
Add Clerk authentication to a TanStack Start app with the Clerk CLI - Part 2
Part 2 of 2. Start with Add Clerk authentication to a TanStack Start app with the Clerk CLI.
How do I wire up Clerk UI components and configure settings in TanStack Start?
This is part 2 of a two-part series on adding Clerk authentication to a TanStack Start app using the Clerk CLI. This part focuses on wiring up the landing page UI, starting the dev server, and performing operational tasks using the Clerk CLI such as configuring instance settings and querying the instance via clerk api.
Wire up the landing page
clerk init deliberately leaves src/routes/index.tsx alone — it's your landing page, and the CLI doesn't make assumptions about your layout. That means out of the box the app has no sign-in affordance on the home page. Add one:
import { Show, SignInButton, SignUpButton, UserButton } from '@clerk/tanstack-react-start'
import { createFileRoute } from '@tanstack/react-router'
export const Route = createFileRoute('/')({ component: Home })
function Home() {
return (
<div className="p-8">
<header className="mb-8 flex items-center justify-end gap-3">
<Show when="signed-out">
<SignInButton mode="modal" />
<SignUpButton mode="modal" />
</Show>
<Show when="signed-in">
<UserButton />
</Show>
</header>
<h1 className="text-4xl font-bold">Welcome to TanStack Start</h1>
<p className="mt-4 text-lg">
Edit <code>src/routes/index.tsx</code> to get started.
</p>
</div>
)
}This is the minimum viable landing page. The mode="modal" prop opens the sign-in/sign-up components in a modal rather than routing to /sign-in or /sign-up. Drop mode="modal" if you prefer full-page navigation to the catch-all routes clerk init generated.
Start the dev server and sign up a test user
pnpm devOpen http://localhost:3000. You should see the "Welcome to TanStack Start" header with Sign in / Sign up buttons in the top right. Click Sign up, run through the flow, and you'll land back on the home page with a <UserButton /> in place of the sign-in/sign-up pair.
If the buttons don't render, two things to check before anything else:
- Restart the dev server. Vite caches aggressively and new env vars don't always hot-reload.
clerk doctor. Missing publishable key is the single most common cause, and doctor catches it in one shot.
Configure Clerk as code: clerk config
clerk config treats your Clerk instance configuration as data. You can pull the current state, diff it, patch fields, and audit the result. It's the same surface whether you're on dev or prod — add --instance prod when you're ready to push changes upstream.
Start by inspecting the schema:
clerk config schema
clerk config schema --keys auth_passkey session auth_attack_protectionclerk config schema prints the entire config surface. --keys scopes it — useful when you know the key names and just want the shape.
Pull the current config as a baseline:
clerk config pull --output config.before.jsonFour patches follow. Run each --dry-run first; the dry run prints the exact shape that would be sent without making changes. Drop --dry-run and add --yes to commit.
Patch 1: block disposable email domains (no paid-plan gate):
clerk config patch --dry-run --json '{"auth_access_control":{"block_disposable_email_domains":true}}'
clerk config patch --json '{"auth_access_control":{"block_disposable_email_domains":true}}' --yesPatch 2: tighten lockout to 10 failed attempts (no paid-plan gate — the default is 100):
clerk config patch --dry-run --json '{"auth_attack_protection":{"user_lockout":{"max_attempts":10}}}'
clerk config patch --json '{"auth_attack_protection":{"user_lockout":{"max_attempts":10}}}' --yesPatch 3: enable passkeys as a sign-in factor (paid plan required):
clerk config patch --dry-run --json '{"auth_passkey":{"used_for_sign_in":true}}'
clerk config patch --json '{"auth_passkey":{"used_for_sign_in":true}}' --yesPatch 4: tune session config (paid plan required):
clerk config patch --dry-run --json '{"session":{"allowed_clock_skew":5,"claims":{},"lifetime":3600}}'
clerk config patch --json '{"session":{"allowed_clock_skew":5,"claims":{},"lifetime":3600}}' --yesallowed_clock_skew tolerates small time drift between client and server (seconds). claims is where you inject custom session claims. lifetime is the session token lifetime in seconds (3600 = 1 hour).
Pull the new config and diff it:
clerk config pull --output config.after.json
diff config.before.json config.after.jsonYou should see four blocks: block_disposable_email_domains flipped, max_attempts dropped from 100 to 10, used_for_sign_in flipped to true, and a full session object materialized (it was null before Patch 4).
Verify the config changes worked
Reload the app and walk the sign-up flow again. A few things to confirm:
- Disposable-email blocking. Try signing up with a
@mailinator.comaddress. The signup should be rejected at the email step. - Lockout. Fail sign-in 10 times on purpose. The account should lock.
- Passkey sign-in. Sign in with your test user, open
<UserProfile />(add a/userroute rendering<UserProfile />if you don't have one yet), go to the Security tab, and register a passkey. Sign out, then sign in again — "Continue with passkey" should appear above the email field. Validated with platform authenticators (Touch ID, Windows Hello) and Bitwarden. - Session lifetime. Signed-in sessions now expire after 1 hour instead of the default. Easy to verify in a long-running tab; easy to forget in dev unless you leave one open.
Inspect your instance with clerk api
clerk api is a direct wrapper around the Clerk Backend API and (with --platform) the Clerk Platform API. It authenticates with your linked app's keys, so you don't need to craft curl commands or copy CLERK_SECRET_KEY into Postman.
List available endpoints and commands:
clerk api ls
clerk api ls usersList users:
clerk api /users
clerk api /users?limit=5Fetch a single user:
clerk api /users/<user_id>The Platform API (cross-instance application management) lives behind --platform. The CLI auto-prepends /v1 and points at the Platform API host (api.clerk.com). Platform resources are namespaced under /platform/, so the full path for listing applications is /platform/applications — the CLI resolves this to api.clerk.com/v1/platform/applications:
clerk api --platform /platform/applicationsBackend API calls (no --platform) hit api.clerk.dev instead, and their paths do not need the /platform/ prefix — /users resolves to api.clerk.dev/v1/users, /organizations to api.clerk.dev/v1/organizations.
clerk api isn't a replacement for the full Backend SDK in application code — it's for one-off inspection, ops, and scripts.
Appendix: what clerk init wrote for you
If you ever need to reproduce clerk init's output by hand — porting to a non-supported framework, or just curious — here's the exact surface. Validated against TanStack Start 1.167.42 + @clerk/tanstack-react-start@1.1.5.
package.json — one dependency added:
{
"dependencies": {
"@clerk/tanstack-react-start": "^1.1.5"
}
}src/routes/__root.tsx — existing content wrapped in <ClerkProvider> (reformatted by pnpm format):
import { ClerkProvider } from '@clerk/tanstack-react-start'
import { HeadContent, Scripts, createRootRoute } from '@tanstack/react-router'
import { TanStackRouterDevtoolsPanel } from '@tanstack/react-router-devtools'
import { TanStackDevtools } from '@tanstack/react-devtools'
import appCss from '../styles.css?url'
export const Route = createRootRoute({
head: () => ({
meta: [
{ charSet: 'utf-8' },
{ name: 'viewport', content: 'width=device-width, initial-scale=1' },
{ title: 'TanStack Start Starter' },
],
links: [{ rel: 'stylesheet', href: appCss }],
}),
shellComponent: RootDocument,
})
function RootDocument({ children }: { children: React.ReactNode }) {
return (
<html lang="en">
<head>
<HeadContent />
</head>
<body>
<ClerkProvider>
{children}
<TanStackDevtools
config={{ position: 'bottom-right' }}
plugins={[
{
name: 'Tanstack Router',
render: <TanStackRouterDevtoolsPanel />,
},
]}
/>
<Scripts />
</ClerkProvider>
</body>
</html>
)
}src/routes/sign-in.$.tsx (new) — catch-all route so <SignIn /> handles any sub-path (Clerk uses this for flow steps like /sign-in/factor-two):
import { SignIn } from '@clerk/tanstack-react-start'
import { createFileRoute } from '@tanstack/react-router'
export const Route = createFileRoute('/sign-in/$')({
component: Page,
})
function Page() {
return (
<div className="flex min-h-screen items-center justify-center">
<SignIn />
</div>
)
}src/routes/sign-up.$.tsx (new) — mirror of sign-in for sign-up:
import { SignUp } from '@clerk/tanstack-react-start'
import { createFileRoute } from '@tanstack/react-router'
export const Route = createFileRoute('/sign-up/$')({
component: Page,
})
function Page() {
return (
<div className="flex min-h-screen items-center justify-center">
<SignUp />
</div>
)
}src/start.ts (modified) — Clerk's request middleware slotted into TanStack Start's server instance (TanStack's scaffold creates this file; clerk init adds the clerkMiddleware() call and the @clerk/tanstack-react-start/server import):
import { clerkMiddleware } from '@clerk/tanstack-react-start/server'
import { createStart } from '@tanstack/react-start'
export const startInstance = createStart(() => {
return {
requestMiddleware: [clerkMiddleware()],
}
})This is the TanStack Start equivalent of Next's proxy.ts / middleware — the hook-point where Clerk resolves the session for every server-side request. createStart takes a callback that returns the config, not a plain object. clerkMiddleware() populates the request context that auth() from @clerk/tanstack-react-start/server reads inside server functions and loaders, so you can gate them with beforeLoad or by checking userId from await auth() before returning data.
.env.local — the four route URL vars come from the framework scaffold step, the two key vars come from clerk init's built-in env pull (real values land whenever you pre-link an app with clerk link --app <id> or pick an app at the interactive prompt):
VITE_CLERK_SIGN_IN_URL=/sign-in
VITE_CLERK_SIGN_UP_URL=/sign-up
VITE_CLERK_SIGN_IN_FALLBACK_REDIRECT_URL=/
VITE_CLERK_SIGN_UP_FALLBACK_REDIRECT_URL=/
# Clerk
VITE_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...What clerk init does not touch: src/routes/index.tsx (landing page), vite.config.ts, src/router.tsx, src/styles.css, README.md. That's why the "wire up the landing page" step exists — you're filling in the piece the CLI intentionally left under your control.
CLI reference (quick skim)
Commands the article touched:
Flags worth memorizing:
--yes/-y— non-interactive; accept defaults.--dry-run— print the operation without executing (config patch,config put,api).--instance prod— target production instead of dev.--app app_xxx— scope the command to a specific app (valid onlink,env pull,config *,api— not oninit).--no-skills— skip the agent-skills prompt insideclerk init.
To upgrade the CLI itself, rerun the installer (curl -fsSL https://clerk.com/install | sh, clerk update, or npm install -g clerk@latest). There is no clerk update subcommand in 1.0.2.
Full reference: Clerk CLI docs.
Further reading
- TanStack Start quickstart — Clerk docs
- Clerk CLI reference
- How Clerk works — overview
- Core 3 upgrade guide
- TanStack Start authentication guide
- Clerk CLI source — GitHub
Conclusion
In this series, we used the Clerk CLI to add authentication to a TanStack Start application. We covered scaffolding the app, running clerk init, pulling environment variables, verifying the setup, adding the UI components, and managing Clerk instance configurations as code.
FAQ
In this series
- Add Clerk authentication to a TanStack Start app with the Clerk CLI
- Add Clerk authentication to a TanStack Start app with the Clerk CLI - Part 2 (you are here)