Deployments and Rollbacks
- Applies to
- Gatewayruntime for API, AI, and MCP gateways
- Hosting
- Managed EdgeManaged DedicatedSelf-Hosted
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.
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.
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.
Roll back to an earlier version
You can redeploy any earlier build of an environment from the Zuplo Portal.
- Open Environments in your project.
- Select the environment you want to roll back. Its list of builds opens.
- Find the build you want to return to, open its actions menu, and select Redeploy this version.
- 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.
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, 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.