# Dev vs production discipline with Clerk
## Key sets
Clerk issues separate publishable/secret key pairs per instance environment: `pk_test`/`sk_test` for development, `pk_live`/`sk_live` for production. The frontend and backend keys must come from the same environment. Mixing a test publishable key with a live secret key (or vice versa) fails in confusing ways.
## The accountless CLI trap
`npx clerk@latest init` can provision a claimable application with temporary development keys without a Clerk account. That is great for scaffolding, but:
- The app is unclaimed until someone runs `npx clerk@latest auth login`. Unclaimed apps and temporary keys are not production-ready, per Clerk's own docs.
- Before production, claim the app, then run the production deploy flow (`npx clerk@latest deploy`) and switch env vars to the production key pair.
## Production checklist
- Production keys in the host's env, never in the repo. `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` (or the bundler equivalent) is public by design; `CLERK_SECRET_KEY` never leaves the server.
- Production webhook endpoints recreated against the production URL, with the production signing secret in env.
- Authorized parties / allowed origins updated to the production domains.
- If you customized session token claims or JWT templates in dev, confirm the same configuration exists on the production instance; token verification failures after launch are often dev-only config.
- Run `npx clerk@latest doctor` as a final check; it verifies the setup end to end.