SupportConsole
llms.txtSign in

Deploy without downtime and roll back to an earlier release

llms.txt

A normal deployment updates the files of a live site while visitors are using them: for a minute the code is half old and half new, and Composer or a build step can leave the site broken. A zero-downtime site avoids that. Every deployment builds the new version in a fresh folder next to the old one, runs your script there, and only when everything has succeeded does SrvYard point the site at the new folder, in a single atomic step. If anything fails before that step, visitors never see it.

The same layout gives you rollbacks: the previous versions are still on the server, so going back means pointing the site at an older folder. This article explains the layout, what the deployment status and the Live badge mean, how to roll back, and what a rollback cannot do (it does not undo database changes).

Before you begin

  • A zero-downtime site. This is chosen when the site is created (Zero downtime deployments in the advanced settings) and cannot be changed afterwards. The Strategy line of the Source card on the Deployments tab says Zero downtime or In place. See Create a site on your server.
  • At least two releases. A rollback needs an earlier finished release that is still on the server.
  • The permission to manage deployments. Members who can only view see the history but not the Roll back to this action.
  • Octane is not compatible. Octane keeps the application in memory and cannot follow the switch. See The Laravel panel.

1. How the folders are laid out

On the server, a zero-downtime site lives under its own folder, for example /home/srvyard/api.harborlane.example:

Folder What it holds
releases/20261022135404 One folder per deployment, named after the date and time it was made (year, month, day, hour, minute, second)
shared Files that survive every release: the .env, storage, anything you added as a shared path
current A link to the release being served now

Nginx serves current, so changing where that link points changes the version visitors get. Your deploy script runs inside the new release folder, with $SRVYARD_RELEASE_DIRECTORY pointing at it (see Write and test a deploy script).

The Source card showing the strategy
The strategy and the number of releases kept are on the Deployments tab.
  1. Strategy. Zero downtime here. A site that deploys in place shows In place and has no releases.
  2. Releases kept. How many release folders exist now, out of the limit (for example 5 of 5).
  3. The limit. A link to the retention setting in Settings > Deployments (1 to 50). After a successful deployment SrvYard deletes releases beyond it. The live release and the one before it are never deleted.

2. What a deployment does, in order

  1. Prepares the server and makes a fresh shallow clone of the branch into a new folder under releases.
  2. Links the shared paths into the new folder.
  3. Runs your deploy script inside it: Composer, the front-end build, artisan migrate, caches. The live site is untouched meanwhile.
  4. Activates the release. SrvYard creates a new link and renames it over current, which is atomic: there is no moment without a valid current. It then removes releases beyond the retention limit and reloads PHP-FPM so the opcode cache follows the new path.
  5. Runs the health check, if it is on, and records the result.

Because the switch is the second to last step, a failure in steps 1 to 3 leaves the old release live. SrvYard also removes the half-built release folder. Two things can still go wrong after the switch: the health check can fail (the release is live, the deployment is marked failed) and a migration that already ran stays applied.

The deployment history
Each row is a release; the Live badge marks the one served now.
  1. The live release. The row with the Live badge. Only one row has it at a time.
  2. An earlier release. Finished rows are the ones you can go back to.
  3. A removed release. A release name that is struck through has been deleted by retention. It cannot be rolled back to, but the row, its commit and its log stay in the history.

A Cancelled row is a deployment that was stopped before the switch; it never went live.

3. Roll back to an earlier release

Open the row menu of the release you want.

The row menu with Roll back to this
Roll back to this is offered on finished releases that are still on the server.
  1. Roll back to this. Only on a finished deployment whose release folder still exists and which is not already live, on a site that deploys with zero downtime and whose server is ready. In other cases the menu does not offer it, and the details page says why: "Only zero-downtime sites keep earlier releases to roll back to.", "This release is already live." or "This release was removed when older releases were pruned."

You can also open the deployment and press Rollback at the top right of its page.

The rollback confirmation
The confirmation reminds you that migrations are not undone.
  1. Roll back. Confirms. The dialog is titled "Roll back to release ..." and says "The site switches back to (the commit) instantly. The deploy script does not run, so database migrations are not undone."

What happens next:

  • SrvYard records a new deployment with the trigger Rollback, copying the commit, branch and release of the one you chose, and queues it like any other (it waits if another deployment is running).
  • It re-points current at the old release folder with the same atomic step as a normal deployment, without pruning and without running any script, and reloads PHP-FPM.
  • The health check then runs again. The log ends with "Rollback finished."
  • The Live badge moves to the release you went back to.
A rollback in the history
A rollback is recorded as a deployment whose trigger is Rollback.
  1. Triggered by. Rollback, with the name of the person who pressed the button.
  2. Rollback. The button of the page header. It is the same action for the release you are looking at.

A rollback has no Build logs: "A rollback does not build anything: it switches back to a release that was built before."

Warning

A rollback does not undo database migrations. If the release you are leaving added a column or dropped a table, the older code now runs against the newer schema. Write migrations so that the previous version still works with them (add columns before you use them, remove them one release later), or reverse the change by hand.

Important

The .env and storage are shared, so a rollback keeps your current environment values and files. If the newer release needed a new environment variable, the older one simply ignores it; if the older release needs a value you have since removed, add it back.

4. Going forward again

A rollback does not change your Git branch. The next push (with push to deploy) or Deploy now deploys the tip of the branch again, which may be the commit you just left. To stay on the older version, revert the bad commit in Git and push, or switch off push to deploy until the fix is ready.

For a site that deploys in place, there are no earlier release folders: revert the commit in Git and deploy again. SrvYard says so: "Only zero-downtime sites keep earlier releases to roll back to."

Troubleshooting

  • "Roll back to this" is missing or greyed. The row is not a finished deployment, the release was removed, it is already live, or the site is in place. The details page names the reason.
  • "The release ... no longer exists on the server". The folder was deleted by hand or by retention after the page loaded. SrvYard marks the release as removed. Choose a newer one.
  • "... is a real directory, not a symlink. Move it away and deploy again". The site's current folder was created by hand. Move it aside on the server and deploy once.
  • The old release is live but the site is still broken. The problem is in shared state: the .env, the database, a cache or a queue payload from the newer code. Fix those, then restart the workers.
  • A deployment is stuck as Queued after a rollback. Only one deployment per site runs at a time. Cancel the one that is running or wait for it. See Read a deployment log and find the failing step.
  • The disk fills up. Every release is a full copy. Lower Deployments to keep, or build assets in CI so releases are smaller.
Last updated 2026-10-247 min readNeed help? Contact support
PreviousDeploy automatically on every pushNextRead a deployment log and find the failing step