Automate

v5.0.1 MIT licensed · Zero-downtime deployments

Deploy to your servers with one command.

Describe your platforms and servers in a single YAML file. Automate clones your repository, runs your build, and switches the release atomically, from your workstation or from your CI.

$ curl -LSs https://www.automate-deployer.com/install | bash
Get started View on GitHub
.automate.yml
repository: git@github.com:acme/shop.git

platforms:
    production:
        default_branch: main
        max_releases: 5
        servers:
            web-01:
                host: web-01.acme.io
                user: deploy
                ssh_key: /home/me/.ssh/id_ed25519
                path: /var/www/shop
            web-02:
                host: web-02.acme.io
                user: deploy
                ssh_key: /home/me/.ssh/id_ed25519
                path: /var/www/shop

shared_files: [.env.local]
shared_folders: [var/uploads]

on_deploy:
    - composer install --no-dev --optimize-autoloader
post_deploy:
    - cmd: php bin/console doctrine:migrations:migrate -n
      only: [web-01]
  1. 1

    Describe

    One .automate.yml at the root of your project lists your platforms, servers, shared files and hooks.

  2. 2

    Deploy

    automate deploy production connects to every server over SSH and prepares a new release in parallel.

  3. 3

    Switch

    When every hook succeeded, the current symlink is moved. Visitors never see a half-deployed app.

Everything a deployment needs, nothing more

Automate does one thing: ship a Git repository or a CI build to Linux servers, safely and repeatably.

Atomic releases

Each deployment lives in its own timestamped folder. A single symlink switch publishes it, so there is no partial state.

Zero downtime

The previous release keeps serving traffic until the new one is complete. A failed deployment never goes live.

Many servers, one run

Hooks run in parallel on all the servers of a platform. Restrict any command to specific servers with only.

Shared files and folders

Keep .env.local, uploads or caches between releases. Automate links them into every new release.

Git, CI build, or both

Clone the repository on the server, upload the artifacts built by your CI, or mix both strategies.

Any stack

PHP, Node, Ruby, Python, static sites: if it runs on a Linux server, Automate can deploy it. A single binary, no runtime needed.

What happens on the server

A layout you can inspect and understand, inspired by Capistrano.

  1. Lock the platform so two deployments never overlap.
  2. Clone the repository into a new release folder and check out the requested branch, tag or commit.
  3. Run your pre_deploy, on_first_deploy and on_deploy hooks.
  4. Link shared files and folders into the release.
  5. Publish by pointing current to the new release, then run post_deploy.
  6. Clean up old releases beyond max_releases.
Read about the deployment lifecycle
/var/www/shop
/var/www/shop
├── current -> releases/2026.10.23-1412.587
├── releases
│   ├── 2026.10.21-0930.112
│   ├── 2026.10.22-1805.341
│   └── 2026.10.23-1412.587
│       ├── .env.local -> ../../shared/.env.local
│       └── var/uploads -> ../../../shared/var/uploads
└── shared
    ├── .env.local
    └── var/uploads
.github/workflows/deploy.yml
deploy:
    runs-on: ubuntu-latest
    steps:
        - uses: actions/checkout@v4
        - name: Install Automate
          run: curl -LSs https://www.automate-deployer.com/install | bash
        - name: Deploy
          run: ~/.automate/bin/automate deploy production
          env:
              AUTOMATE__prod_password: ${{ secrets.PROD_PASSWORD }}

Works where you work

Run Automate from your terminal, or from GitHub Actions, GitLab CI or any runner. Secrets are read from environment variables, never written to disk.

See the CI integration guide

Ready to deploy?

Install Automate, write your first .automate.yml and ship in five minutes.

Read the quick start Browse the configuration reference