Setting up atomic deployments

In DeployHQ, you can setup atomic deployments to your servers to ensure that there is zero downtime during the actual deployment process.

You'll be able to find out useful information about how the process works and how to set it up below.

How it works

When you first run an atomic deployment to your server, DeployHQ will prepare 2 directories within your deployment path:

  • releases
  • shared

And one symlink:

  • current

That points to a folder within the releases directory, named as a timestamp from when you ran the associated deployment.

Your files will be uploaded to that directory, then once this process has finished, the current directory will be symlinked to that release. This is where your live app will be run from.

The current symlink will therefore look like so:

current -> releases/20190123120000

This will also happen in exactly the same way during any subsequent deployments, but because the symlink doesn't get created until after files are transferred, your site will continue to run in its previous state.

Additionally, if the deployment fails at any point before that time, the site will stay pointed to the last release, completely unaffected.

Setting up an atomic deployment


To start using Atomic deployments, you'll need to add a new server to your project which supports SSH access, with the ability to run POSIX operations (for both copying, and symlinking to release directories).

Adding an atomic server

Just configure a new SSH server as normal, but then also enable the option for Zero-downtime deployments at the same time:

Zero-downtime option

Once you've added your server, you'll need to run a full deployment as normal on the first deployment, so that the correct directories are prepared and a full copy of your site is uploaded to it.

After that, only your changes will be uploaded but onto a new, full copy of the last release on every subsequent deployment.

Using Atomic deployments with server groups

Atomic deployments are fully supported for server groups too, and with this in mind, you can also now set up different deployment strategies when configuring a server group.

You'll see two options, sequential or parallel when you're setting up a group:

Sequential and parallel deployments

Sequential will deploy to each server in turn, whereas parallel will deploy to each server at the same time (up to 3 at once), ensuring that each step is completed on all servers before moving onto the next step.

Therefore, when using atomic deployments with a server group it is strongly recommend that you use the parallel strategy.

Further reading

Some useful information about the process:

  • DeployHQ will only keep 3 releases (the current, and 2 previous ones) on your server, and automatically tidy up older releases during the deployment process.
  • At present, atomic deployments are only supported on SSH servers, when you first add a new server to your project.
  • You can use the shared directory to keep files in that you want to be persisted across all releases, such as user uploads or config files.