Auth breaks right after deploy: development keys are still set in production

TL;DR: Everything worked locally. In production, sign-in fails or users land on the wrong instance. Confirm the cause 1. Read the production env vars on your host.

The fix

1. Read the production env vars on your host. If the publishable key starts with pktest or the secret key starts with sktest, production is talking to your development instance.
2. This is the single most common Clerk deploy mistake, called out explicitly in the deployment docs.
3. In your hosting provider's env vars (not just your local .env), set the production keys from the production instance: the pklive publishable key, the sklive secret key, and the production webhook signing secret.
4. While you are there: production OAuth needs your own provider credentials (development uses Clerk's shared ones), and custom-domain DNS records can take up to 24 hours to propagate.

When to use this

• This covers exactly what the title says: Auth breaks right after deploy.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Auth; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Auth behavior.

Verified against Clerk deployment docs 2026-09-26: forgetting to change API keys to the production instance's keys is the documented common mistake; keys are pktest/sktest in development and pklive/sklive in production, set per environment; production OAuth requires your own credentials and DNS can take up to 24h.