Skip to main content

How to take Clerk to Production

Category
Guides
Published

Step-by-step guide for developers to launch a Clerk app in a production environment with a custom domain, OAuth credentials, and secure DNS configuration.

When you're building a modern web app, authentication is one of the first things to set up—and Clerk makes it incredibly fast. By default, your app starts with a development instance so you can test and build quickly. But to go live securely, you'll need a production instance.

Not sure when or how to switch? Let's walk through the differences and steps.

Related: Dev vs Prod Environment Guide

What's the Difference Between Dev and Production in Clerk?

Dev instances are optimized for speed:

  • Use shared OAuth credentials
  • Allow HTTP (great for localhost)
  • Minimal setup to get started

Production instances are secure by design:

  • Require HTTPS
  • Use dedicated credentials per provider
  • Authenticate under your own domain via DNS records

This setup reduces the risk of cross-site scripting and improves trust with your users.

Step-by-Step: Launching Your Clerk App in Production

1. Set Up Your Custom Domain

Before anything else, secure the domain where users will log in. Clerk uses this domain for identity verification and security. Related: Using Clerk with Custom Domains

2. Create a Production Instance in the Clerk Dashboard

Alt text: Clerk dashboard showing how to switch from a development instance to a production instance. The dropdown menu labeled “Development” is open, with a red arrow pointing to the “Create production instance” option. This step is part of promoting your app to production in Clerk.
  • Toggle from “Development” → Create production instance
  • Choose to clone or start fresh
  • Reconfigure any integrations that don't carry over (e.g., SSO)

Clerk gives you a helpful checklist after creation.

3. Add DNS Records for Verification

Alt Text: Clerk production instance dashboard displaying the initial setup checklist. It highlights required actions such as setting custom OAuth2 credentials and configuring CNAME records before deployment. Metrics for total users, active users, and deployment status (frontend not deployed, backend operational) are shown below.

Clerk provides DNS entries for:

  • Verifying domain ownership
  • Email authentication (SPF, DKIM, etc.)
  • Redirects/login under your domain

See docs: Custom Domain DNS Setup

4. Update Your API Keys

Alt Text: Clerk dashboard showing the API keys configuration page for a production instance. The screen displays the public "publishable key" (pk_live_...) for frontend use and a masked secret key under “default.” It also shows relevant deployment URLs, including the Frontend API, Backend API, and JWKS endpoint. A warning at the bottom reminds users that Clerk support will never ask for secret keys.

Each Clerk instance has its own key (Located under Configure > API Keys):

  • pk_live_ (publishable)
  • sk_live_ (secret)

Replace your .env values with the new production keys.

Docs: Environment Variables Reference

5. Configure Social Logins for Production

Clerk uses shared credentials in dev—but in production, you must register your app with each identity provider.

For example, when using Google:

  • Visit Google Cloud Console
  • Set up the consent screen + credentials
  • Add redirect URIs from your Clerk dashboard

Detailed walkthrough: Google OAuth with Clerk

Also see the full OAuth guide for other providers.

TL;DR: How to Go Live with Clerk

1. Secure a custom domain
2. Create a production instance from the Clerk dashboard
3. Configure DNS records
4. Update your environment with production API keys
5. Register OAuth credentials per provider and configure in Clerk
6. Redeploy your app using the new settings

Ready to get started?

Sign up today
Author
Alex Rapp