┌───────────────────────────────────────────────────────────────────────────────┐ │ 📄 shadcn/directory/clerk/clerk-docs/guides/development/deployment/production │ └───────────────────────────────────────────────────────────────────────────────┘
╔══════════════════════════════════════════════════════════════════════════════════════════════╗
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
Before you begin:
[!WARNING] For security reasons, SSO connections, Integrations, and Paths settings do not copy over. You will need to set these values again.
A common mistake when deploying to production is forgetting to change your API keys to your production instances keys. The best way to set this up is to make use of environment variables. All modern hosting providers, such as Vercel, AWS, GCP, Heroku, and Render, make it easy to add these values. Locally, you should use an .env file. This way, these values are being set dynamically depending on your environment. Here's a list of Clerk variables you'll need to change:
Publishable Key: Formatted as pk_test_ in development and pk_live_ in production. This is passed to the <ClerkProvider> during initialization.
Secret Key: Formatted as sk_test_ in development and sk_live_ in production. These values are used to access Clerk's Backend API.
[!TIP] Be sure to update these values in your hosting provider's environment variables, and also to redeploy your app.
In development, for most social providers, Clerk provides you with a set of shared OAuth credentials.
In production, these are not secure and you will need to provide your own. Each OAuth provider has a dedicated guide on how to set up OAuth credentials for Clerk production apps.
Your webhook endpoints will need to be updated to use your production instance's URL and signing secret. See the guide on syncing data for more information.
If you're using a CSP, follow the instructions in the CSP guide.
Clerk uses DNS records to provide session management and emails verified from your domain.
To see what DNS records you need, navigate to the Domains page in the Clerk Dashboard.
[!NOTE] It can take up to 48hrs for DNS records to fully propagate.
When you set a root domain for your production deployment, Clerk's authentication will work across all subdomains. User sessions will also be shared across the subdomains.
Examples
example-site.com and dashboard.example-site.comdashboard.example-site.com and accounts.example-site.com[!NOTE] If you're using passkeys, only the first scenario in the above example will work due to restrictions in the WebAuthn standard.
To share sessions and authentication across two different domains with the same Clerk application, see the Authentication across different domains guide.
authorizedParties for secure request authorizationFor enhanced security, it's highly recommended to explicitly set the authorizedParties option when authorizing requests. This option acts as an allowlist of origins to verify against, protecting your application from subdomain cookie leaking attacks. Without this setting, if an app on another subdomain of the same root domain as your Clerk app is compromised, that app could potentially generate valid sessions for your Clerk app.
The authorizedParties value should include a list of domains allowed to make requests to your application. Omitting this setting can expose your application to CSRF attacks.
The following examples show how to set authorizedParties with different Clerk helpers.
authorizedParties with clerkMiddleware()clerkMiddleware({
authorizedParties: ['https://example.com'],
})
authorizedParties with authenticateRequest()clerkClient.authenticateRequest(req, {
authorizedParties: ['https://example.com'],
})
The Clerk Dashboard home page will tell you what steps are still required to deploy your production instance. Once you have completed all of the necessary steps, a Deploy certificates button will appear. Selecting this button will deploy your production instance.
Clerk uses a DNS check to validate this CNAME record. If this subdomain is reverse proxied behind a service that points to generic hostnames, such as Cloudflare, the DNS check will fail. Set the DNS record for this subdomain to a "DNS only" mode on your host to prevent proxying.
If your instance is stuck during TLS certificate issuance for longer than a few minutes, this might be caused due to certain CAA DNS records set on your primary domain.
CAA are DNS records you may set to denote which certificate authorities (CA) are permitted to issue certificates for your domain, as a security measure against certain attacks. When you deploy your application, Clerk attempts to provision certificates using either the LetsEncrypt or Google Trust Services certificate authorities.
Ensure that your primary domain (e.g., example.com) does not have any CAA records that prevent either LetsEncrypt or Google Trust Services from issuing certificates for your domain. To check this, run the following command in your terminal, replacing example.com with your app’s domain:
dig example.com +short CAA
If the command returns an empty response, your domain is correctly configured. If it returns any text, you need to remove the CAA records from your primary domain to avoid potential downtime during certificate renewal.
If you accidentally set the wrong domain, you can change it through the Clerk Dashboard or the Backend API. For more information, see the dedicated guide.
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╚══════════════════════════════════════════════════════════════════════════════════════════════╝