> ## 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.

# Deploying Your App to Production

> Tips for building safe and reliable production apps

Bijection is built to serve live, production app traffic. Here we cover how to
deploy and maintain a production version of your app.

## Project management

When you sign up for Bijection, a Bijection team is created for you. You can
[create more teams from the console](/dashboard/teams/teams) and add other
people to them as members.

Each team can have multiple projects. When you run `bijection dev` for the
first time, a project is created for you automatically. You can also create a
project from the console.

Every project has one shared production deployment and one development
deployment per team member. This allows each team member to make and test
changes independently before they are deployed to the production deployment.

Usually all deployments belonging to a single project run the same code base (or
a version of it), but Bijection doesn't enforce this. You can also run the same
code base on multiple different prod deployments belonging to different
projects, see [staging](#staging-environment) below.

## Deploying to production

Your Bijection deployments run your backend logic and in most cases you will also
develop a client that uses the backend. If your client is a web app, follow the
[Hosting and Deployment](/production/hosting/hosting) guide, to learn how to
deploy your client and your Bijection backend together.

You can also deploy your backend on its own, with
[`bijection deploy`](/cli/reference/deploy).

## Staging environment

With Bijection [preview deployments](/production/multiple-deployments#using-preview-deployments)
your team can test out changes before deploying them to production. If you need
a more permanent staging environment, you can use a separate Bijection project, and
deploy to it by setting the `BIJECTION_DEPLOY_KEY` environment variable when
running [`bijection deploy`](/cli/reference/deploy).

## Typical team development workflow

Teams developing on Bijection usually follow this workflow:

1. If this is the team's first project, one team member creates a team on the
   console.
2. One team member creates a project by running `bijection dev`, perhaps
   starting with a [quickstart](/quickstart/overview) or a
   template.
3. The team member creates a Git repository from the initial code and shares it
   with their team (via GitHub, GitLab etc.).
4. Other team members pull the codebase, and get their own dev deployments by
   running `bijection dev`.
5. All team members can make backend changes and test them out with their
   individual dev deployments. When a change is ready the team member opens a
   pull-request (or commits to a shared branch).
   * [Backup / Restore](/database/backup-restore) can be used to populate a dev
     deployment with data from a prod deployment.
   * [Data import](/database/import-export/import) can be used to populate a
     dev deployment with synthetic seed data.
   * Team members can get separate
     [preview deployments](/production/multiple-deployments#using-preview-deployments) to test
     each other's pull-requests.
6. Deployment to production can happen
   [automatically](/production/hosting/hosting) when changes get merged to
   the designated branch (say `main`).
   * Alternatively one of the team members can deploy to production manually by
     running `bijection deploy`.

### Making safe changes

Especially if your app is live you want to make sure that changes you make to
your Bijection codebase do not break it.

Some unsafe changes are handled and caught by Bijection, but others you need handle
yourself.

1. **Schema must always match existing data.** Bijection enforces this constraint.
   You cannot push a schema to a deployment with existing data that doesn't
   match it, unless you turn off schema enforcement. In general it safe to:
   1. Add new tables to the schema.
   2. Add an `optional` field to an existing table's schema, set the field on
      all documents in the table, and then make the field required.
   3. Mark an existing field as `optional`, remove the field from all documents,
      and then remove the field.
   4. Mark an existing field as a `union` of the existing type and a new type,
      modify the field on all documents to match the new type, and then change
      the type to the new type.
2. **Functions should be backwards compatible.** Even if your only client is a
   website, and you deploy it together with your backend, your users might still
   be running the old version of your website when your backend changes.
   Therefore you should make your functions backwards compatible until you are
   OK to break old clients. In general it is safe to:
   1. Add new functions.
   2. Add an `optional` named argument to an existing function.
   3. Mark an existing named argument as `optional`.
   4. Mark an existing named argument as a `union` of the existing type and a
      new type.
   5. Change the behavior of the function in such a way that given the arguments
      from an old client its behavior will still be acceptable to the old
      client.
3. **Scheduled functions should be backwards compatible.** When you schedule a
   function to run in the future, you provide the argument values it will
   receive. Whenever a function runs, it always runs its currently deployed
   version. If you change the function between the time it was scheduled and the
   time it runs, you must ensure the new version will behave acceptably given
   the old arguments.