# Release Mode Messages and Fixes in xCloud

> Every message Release mode (zero-downtime deployments) can show in xCloud, where to find it, and how to fix it: refused turn-on, failed deploys, failed rollbacks and shared path errors.

**Release mode** (zero-downtime deployments) in **[xCloud](/)** refuses anything that could break the live site, and tells you why. This page lists each message, where it appears and how to fix it. For how the feature works, see [How to use zero-downtime deployments](/docs/zero-downtime-deploys-with-release-mode-in-xcloud/).

## Where to find the message

- **Turning Release mode on is refused:** the reason shows on the **Release mode** card (Site → **Git**) under the description, and the switch stays off.
- **Turning it on, a rollback or a shared path change failed:** the card shows "Release mode could not be turned on.", "The rollback to release … failed." or "The shared paths could not be updated.", followed by the reason.
- **A deploy failed:** the card shows only a red **Failed** row in the releases list. The previous release stays **Live**.

![The Release mode card with a red Failed row while the previous release stays Live](/_landing/docs/release-mode-messages-and-fixes-image-1.png)

For a failed deploy, open **Deployments** in the site menu, select the failed deployment, and read **Deployment output**. The line that starts with `Error:` is the reason. The next line, "The live release is unchanged.", confirms that visitors still get the previous release.

![The Deployments page with the failed deployment and its Deployment output](/_landing/docs/release-mode-messages-and-fixes-image-2.png)

More about that page in [How to view Git deployments](/docs/view-git-deployments-in-xcloud/).

## Turning Release mode on is refused

| Message | Fix |
| --- | --- |
| Release mode needs a git-deployed site. | Connect the site to a Git repository first. See [Git integration for an existing site](/docs/set-up-git-integration-for-existing-wordpress-or-php-site/). |
| Release mode is available for Laravel, custom PHP, Node.js and git-deployed WordPress sites only. | Other site types can't use Release mode. |
| Release mode needs an nginx or OpenLiteSpeed server. | Move the site to an nginx or OpenLiteSpeed server. |
| Node.js release mode needs an nginx server. | Node.js sites need an nginx server. |
| WordPress release mode needs an nginx server. | WordPress sites from Git need an nginx server. |
| Release mode needs a WordPress site that is deployed from git (for example a Bedrock repository). WordPress installed by xCloud keeps its plugins and themes in the site folder, so it cannot use release mode. | Deploy WordPress from a Git repository that holds core. See [WordPress from Git](/docs/zero-downtime-deploys-for-wordpress-from-git/). |
| Release mode on OpenLiteSpeed needs xCloud to manage this site's vhost; turn automatic vhost regeneration back on first. | Turn automatic vhost regeneration back on for the site, then try again. |
| Docker Compose sites cannot use release mode: the compose project is named after the site directory, so a release switch would start a second stack. | Not supported. Container sites can use Release mode when they are built from a Dockerfile or an app recipe. |
| Release mode supports container sites built from a Dockerfile (the repository's own or an app recipe). This site runs its repository's compose file, which has no web service xCloud can name. | Not supported for sites that run the repository's compose file. |
| Release mode supports one published port; this site publishes … | Publish one port only. |
| Ask a team admin with the deploy-settings permission to turn release mode on or off. | You need the **Manage deploy scripts** permission. See [who can change a deploy script](/docs/team-roles-permissions-in-xcloud/#who-can-change-a-deploy-script). |

The deploy rules below also block turning Release mode on, so the card can show any of them too.

## Turning Release mode on failed

| Message | Fix |
| --- | --- |
| WordPress core is not in the repository (xCloud's Git setup leaves it out), so release mode cannot build a release from it. Commit WordPress core (…), then try again. | Commit WordPress core, including `wp-settings.php`, to the repository, deploy, then turn it on again. |
| composer.json is not in the repository, so release mode cannot build a release from it. Commit your Bedrock project (composer.json), then try again. | Commit the whole Bedrock project. |
| Cannot find … where release mode expects it. Set the shared paths for this site, then try again. | The WordPress content folder is not where the layout expects it. Check the site's web root and layout. |
| … is a link to …; release mode needs it to be a real file or directory. | Replace the link in the site folder with the real file or folder. |
| The site's container is not running on port …. Deploy the site, then turn release mode on. | Deploy the container site so it runs, then turn Release mode on. |

## A deploy was refused

These show in the **Deployment output** and on the card while Release mode is off.

| Message | Fix |
| --- | --- |
| This site has a custom pull script. Release mode creates each release from git itself, so remove the pull script, then deploy again. | In **Git Settings**, go back to the default **Git Pull Script**, save, and deploy again. If clearing the box doesn't remove it, paste the default script text and save. |
| This site has no git branch set. Set the branch in the Git settings, then deploy again. | Set **Git Branch** in Git Settings. |
| The deploy script uses the live site path or git pull on line …, which would change the live release instead of the new one. Use $PROJECT_DIR for paths and remove git pull there, then deploy again. | Edit the named lines of the **Deploy Script**. |
| The deploy script changes PM2 processes on line …. Release mode starts and drains processes itself. Remove those commands and use the start command setting. | Remove `pm2` commands from the deploy script (Node.js). |
| The deploy script runs its own commands; release mode builds and starts the container itself. Reset it to the default, then retry. | Reset the deploy script to the default (container sites). |
| Another clone or deploy is running for this site. Wait for it to finish, then retry. | Wait, then deploy again. |

## A deploy failed before going live

In each case the new release never went live, and the previous release keeps serving visitors.

| Message | Fix |
| --- | --- |
| The commit tracks .env; release mode keeps it in …. Remove it from the repository, then deploy again. | Remove `.env` from the repository and add it to `.gitignore`. The same applies to any other shared path the repository tracks. |
| The commit does not track …: WordPress core must be in the repository for release mode. | Commit WordPress core (or your Bedrock `composer.json`). |
| The deploy script failed (exit …); its output above has the cause. | Read the lines above it in the output and fix the command. |
| php artisan --version failed in the new release. | The Laravel app doesn't boot. Check `composer install` and the shared `.env`. |
| Smoke check failed: GET / on the new release answered … (needs below 500 within 10 seconds). | The new release returns a server error on `/`. Fix the error and deploy again. Check the site's logs for the cause. |
| The new Node process failed its health check (HTTP …; needs an answer below 500). | Make the app read `PORT`, listen on `127.0.0.1` and answer `/` without a 5xx. See [Node.js apps](/docs/zero-downtime-deploys-for-node-js-apps/). |
| The Node install or build failed. | Read the install and build output above it. |
| A custom ecosystem.config.js file is not supported in release mode. Use the start command setting instead. | Remove the ecosystem file and set the start command in xCloud. |
| The static release has no index.html. | Check the build output folder of the static app. |
| The new container failed its health check (HTTP …; needs an answer below 500). Its last log lines: | Read the container log lines that follow, fix the app and deploy again. |
| The image build failed; its output above has the cause. | Read the build output and fix the Dockerfile. |
| Branch … was not found on the remote. | Check the branch name in Git Settings. |
| Only … KB free on the disk; a new release needs at least twice the current release (… KB). | Free disk space on the server. |

![A Node.js site whose repository tracks .env: the deploy failed and the converted release stays Live](/_landing/docs/release-mode-messages-and-fixes-image-3.png)

## A rollback failed

| Message | Fix |
| --- | --- |
| Release … is not on the server; pick a release that is still kept. | Pick a newer release. Older ones are removed after new deploys. |
| Release … never went live (its build failed or was interrupted); pick a release that was live before. | Pick a release that shows **Deployed**, **Rolled back** or **Converted**. |
| Release … is already live. | Nothing to do. |

See [How to roll back a deployment](/docs/roll-back-a-deployment-in-xcloud/).

## Shared path errors

| Message | Fix |
| --- | --- |
| … is an absolute path. Use a path inside the site, such as storage or public/uploads. | Use a path relative to the site folder. |
| … must be a clean path inside the site: no '..', '.' or empty parts. | Remove `..`, `.` and double slashes. |
| … may use only letters, numbers, dots, dashes and underscores. | Rename the folder or pick another one. |
| … cannot be shared: .git is the site's repository. | Don't share `.git`. |
| … is the site's web root (or holds it), so it cannot be shared. | Share a folder inside the web root, such as `public/uploads`. |
| … is inside …, which is shared too. Share one of them. | Keep only the outer or the inner path. |
| At most 50 shared paths per site. | Remove paths you don't need. |
| A container site shares no paths: each release's container reads the site's .env from its own folder. | Container sites don't use shared paths. |

See [Shared files and folders in Release mode](/docs/shared-files-and-folders-in-release-mode/).

## Other messages

- **"Another release mode change, rollback or deploy is still running for this site. Wait for it to finish, then try again."** Only one change runs at a time per site. Wait and try again.
- **"Warning: … The release is live; restart this by hand if the workers still run the old code."** The deploy worked, but a queue worker, Horizon or Supervisor program did not restart. Restart it from [Supervisor](/docs/supervisor-for-process-management/).
- **"ERROR: cannot change the domain of …: it uses zero-downtime deploys, and renaming those sites is not supported yet. Nothing was changed."** Turn Release mode off before you change the site's domain, then turn it on again.

## Frequently asked questions

### My Release mode card shows a red Failed row. Where is the reason?

Open the site's Deployments page, select the failed deployment and read Deployment output. The line that starts with Error: is the reason, and the next line, The live release is unchanged., confirms visitors still get the previous release.

### Is my site down when a deploy fails in Release mode?

No. A failed release never goes live. The release that was live keeps serving visitors until a deploy succeeds or you roll back.

### Why can't I turn Release mode on?

The card shows the reason under its description while the switch is off, for example a custom pull script, a server type that is not supported, or deploy script lines that use the live site path. Fix what it names and reload the page.

## Related guides

- [How to use zero-downtime deployments (Release mode)](/docs/zero-downtime-deploys-with-release-mode-in-xcloud/)
- [Troubleshooting Git deployments](/docs/troubleshooting-git-deployments-stuck-failed-or-not-triggering/)
- [How to view Git deployments](/docs/view-git-deployments-in-xcloud/)

If a Release mode message is not on this page or the fix doesn't work, feel free to reach out to our [support team](/docs/access-built-in-support-portal-in-xcloud/).