Deploy with zero downtime using Launchdeck’s atomic deployments strategy.

What’s “atomic deployment”?

Generally speaking, the deployment process entails uploading each file individually to your server. This method is utilized when you’re using FTP or SFTP deployments. This “incremental” deployment strategy may cause your website or application to incur downtime or to enter “maintenance mode” temporarily, when only some of the application sources have been updated while the upload process is running.

Given that you have full SSH access to your server, it’s possible to perform "atomic deployments", this means you can deploy with zero downtime. Your application or site won’t suffer from any downtime, and the new version will go live instantaneously, only once the entire deployment has been completed successfully.

How does “atomic deployment” work?

You’ll notice that during the first zero downtime deployment, two directories and a symlink will be added to your “installation path”.

Zero downtime atomic deployment

  • releases
    • This folder will hold the latest version, as well as the 4 other most recent releases on your server. Each version (release) has a unique timestamp-based ID generated as a part of the build- and transfer-phase. This also facilitates our zero downtime rollback function.
  • current
    • This is simply a symlink to the currently “active” release in the releases folder. You should make sure the server webroot points to this path, or a subdirectory within it. Launchdeck allows you to set this up automatically using the “link webroot” functionality in your server settings.
  • shared
    • This is where shared files and directories will be kept - the ones that should persist throughout multiple releases. Each release contains symlinks - automatically created by Launchdeck - at the appropriate paths to the corresponding paths in “shared”. More on this in the remainder of this article.

In short, for every “zero downtime deployment”, a full copy of the release (the sources in your repository and, if applicable, any files or artifacts generated during the build phase) will be transferred to your server as a tar.gz archive and extracted remotely. Once transferred and extracted, this is the new release containing the new version of your application.

Thus far, nothing has visibly changed from the “outside”, it’s only once you hit 'publish' that the “current” symlink will be updated to point to this new version.

Before ‘Publish’, your current symlink looks like this:

current -> releases/current-release-id

After ‘Publish’:

current -> releases/new-release-id

With each subsequent deployment, this is done the same way - a new release is uploaded to your server, and the symlink is updated once you hit the 'Publish' button. If anything goes wrong during the build or transfer, the new release will not be made available. In case something goes wrong during the publish step, your live site continues to reference the current version, unaffected.

How to set up zero downtime / atomic deployments?

A requirement for atomic deployments is that you have SSH access to your target server, including the ability to execute SSH commands on your server for the purpose of extracting the releases, and creating symlinks.

You can verify this by logging into your server and running the following command from the terminal;

$ tar --help

If the documentation appears this generally means you have the prerequisite access.

Adding an SSH server

Hit ‘+ new server’, select the SSH server type, and enter the credentials facilitating access to your server.

For security, we recommend creating a separate user to use for deployments.

sudo adduser launchdeck
sudo usermod -a -G www-data launchdeck

More information on how to configure your server can be found in our SSH server configuration docs.

Using shared paths

In many instances there will be files or folders that need to be persisted throughout builds. Think of wp-uploads, or some asset/uploads folder.

You can specify these shared paths in the build commands editor - Launcheck will create them on your server within the shared directory. All such paths will be symlinked to the corresponding paths in every release (with an identical hierarchy). If these directories or files are also present in your repository, they will be overwritten. We recommend making sure the shared paths are not present in your repository.

Let's say that you have set up a server with an installation path of /var/www/my-app, and specify web/wp/uploads as a share. 

What Launchdeck will do once a new build is transferred is create a symlink, and it'll look like so:

## Path in shared:
/var/www/my-app/shared/web/wp/uploads

## Symlinked to latest release:
/var/www/my-app/releases/12345678/web/wp/uploads

For example, if you have populated your development environment (or repository) with data such as images added through a CMS, you may upload these files directly to your shared folder after the first release has been transferred.

More information on how to configure shared files can be found in our build automation docs under the section ‘Shared’.

Learn more:

  • Because of how Laravel applications work, deploying them using the atomic deployment strategy is recommended. Check out our guide on how to deploy Laravel with zero downtime.
  • Launchdeck will only keep 5 releases (the current, and 4 previous ones) on your server, and automatically tidy up older releases during the deployment process. 

A better way to deploy code

Get started for free

Free • Simple setup • Cancel any time

A better way to deploy code

Get started for free

Free • Simple setup • Cancel any time

A little bit about the author
Webdesigner and front-end developer. Marketing, UI, UX & SEO enthusiast. Likes to delete buttons, features and settings for a more intuitive design. Life motto: Less is more.