Sign-in and workspaces
People sign in with Clerk, work with their team inside a workspace, and can only do what their role allows. Your server checks all of it on every request.
In short
- Clerk runs accounts, passwords and invitations: nothing to build, no password to store.
- Each customer works in its own workspace, walled off from the others.
- Runs without a Clerk account until you add your keys.
Clerk's sign-in, in your colors
Clerk's own screens handle sign-up, sign-in, email codes and workspace creation. They read your theme's variables, so they look like the rest of the app, and they switch to French with it.
- Email with a password or a code, Google, and more: chosen in the Clerk dashboard
- Two-step verification and signed-in devices on the Security settings page
- Clerk's bot protection checks every sign-up: the guide shows the one setting to verify
- The server checks each session token itself, without calling Clerk
Every customer gets a workspace
Clerk's organizations are your workspaces. Each person works inside an active one, switches from the sidebar, and invites teammates from the Members page.
- A new person creates a workspace or joins one they were invited to
- Switching workspace clears what the app loaded before showing the new one
- Your database gets its own copy on the first request, with its own ids
Roles from Clerk, permissions in your code
Clerk only says whether someone is an admin or a member. One file of your code turns that role into permissions, and every endpoint checks the permission it needs. Nothing to set up in the Clerk dashboard.
- Admins can do everything; members create and edit projects
- A role your code doesn't know gets the member's permissions
- The web app hides what a member can't do, and the server refuses it anyway
| Permission | Admin | Member |
|---|---|---|
Create projectsorg:projects:create | Allowed | Allowed |
Edit projectsorg:projects:update | Allowed | Allowed |
Delete projectsorg:projects:delete | Allowed | Not allowed |
Manage the workspaceorg:workspace:manage | Allowed | Not allowed |
Manage billingorg:billing:manage | Allowed | Not allowed |
One workspace never sees another's data
The workspace comes from the verified token, never from what the browser sends. Workspace data is only read and written through a repository that adds it to every query, and a lint rule refuses any other way.
- Asking for another workspace's project answers "not found", as if it didn't exist
- The API tests check it for every action on the example feature
Try everything before creating a Clerk account
Without Clerk keys, a stand-in signs every request in as Ada Lovelace, admin of Acme team. A request header picks another sample person, so you can try each role. It refuses to run in production.
- Add your Clerk keys when you're ready: no code to change
- The API tests always run with it
# Who signs users in.# mock (default) every request is signed in as a seeded user (Ada Lovelace,# admin of "Acme team"), so the app runs without a Clerk account.# Development and tests only: refused when NODE_ENV=production.# clerk real sign-in with Clerk; the three CLERK_ keys below are then required.AUTH_PROVIDER=mock| Person | Workspace | Role |
|---|---|---|
| Ada Lovelaceada@example.com | Acme team | Admin |
| Grace Hoppergrace@example.com | Acme team | Admin |
| Alan Turingalan@example.com | Acme team | Member |
| Bob Smithbob@example.com | Globex | Admin |
Questions
Do I need a Clerk account to start?
No. The starter runs with its stand-in sign-in until you add your Clerk keys. Clerk's free plan covers 50,000 monthly users; check their website for current prices.
Can I add my own roles?
The starter uses Clerk's two default roles on purpose and derives permissions in your code. Add a permission to two lists and every endpoint can check it. Custom roles in Clerk need one of its paid add-ons.
Where are passwords stored?
At Clerk. Your database keeps a copy of names and emails, never passwords, sessions or two-step verification settings.
Explore the other features
- BillingStripe subscriptions per workspace, driven by webhooks.
- AI guardrailsA rulebook, lint rules that explain, and yarn verify.
- Design system70 components, 466 icons and tokens for light and dark.
- ArchitectureOne repository: web app, API, worker and shared code.
- SecurityLocked endpoints, rate limits, backups, alerts.
Start your next app from a clean base
Pay once and get the full source code, with every future update.