How do SFTP deployments work?

Firstly, DeployBot offers two kinds of SFTP deployments: file deployments and atomic deployments. File deployments upload files directly to the directory that you specify. They iterate over changes since the last deployed Git commit in lexicographical order removing or uploading files one-by-one as an FTP/SFTP client would.

Atomic deployments work differently. They maintain a special directory structure on your server that allows DeployBot to store last N releases and switch between them using symlinks. This is why atomic deployments are often referred to as zero-downtime deployments.

What gets changed?

We only update changed files in your Git repo since the last deployment. But, if you’re using build tools, all build artifacts such as minimized assets, etc. (and only build artifacts) are deployed from scratch every time.

What is the order of events?

File SFTP deployments have pre- and post-deployment commands. Those run on the server against the live version, before or after the file transfer.

Atomic SFTP deployments have post-upload commands, but they don’t have pre-deployment commands since atomic uploads are non-intrusive. These run on the server against the newly uploaded version. Additionally, atomic deployments allow you to specify commands to run when a newly uploaded version becomes active.

How exactly do atomic deployments work?

To provide seamless version rollouts, atomic deployments have to maintain a special directory structure on your server:

releases — contains cached copies of your releases including the currently active release.
deploy-cache — contains the last uploaded state. Manually modifying this directory will break your deployments.
shared — contains your shared resources: user-uploaded content, file caches, etc.
current — a symbolic link to the currently active release from the releases directory.

These directories will be created in the destination path specified in atomic server settings. When you trigger a deployment, the following actions take place:

DeployBot makes sure all the directories mentioned above exist and creates the missing ones.
DeployBot updates the copy of your code in a cache directory on your server.
When the code is updated, DeployBot copies that code to a separate release directory.
In the release directory, DeployBot executes user-specified post-upload commands to get code into shape — like installing application dependencies or linking shared resources.
Once the release is ready, the current symlink is updated to point to a new release directory.
User-defined commands are then executed to restart your application server, prune caches, or notify external services.
DeployBot removes previous versions of your apps from the releases directory, keeping only a fixed number of newest ones. This number is configurable via advanced server settings.

Please note: We don’t support SFTP deployments to Windows hosts.