Clerk logo

Clerk Docs

Ctrl + K
Go to

Remix Authentication

Easily add secure, edge- and SSR-friendly authentication to Remix with Clerk.


Clerk is the easiest way to add authentication and user management to your React application. This guide will walk you through the necessary steps to install and use Clerk in a new Remix application.

After following this guide, you should have a working Remix app complete with:

  • Fully fledged sign in and sign up flows.
  • Google Social Login.
  • Secure email/password authentication.
  • A prebuilt user profile page.

Looking for a quicker start? Check out the Clerk + Remix starter repo

Before you start

Before you start, you need to set up your application in your Clerk Dashboard. For more information, check out our Set up your application guide.

Create a Remix application

Start by creating a new Remix application with the npx CLI:

Choose a directory to create the app and follow these prompts:

  • For app type, select "Just the basics"
  • For deployment target, select "Remix App Server"

Need more help? The Remix documentation goes into more detail about creating applications.

Installing Clerk

Once you have a Remix application ready, you need to install Clerk's Remix SDK. This gives you access to our prebuilt components and hooks for React, as well as our helpers for Remix loaders.


There are 3 important environment variables that you need to know about in Clerk. The Frontend API key, Backend API key, JWT verification key.

You can find them on the API Keys page of your instance.

Frontend API key: This connects your frontend with your instance and is mandatory. This is a "public key", and does not need to be kept secret.

Backend API key: This is used to make admin requests to Clerk's Backend API. This is a "secret key", and MUST BE KEPT SECRET. It has access to modify anything about any of your users. You may not need this in your application.

JWT verification key: This is a public key that is used to validate JWTs, so that you know they are secure. This does not need to be kept secret and you may not need this in your application.

To add environment variables to a Remix application, create a file named .env in the root directory of your project and add your keys there. This is a good time to set all of them so you don't need to worry about them further in the guide.


Initialize Clerk in app/root.tsx

In Remix, app/root.tsx wraps your entire application in both server and browser contexts. Clerk requires three modifications to this file so we can share the authentication state with your Remix routes.

First, we must define a root loader.


If you'd like to load additional data, you can pass your own loader directly to rootAuthLoader.


Wrap your App with ClerkApp

Clerk provides a ClerkApp wrapper to provide the authentication state to your React tree. This helper works with Remix SSR out-of-the-box and follows the "higher-order component" paradigm.

First, update App so it is not exported as the default module. Then, wrap App with ClerkApp:


Set ClerkCatchBoundary

Clerk uses Remix's catch boundary in root.tsx to refresh expired authentication tokens.


You can also add your own boundary, simply by passing it as an argument.


To run your app, start the development server and navigate to http://localhost:3000


Clerk is installed, but you still have to configure your application to actually use authentication. Read on to learn how to protect pages, API routes, and more.

Access authentication data

Once installation is complete, Clerk can seamlessly authenticates users across all three Remix contexts:

  1. React pages
  2. Loaders
  3. Actions

Each context has access to Clerk's auth singleton, which contains the data necessary for authentication and data loading:

  • userId: The ID of the active user, or null when signed out. In data-loaders, this is often the only piece of information needed to securely retrieve the data associated with a request.
  • sessionId: The ID of the active session, or null when signed out. This is primarily used in audit logs to enable device-level granularity instead of user-level.
  • getToken({ template?: string; }): Retrieves a signed JWT that is structured according to the corresponding JWT template in your dashboard. If no template parameter is provided, the default Clerk session JWT is returned.

Using React

In React, the auth singleton is available via the useAuth hook:


Loaders and actions

In loaders and actions, the auth singleton is available via the getAuth helper.


Protecting routes

To protect a route from signed out users, simply add a redirect to your loader if no userId is found in the auth singleton:


Enabling full server side rendering

To make auth as fast as possible, Clerk uses short-lived stateless JWT tokens by default, requiring no network requests.

If desired, Clerk’s complete User objects can also be retrieved during SSR. Since these objects require network requests to retrieve, so you need to explicitly enable server-side user fetching by passing a flag to the root loader:


This makes the entire User object available to your components during SSR, allowing the whole app to be rendered on the server side.

Using Clerk Hosted Pages

If you're looking for the fastest way to implement a full-stack authentication into your site, you can leverage Clerk Hosted Pages for your sign up, sign in, and user profile pages.

You can easily define how you want your users to sign in and sign up in the User & Authentication settings page.

By default, the URLs for your hosted pages will match the following pattern:

For development instances, Clerk will issue you a domain on "". In production, you'll need to supply your own domain. See Production setup or more information.

Clerk provides SDKs to make navigating to these pages easy.


Using Clerk Components

If you want more control over the look and feel of your sign in and sign up experience but don't want to completely build one from scratch, you can use the pre-built Clerk Components.

Clerk provides <SignIn />, <SignUp /> and <UserProfile /> components that render entire flows. Using these, Clerk will take care of everything from verifying the user's email address to letting your user add 2FA. These in conjunction with Remix's router gives you a complete solution that's surprisingly easy to implement and is completely customizable via CSS.

Sign up Pages


Sign in Pages


Once these files have been added, re-run `npm run dev` and navigate to localhost:3000/sign-in

In order to make the links on the modal work, you'll need to set these in the Clerk Dashboard on the Paths page of your instance

For more details on the available component options as well as how you can customize them, please visit the <SignUp /> and <SignIn /> component guides.

Using experimental Edge runtimes

The latest @clerk/remix package (>=1.4.0) works across all Remix runtimes such as Node, Cloudflare Workers, Cloudflare Pages, and Deno.

In order to add it to your Remix application you should follow the steps described in the previous sections but all imports should happen from @clerk/remix/experimental instead of @clerk/remix.

Moreover, the following breaking changes are introduced:

  • The getAuth has a new, simpler signature. Use getAuth(loaderArgs) instead of getAuth(loaderArgs or Request).
  • Fetching data from Clerk Backend API is done as follows:
  • The `window.__clerk_debug` utility returns a debug object instead of a string.

Next steps

You now have a working Remix + Clerk app. Going forward, you can:

Was this helpful?

Clerk © 2022