Every release, one click away
Each deploy is listed with its commit, who deployed it and how long it took. The newest is marked Live. Every kept release has a Rollback button.
Release mode for Git sites
Zero-Downtime Deployments: Deploy Without Downtime, Roll Back in One Click
xCloud builds every Git deploy beside your live site, checks that the new release answers, then switches traffic in one step. If a release misbehaves, roll it back in one click. Turn on Release mode from the dashboard for Laravel, PHP, WordPress, Node.js and Docker sites, with no YAML to write.
Get started- Visitors never see a half-deployed site
- One-click rollback to a kept release
- A release that fails its check never goes live
- No pipeline or YAML to maintain
HOW IT WORKS
How a Zero-Downtime Deploy Works
A normal deploy changes files in the folder your visitors are using, or restarts the app they are talking to. Release mode never touches the live release until the new one is ready.
Build beside the live release
xCloud pulls your commit into a new release folder, or builds a new container image, next to the one that is live. Your deploy script runs there while visitors keep using the live release.
Check that it answers
Before it gets any traffic, the new release must answer a request. Node.js apps and containers start on a second port and pass a health check. A release that answers with a server error, or not at all, is never switched in.
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. There is no moment where half the files are new.
Old process finishes, workers restart
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 old release is kept for rollback.
SUPPORTED STACKS
Which Sites Can Deploy Without Downtime?
Any site you deploy from Git on these stacks can turn on Release mode. Each stack switches the way that suits it.
Laravel
On nginx or OpenLiteSpeed. .env and storage are shared between releases, and queue workers and Horizon restart on the new code after each deploy.
PHP apps
Any custom PHP app deployed from Git, on nginx or OpenLiteSpeed. Add folders such as public/uploads to the shared list so they survive every release.
WordPress from Git
Classic and Bedrock layouts on nginx. wp-config.php (or .env for Bedrock) and uploads are shared. Plugins and themes come from your repository while Release mode is on.
Node.js
Node.js apps on nginx. The new release starts on a second port, passes a health check, then nginx switches over and the old process finishes its requests.
Docker containers
Sites built from your repository's Dockerfile or an app recipe such as Flask. The new container starts beside the old one and takes over after its health check.
Not covered yet
A repository's own docker-compose file, containers that publish more than one port, and WordPress sites not deployed from Git. Node.js and WordPress need an nginx server.
ROLLBACK AND SHARED FILES
One-Click Rollback, Without Touching Your Data
Everything lives on the Release mode card under Site → Git. These are real screens from an xCloud test site.
Rollback changes code, not data
Confirm the rollback and the site switches to that release at once. The database, .env and shared files are not changed, so a rollback never loses an order or an upload.
Shared files stay in one place
Files every release needs, such as .env, storage and uploads, live in one shared folder. Add your own paths, for example public/uploads, and every new release links to them.
ON EVERY DEPLOY
What Else Release Mode Takes Care Of
The parts of a deploy that usually need a runbook.
Failed deploys never go live
If the build or the check fails, the deploy is marked Failed and the live release keeps serving. The deployment log shows why.
Workers run the new code
Queue workers, Horizon and Supervisor programs restart after every deploy and rollback, so background jobs never run old code against a new release.
Releases are kept for you
xCloud keeps the last five releases of PHP, WordPress and Node.js sites, and the last three images of container sites, and removes older ones.
Rollback follows team roles
Turning Release mode on or off and rolling back need the Manage Deploy Scripts permission, so not every teammate who can deploy can roll back.
On from the first deploy
Switch on Release mode (zero-downtime deploys) when you create a Git site, and the site converts after its first successful deploy.
Public API and MCP
Turn it on or off, list releases and roll back from the xCloud Public API or from an AI tool connected through xCloud MCP.
LAB PROOF
6 Apps, 19 Deploys, 7 Rollbacks: 0 Failed Requests
We deployed six demo apps on xCloud test servers while each one served steady traffic, then ran the same Node.js app with Release mode off for comparison.
| 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) |
Measured on 10 November 2026 on three xCloud test servers (nginx, OpenLiteSpeed, Docker), with demo apps from public sample repositories. Each site got a steady 8 requests a second over HTTPS during its own turn-on, deploys and rollbacks. A failed request is any answer that is not 2xx or 3xx, or no answer. Some deploys rebuilt the same commit; each still built and switched to a new release. With Release mode off, every deploy restarted the app and visitors got about a second of 502 errors.
NO YAML, FROM THE PANEL
Zero Downtime Without Writing the Plumbing
You can build all of this yourself on any Linux server. This is the list of jobs, and what Release mode does instead.
Scroll the table sideways to compare.
| Scripting it yourself | With Release mode in xCloud |
|---|---|
| Write a deploy script that builds into a new folder, links it live and cleans up old releases. | Turn on Release mode. Each deploy builds beside the live release, and old releases are removed for you. |
| Add a health check, and stop the switch when the new code fails it. | Every release is checked before it gets traffic. One that fails never goes live. |
| Run two copies of a Node.js app or container on two ports and flip the nginx upstream. | Node.js and container releases start on a second port. nginx switches after the check passes. |
| Restart queue workers and Supervisor programs so they pick up the new code. | Workers, Horizon and Supervisor programs restart after every deploy and rollback. |
| Keep .env and uploads outside the release folders, and link them into each one. | Shared files and folders: .env and storage by default, plus any path you add. |
| SSH in and relink the previous release when a deploy goes wrong. | Click Rollback on any kept release in the dashboard. |
GET STARTED
Turn On Zero-Downtime Deployments in 3 Steps
Release mode works on sites you deploy from Git, on a server you bring or one xCloud manages.
Deploy your site from Git
Create a site from your GitHub, GitLab or Bitbucket repository, or use a Git site you already have.
Turn on Release mode
Open Site → Git, find the Release mode card and click Turn on. The site stays online while it converts.
Deploy as usual
Click Deploy Now or push to your branch. Each deploy becomes a new release, and Rollback is one click away.
Step-by-step guides: zero-downtime deploys with Release mode, roll back a deployment and deploy a Git project. Related: One-click Git deployment, Laravel hosting, Node.js hosting, Docker hosting, Pricing.
Zero-Downtime Deployment FAQs
How Release mode works, what it covers and what it leaves alone.
What is a zero-downtime deployment?
A zero-downtime deployment puts new code live without a moment where visitors get errors or a half-updated site. The new version is built and checked beside the running one, and traffic moves to it only when it is ready. xCloud does this with Release mode.
Which sites can use zero-downtime deployments on xCloud?
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.
Does a rollback undo my database changes?
No. A rollback switches your code to an older release. The database, .env and shared files are not changed. If a deploy ran a migration, make sure the older code still works with the new schema before you roll back.
What happens when a deploy fails?
The new release never gets traffic. The deploy is marked Failed, the live release keeps serving, and the deployment log shows the reason, so you can fix it and deploy again.
How many releases does xCloud keep for rollback?
The last five releases for PHP, WordPress and Node.js sites, and the last three images for Docker container sites. Older ones are removed after a deploy.
How do I turn on Release mode?
Open your site, go to Git and click Turn on in the Release mode card. You can also switch on Release mode (zero-downtime deploys) when you create a Git site, or use the xCloud Public API.
Do I need Docker, Kubernetes or a CI pipeline?
No. Release mode runs on your xCloud server for PHP, WordPress and Node.js sites without containers. There is no YAML file or pipeline to write: you turn it on from the dashboard.
Ship Your Next Deploy Without Downtime
Deploy from Git, turn on Release mode, and keep a one-click rollback for every release.