> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic AuthKit Configuration

> Configure WorkOS AuthKit integration with automatic provisioning for Bijection deployments

Bijection can **create** AuthKit environments in a WorkOS account made on your
behalf. By default WorkOS gives you only two environments, but giving each
Bijection dev deployment its own AuthKit environment is useful for isolating
development user data and configuration changes between multiple developers or
agents working in parallel.

The Bijection CLI will **configure** AuthKit environments, regardless of whether
Bijection or you created them, if the `WORKOS_CLIENT_ID` and `WORKOS_API_KEY`
environment variables are present in the build environment or the Bijection
deployment. While developing locally, Bijection can write environment variables to
`.env.local` to make setting up an AuthKit environment a breeze.

This automatic configuration is available whether you're
[starting a new application](/auth/authkit/index) or adding WorkOS AuthKit to an
[existing application](/auth/authkit/add-to-app).

Read on for some additional details about how the auto-configuration works and
some things that you may need to configure manually based on your specific
needs.

<Info>
  Provisioning or disconnecting the underlying Bijection-managed WorkOS team
  requires **team admin**. Provisioning a per-deployment WorkOS environment uses
  the deployment's own management permission — any team member can do this for
  their dev or preview deployment, but production envs require team admin (or
  project admin). Shared project-level WorkOS environments require team admin or
  project admin.
</Info>

## Production deployments

In the Bijection console settings for your production deployment, create an
AuthKit environment in the WorkOS Authentication integration under settings,
integrations. Copy these credentials to your hosting provider environment
variables (in addition to other setup, like adding a production
`BIJECTION_DEPLOY_KEY`, setting the build command, and setting other
framework-specific AuthKit environment variables).

## Preview deployments

In the Bijection console settings for any deployment in your project, create a
new project-level AuthKit environment in the WorkOS Authentication integration
under settings, integrations. Copy these credentials to your hosting provider
environment variables (in addition to other setup, like adding a preview
`BIJECTION_DEPLOY_KEY`, setting the build command, and setting other
framework-specific AuthKit environment variables).

## How it works

AuthKit provisioning and configuration is triggered by the presence of a
`bijection.json` file with an `authKit` section with a property corresponding to
the type of code push: `dev`, `preview`, or `prod`.

If this section is present, an AuthKit environment may be provisioned (dev
only), local environment variables set (dev only), and configured (all code push
types).

### Finding the AuthKit environment

The CLI looks for WorkOS credentials `WORKOS_CLIENT_ID` and `WORKOS_API_KEY` in
the following order:

1. Environment variables in the build environment shell or `.env.local` file
2. Bijection deployment environment variables

In remote build environments (e.g. building a project in Vercel, Netlify,
Cloudflare) if these two environment variables are not found, the build will
fail.

During local dev, credentials are next fetched from the Bijection Cloud API for a
new or existing AuthKit environment. A link to this deployment in the WorkOS
dashboard can be found in the Bijection console under the WorkOS integration.

### Configuring the AuthKit environment

Once credentials are found, the `WORKOS_API_KEY` is used to configure the
environment based on the `configure` section of the relevant `authKit` object.
This sets things like an environment's
[redirect URIs](https://workos.com/docs/sso/redirect-uris),
[allowed CORS origins](https://workos.com/docs/authkit/client-only).

### Setting local environment variables

For dev deployments only, environment variables are written to `.env.local`
based on the `localEnvVars` section of the relevant `authKit` config.

## Project-level vs deployment level AuthKit environments

In hosting providers with remote build pipelines like Vercel, it's difficult to
set environment variables like `WORKOS_API_KEY` at build time in a way that's
available to server-side code like Next.js middleware. This makes it necessary
set the `WORKOS_*` environment variables in advance for preview and production
deployments built on these platforms.

After creating the WorkOS AuthKit environments for production and preview
deployments in the console, copy relevant environment variables like
`WORKOS_CLIENT_ID`, `WORKOS_API_KEY`, `WORKOS_REDIRECT_URI`, and
`WORKOS_COOKIE_PASSWORD` to the preview and production environment variables in
your hosting provider.

Deployment-specific AuthKit environments can be created for any deployment are
difficult set up automatically so shared project-level environments are
generally a better fit.

In the `authKit` section of `bijection.json`, `localEnvVars`
`automate setting up dev environments by automatically setting the right environment variables in .env.local and automatically configuring the environment with a `redirectUri\`.

Environments for hosting providers in build environments like Vercel (production
and preview deploys) can be configured at build time, but the environment
variables for these build environments must be set manually in the build
settings.