# Environments

One of the things that makes Zuplo different from most API gateways, and API
management platforms is that you can rapidly deploy many environments. Some of
our customers have hundreds of deployed environments! This facilitates
collaboration, where teams can collaborate on new features with a dedicated
environment, deployed for no additional cost in under 20 seconds.

:::tip

For a comprehensive guide to how branches map to environments, see
[Branch-Based Deployments](./branch-based-deployments.mdx).

:::

## Environment Types

There are three types of environments on Zuplo - Production, Preview, and
Development (called Working Copy). Each environment has a unique URL and every
environment is deployed to 300+ edge locations around the world.

### Development (Working Copy)

This is your development environment. You can think of this as your personal
cloud laptop. To deploy to this environment you just need to save a change in
portal.zuplo.com, that will automatically trigger a build and deploy of your
working-copy. A working-copy environment ends in a `.dev` URL. While these
environments are deployed to the edge in 300+ data centers around the world,
they're optimized for development purposes. There are some minor differences
with production and preview environments with caching and other features.

### Preview

These are environments that are deployed using the
[GitHub integration](/docs/articles/source-control.mdx) or building a
[custom CI/CD pipeline](/docs/articles/custom-ci-cd.mdx). Preview environments
are deployed from any branch that isn't set as your default (for example
production branch). Preview environments are deployed to the edge and have the
same behavior as production environments, but are typically used for staging,
testing pull requests, etc.

### Production

These are environments that are deployed using the
[GitHub integration](/docs/articles/source-control.mdx) or building a
[custom CI/CD pipeline](/docs/articles/custom-ci-cd.mdx). Each project has only
one Production environment and is deployed from the git branch that's set as
your production branch in your source control settings.

#### Changing the Production Environment

The Production environment is determined by your repository's **default branch**
setting (configured in your Git provider, not Zuplo). To change which branch
deploys to Production:

1. Go to your Git repository settings:
   - **GitHub**: Settings > General > Default branch
   - **GitLab**: Settings > Repository > Branch defaults
   - **Bitbucket**: Repository settings > Branching model
   - **Azure DevOps**: Project settings > Repositories > Default branch
2. Change the default branch to your desired branch
3. Zuplo automatically treats the new default branch as Production

:::caution

Changing the default branch affects which environment receives Production
environment variables and uses the Production API key bucket. Plan this change
carefully.

:::

### Preview vs Production Environments (or multiple Production Environments)

:::note

There is **no technical difference** between a Production environment and a
Preview environment. Both deploy to the same infrastructure, run in the same
300+ edge locations, and have identical performance characteristics. The
"production" label simply means "deployed from the default branch." It controls
which set of [environment variables](/docs/articles/environment-variables.mdx)
and [API key buckets](/docs/articles/api-key-buckets.mdx) apply by default, but
the underlying deployment is exactly the same.

:::

Some customers choose to use a specific (or multiple) Preview environments as
"production" deployments of their API. For example, you might deploy your US
traffic from `main` (Production) and your EU traffic from an `eu-production`
branch (Preview). This works because the environments are technically identical.
Environment variables and API key buckets can be overridden for specific Preview
environments to support this pattern.

For a comprehensive overview of how source control, branches, and environments
relate to each other, see
[Source Control and Deployment](/docs/concepts/source-control-and-deployment.mdx).

## Navigating Environments

On the bottom toolbar of the Zuplo portal you will see a selector for the
current environment. You can switch between environments by clicking on the name
of the current environment and then selecting another environment.

![Environments](../../public/media/environments/image.png)

Your development (working copy) environment will be listed at the top in a
separate section. Your git deployed environments will be listed next with the
production environment on top.

For users using [source control integration](/docs/articles/source-control.mdx)
the name of the deployment matches the branch name (yes - creating a new
environment is literally as easy as creating a new branch).

You can't edit the code of an production or preview environment in
portal.zuplo.com but you can switch into those environments to perform a number
of functions, such as:

- edit API consumers for this environment
- view analytics for this environment
- view Live Logs for this environment

## Different Backends per Environment

It's common to want a different backend for your production, staging and preview
environments. This can be easily achieved by using
[environment variables](./environment-variables.mdx) to specify the origin of
the backend and then using that in your
[URL Rewrite Handlers](../handlers/url-rewrite.mdx).

For example,

```json
${env.BASE_PATH}${pathname}
```

A url rewrite like this will combine the `BASE_PATH` environment variable, say
`https://example.com` with the incoming path, for example `/foo/bar` to create a
re-written URL:

```json
https://example.com/foo/bar
```