# Deployments and Rollbacks

> **Scope of this page**
>
> This page documents the Zuplo **gateway** runtime (API, AI, and MCP gateways), not the Developer Portal.
>
> It applies to every Zuplo hosting option: Managed Edge, Managed Dedicated, and Self-Hosted. See [Hosting options](https://zuplo.com/docs/articles/hosting-options).

Every time you push to a branch, Zuplo builds that branch and deploys it to the
matching environment. Deployments don't cause downtime, a deployment that fails
never replaces the version that's serving, and you can roll back to any earlier
build from the Zuplo Portal.

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

## How a deployment rolls out

When a new version of your gateway deploys:

- **There's no downtime.** The environment keeps serving requests throughout the
  deployment.
- **In-flight requests finish.** Requests that are already in progress complete
  on the version that received them. New requests go to the new version.
- **Both versions can serve briefly.** Until the rollout reaches every location,
  some requests can still reach the previous version. Keep changes backward
  compatible across one release, for example by adding a new route before you
  remove the old one.

A deployment takes a few minutes to reach every location that serves your
gateway.

## When a deployment fails

If a build or deployment fails, nothing rolls out. The environment keeps serving
the version that was already deployed, and you can fix the problem and push
again. To find out why a build failed, see
[Troubleshooting Deployments and Git Sync](./troubleshooting-deployments-and-git-sync.mdx).

The build catches problems such as invalid configuration files and code that
doesn't compile. It can't catch every problem that only shows up at runtime,
such as an environment variable that points to the wrong backend or a policy
that rejects valid requests. Test each deployment before it takes production
traffic, for example by running tests against a preview environment. See
[Testing Preview Environments](./testing-preview-environments.mdx).

## Roll back to an earlier version

You can redeploy any earlier build of an environment from the Zuplo Portal.

1. Open
   [**Environments**](https://portal.zuplo.com/+/account/project/environments)
   in your project.
2. Select the environment you want to roll back. Its list of builds opens.
3. Find the build you want to return to, open its actions menu, and select
   **Redeploy this version**.
4. Review the dialog and select **Deploy**. For the production environment, the
   button reads **Deploy to production**.

The redeploy rolls out the same way as any other deployment: with no downtime,
reaching every location within a few minutes.

:::caution

A redeploy uses the source code of the build you select, with your project's
current settings. If the problem came from an
[environment variable](./environment-variables.mdx), change the variable back as
well. Redeploying an earlier build doesn't restore its old variable values.

:::

### Keep your branch in sync

Redeploying an earlier build doesn't change your Git branch. The next push to
that branch deploys the branch's latest commit, including the change you rolled
back. After you roll back, revert the change in Git, for example with
`git revert`, so the next deployment doesn't reintroduce it.

You can also roll back through Git alone: revert the commit and push. Zuplo
builds and deploys the reverted branch like any other change.

## Related resources

- [Environments](./environments.mdx)
- [Branch-Based Deployments](./branch-based-deployments.mdx)
- [Source Control and Deployment](../concepts/source-control-and-deployment.mdx)