# Zero-Downtime Deployments and One-Click Rollback Are Here

> Zero-downtime deploys are live in xCloud: each Git deploy builds beside your live site, passes a check, then switches. Roll back any release in one click.

**Zero-downtime deploys** are now part of xCloud. Turn on **Release mode** on a Git site and every deploy builds a new release beside the live one, checks that it answers, then switches traffic in one step. If a release misbehaves, you roll it back in one click. It works for Laravel, PHP, WordPress, Node.js and Docker sites.

Until now, a deploy on xCloud worked the way it does on most servers: new files land in the folder your visitors are using, and Node.js apps restart. For a few seconds, some requests can fail. That was fine for a blog. It is not fine for a store at checkout time, or for an API that other apps call. If you are new to Git deploys on xCloud, start with our **[one-click Git deploy guide](/one-click-git-deploy-ship-any-project-the-fastest-way/)**.

This post covers what Release mode does, which stacks it supports, how a deploy and a rollback work, what we measured on our own test servers, and how to turn it on.

![The Release mode card on an xCloud Laravel site after it was turned on, with .env and storage shared between releases](/_landing/blog/zero-downtime-deploys-and-one-click-rollback-image-1.png)

## TL;DR

- **What's new:** Release mode gives Git sites zero-downtime deploys and a one-click rollback, from **Site → Git → Release mode**.
- **How it works:** each deploy builds beside the live release, must pass a check, then takes over in one step. A release that fails never goes live.
- **Stacks:** Laravel and PHP on nginx or OpenLiteSpeed, WordPress from Git and Node.js on nginx, and Docker containers from a Dockerfile or an app recipe.
- **Rollback:** switches code only. Your database, `.env` and shared files are not changed.
- **Proof:** on our test servers, 6 apps took 19 deploys and 7 rollbacks under steady traffic with **0 failed requests**. The same Node.js app without Release mode returned 27 errors over 3 deploys.
- **No YAML:** you turn it on from the dashboard. Workers restart on the new code by themselves.

## What We Found: 0 Failed Requests Across 19 Deploys

Before writing a word about this feature, we tested it. On 10 November 2026 we set up three xCloud test servers (nginx, OpenLiteSpeed and Docker) with demo apps from public sample repositories. Each site got a steady 8 requests a second over HTTPS while we turned Release mode on, deployed three or more times and rolled back.

| App | Stack | Release mode | Deploys | Rollbacks | Requests | Failed |
|---|---|---|---|---|---|---|
| Laravel store | Laravel on nginx | On | 4 | 2 | 2,256 | **0** |
| PHP landing page | Custom PHP on OpenLiteSpeed | On | 3 | 1 | 1,429 | **0** |
| Express app | Node.js on nginx | On | 3 | 1 | 2,400 | **0** |
| Welcome app | Docker container from a Dockerfile | On | 3 | 1 | 2,640 | **0** |
| Flask app | Docker container from the Flask recipe | On | 3 | 1 | 3,760 | **0** |
| WordPress blog | WordPress (Bedrock) from Git on nginx | On | 3 | 1 | 1,520 | **0** |
| Same Express app | Node.js on nginx | **Off** | 3 | 0 | 880 | **27** (502 errors) |

The last row is the one to look at. With Release mode off, each deploy restarted the Express app, and visitors got about a second of 502 errors every time. With it on, the same app deployed three times and rolled back once without a single failed request.

A failed request here means any answer that is not 2xx or 3xx, or no answer at all. Some deploys rebuilt the same commit; each one still built and switched to a new release. We are not publishing response times from this run: one window overlapped a monitoring install on a small test server, so those numbers would not be fair.

## How a Zero-Downtime Deploy Works in xCloud

Release mode never touches the live release until the new one is ready. Every deploy goes through four steps:

1. **Build beside the live release.** xCloud pulls your commit into a new release folder, or builds a new container image, next to the live one. Your deploy script runs there.
2. **Check that it answers.** Node.js apps and containers start on a second port and must pass a health check. PHP and WordPress releases must answer a request. A server error or no answer stops the deploy.
3. **Switch in one step.** For PHP and WordPress, the site folder now points to the new release. For Node.js and containers, nginx sends new requests to the new port.
4. **Finish and restart workers.** The old Node.js process or container finishes its open requests, then stops. Queue workers, Horizon and Supervisor programs restart on the new code.

The pattern behind steps 2 and 3 is known as **[blue-green deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html)**: two copies, one live, and a switch that moves traffic between them.

## Which Stacks Support Release Mode

| Stack | Server | How it switches | Shared by default |
|---|---|---|---|
| Laravel | nginx or OpenLiteSpeed | Site folder points to the new release | `.env`, `storage` |
| Custom PHP | nginx or OpenLiteSpeed | Site folder points to the new release | `.env` |
| WordPress from Git (classic or Bedrock) | nginx | Site folder points to the new release | `wp-config.php` and uploads (Bedrock: `.env` and `web/app/uploads`) |
| Node.js | nginx | New release on a second port, then nginx switches | `.env` |
| Docker container (Dockerfile or app recipe) | Docker server with nginx | New container on a second port, then nginx switches | none: each release reads the site's `.env` |

For **WordPress**, plugins and themes come from your repository while Release mode is on, so installs from the WordPress admin are turned off. The card says so before you turn it on.

## One-Click Rollback That Leaves Your Data Alone

Every deploy shows up on the Release mode card with its commit, who deployed it, how long it took and its result. The newest is marked **Live**. Every other kept release has a **Rollback** button.

![The Release mode releases list in xCloud, with the newest release Live and older releases showing a Rollback button](/_landing/blog/zero-downtime-deploys-and-one-click-rollback-image-2.png)

Click **Rollback** and xCloud asks you to confirm: "The site switches to this release at once. The database, .env and shared files are not changed." That is the important part. A rollback puts your old code back; it never rolls back orders, sign-ups or uploads.

![The Roll back to release confirm dialog in xCloud: the database, .env and shared files are not changed](/_landing/blog/zero-downtime-deploys-and-one-click-rollback-image-3.png)

xCloud keeps the last five releases for PHP, WordPress and Node.js sites, and the last three images for container sites. Rolling back and turning Release mode on or off need the **Manage Deploy Scripts** permission, so a teammate who can only deploy can't roll back.

## Shared Files and Worker Restarts

Files that every release needs live in one shared folder. Laravel shares `.env` and `storage` by default. Under **Shared between releases** you can add your own paths, such as `public/uploads`, and every new release links to them.

On Laravel sites, queue workers and **[Horizon](/docs/set-up-laravel-horizon/)** reload after their current job, and other **[Supervisor programs](/docs/supervisor-for-process-management/)** restart. That happens after every deploy and every rollback, so a background job never runs old code against a new release.

## How to Turn On Zero-Downtime Deploys

1. Open your Git site in xCloud and go to **Git**.
2. Scroll to the **Release mode** card and switch it on.
3. Confirm **Turn on release mode?**. The site stays online while it converts.
4. Deploy as usual with **Deploy Now** or a push to your branch.

![The Turn on release mode? confirm dialog in xCloud: the site stays online while it converts](/_landing/blog/zero-downtime-deploys-and-one-click-rollback-image-4.png)

Creating a new site? In **Deploy via Git**, switch on **Release mode (zero-downtime deploys)** and the site converts after its first successful deploy. You can also turn it on, list releases and roll back from the xCloud Public API or MCP.

👉 Full steps: **[Zero-downtime deploys with Release mode](/docs/zero-downtime-deploys-with-release-mode-in-xcloud/)** and **[How to roll back a deployment](/docs/roll-back-a-deployment-in-xcloud/)**.

## What Release Mode Doesn't Do (Yet)

Honest limits, so you can plan:

- **Rollback doesn't undo migrations.** If a deploy changed the database schema, the older code must still work with it. Our guide to **[zero-downtime deployment strategies](/what-is-zero-downtime-deployment/)** explains the expand and contract pattern.
- **Some setups are not supported yet:** a repository's own **[docker-compose file](/what-is-docker-compose/)**, containers that publish more than one port, WordPress sites not deployed from Git, and Node.js or WordPress on OpenLiteSpeed.
- **A custom pull script must go.** Release mode builds each release from Git itself, so a deploy is refused until the site uses the default pull script. The live release stays untouched.
- **Keep `.env` out of your repository.** Release mode keeps it in the shared folder. On our Node.js test site, a commit that tracked `.env` was refused, with the reason in the deployment log.
- **To turn it off,** switch the card off. The site goes back to its normal folder.

## Ship Your Next Deploy Without Downtime

Release mode removes the riskiest minute of a release: the moment new code meets live traffic. Build beside the live site, check it, switch, and keep a way back. If you run a store, an API or a client site you can't afford to break, turn it on before your next deploy.

See everything it covers on the **[zero-downtime deployments page](/zero-downtime-deployments/)**, host your app on **[Laravel hosting](/laravel-hosting/)** or **[Node.js hosting](/node-js-hosting/)**, and compare plans on **[pricing](/pricing/)**. If a deploy ever does fail, **[why your Git deploy failed on xCloud](/why-your-git-deploy-failed-on-xcloud/)** walks through the usual causes.

**[Start with xCloud](https://app.xcloud.host/register)** and turn on Release mode on your first Git site.

If you have found this blog helpful, feel free to [**subscribe to our blogs**](https://xcloud.host/blog/) for valuable tutorials, guides, knowledge, and tips on web hosting and server management. You can also join our [**Facebook community**](https://www.facebook.com/groups/xcloud.community) to share insights and engage in discussions.

## Frequently Asked Questions

### What is Release mode in xCloud?

Release mode is the dashboard name for xCloud's zero-downtime deployments. When it is on, every Git deploy builds a new release beside the live one, checks that it answers, then switches traffic in one step. Older releases are kept, so you can roll back in one click.

### Which sites can use zero-downtime deploys?

Sites deployed from Git: Laravel and custom PHP apps on nginx or OpenLiteSpeed, WordPress (classic or Bedrock) and Node.js apps on nginx, and Docker container sites built from a Dockerfile or an app recipe. A repository's own docker-compose file and containers that publish more than one port are not supported yet.

### Does a rollback restore my database?

No. A rollback switches your code to an older release. The database, .env and shared files are not changed. If the newer release ran a migration, check that the older code still works with the new schema before you roll back.

### What happens if a deploy fails with Release mode on?

The new release never gets traffic. The deploy is marked Failed, the live release keeps serving visitors, and the deployment log on the Deployments page shows why.

### How many releases does xCloud keep?

The last five releases for PHP, WordPress and Node.js sites, and the last three images for Docker container sites. Any kept release can be rolled back to from the Release mode card.