Build your updater.config.json

Each update runs these steps in order

1. 1Repository

   Where the code comes from.

   Clone URL Branch Provider Detect from the URL GitHub GitLab Plain Git Access token For private repositories. Write ${NAME} and put the value in the environment or .env. API URL Only for GitHub Enterprise or self-hosted GitLab.

2. 2What to deploy

   The newest commit of the branch, or the newest release tag.

   Follow

   Every commit on the branch Release tags only

   Tag pattern The newest version number among matching tags wins. Include prereleases such as v2.0.0-rc.1 Deploy only signed commits or tags Allowed signers file For SSH signatures; GPG signatures use the keyring of the user running the updater.

3. 3Checkout and install

   The directory your service runs from. The updater creates it on the first run.

   Workspace directory Shallow fetch (smaller, but no install skipping) Install dependencies Install command When When a lockfile or manifest changed After every update

4. 4Before the switch

   Runs in the workspace before the new code is checked out. If it fails, nothing changes.

   Pre-update command Time limit per command (seconds)

5. 5Restart

   How the new version starts.

   Service type PM2 process systemd unit Docker container Docker Compose service Custom command Nothing to restart Name Compose file Compose service Restart command Required for a custom command; replaces the built-in restart for the other types. Run the built-in restart with sudo -n

6. 6Health check

   Proves the new version works. Leave both empty to skip it.

   URL that must answer Expected status Command that must succeed Retries Seconds between tries Wait before the first try

7. 7Finish or roll back

   After a successful check the post-update command runs. After a failure the previous commit comes back.

   Post-update command Roll back when install, restart or the health check fails

Around the deployment