Deploying and rolling back

Every finished build of your app deploys by itself, and visitors never see it down. The new version starts beside the old one, must answer its health check, and only then gets the visitors. If anything fails on the way, the version before keeps serving.

How code arrives

• GitHub: pick a repository and branch on the app's Code card. With Build every time I push on, each push starts a build.

• A ZIP file: upload one on the Code card. A dropped connection carries on where it stopped when you choose the same file again.

• A deploy address: for a pipeline that deploys after its tests pass (below).

Each arrival is kept as a version, and you can build any of them again.

The steps of a deploy

The deployment's page follows each step live:

1. Get the code

2. Install packages

3. Build

4. Before going live, when you set a command

5. Health check

6. Send visitors to the new version

The build log streams line by line: our own steps in plain words, like "Installing PHP 8.4 with Composer 2.10.3", then your commands' own output. A build may take up to 15 minutes, with 2 GB of memory or your app's memory limit if that's higher. Builds take turns, one at a time where your app runs, so a build never slows the apps that are running.

Before going live

An optional command that runs once per deploy, in its own sandbox, from the new version with your app's variables and storage, before any visitor sees it. Set it in Build and run, under Before going live, or as release in tanzahost.json:

php artisan migrate --force

It must be one line: join several commands with &&. If it fails, the deploy stops, the old version keeps serving, and the deployment shows the command's last lines.

The health check

We ask the new version for its health address, "/" unless you choose another like /up, every second, until it answers with a success (a status from 200 to 399). It has 2 minutes. Then visitors switch to it in one step, and the old version gets 10 seconds to finish its requests before it stops.

A version that never answers is removed, and the deployment shows its last 50 log lines, so you can see why.

Watched for 5 minutes

If the new version stops by itself within 5 minutes of going live, visitors go back to the version before, and you're told under the bell. That's why a bad push rarely shows to anyone.

Crashes

A process that stops is started again after 1, 2, 4 seconds and longer, up to a minute apart. If it stops 5 times within 10 minutes, we stop trying: the app shows This app keeps crashing with its last lines, and you're told. Fix the problem and deploy, or choose Start it again.

Roll back

Open the project's Deployments tab. Every deployment of the project's apps is listed, newest first. Open the menu of an earlier one and choose Roll back to this. That build deploys again with no downtime, as any deploy does.

Each app keeps two good builds ready: the live one and the one before it, so that's the one that can come back. Older ones keep their logs. A build that failed is replaced by the next one, so the list never fills with failures. A rollback runs the old build with today's variables.

Restart, redeploy, stop

• Restart starts the live version again beside itself, so visitors never see it down.

• Redeploy deploys the live build again, to give it new variables.

• Stop shows visitors a "temporarily unavailable" page until you start the app again. While stopped, it pays only for its storage.

The deploy address

On the app's page, under Deploy address, choose Make an address. Calling it with POST deploys the newest code. Copy it at once: we keep only a fingerprint of it, so it can't be shown again. Replace makes a new one and stops the old one at once. It starts at most 10 deploys an hour.

Asha keeps hers as a secret named DEPLOY_ADDRESS in GitHub, and deploys from GitHub Actions after her tests pass:

- name: Deploy to Tanzahost
  run: curl -fsS -X POST "$DEPLOY_ADDRESS"
  env:
    DEPLOY_ADDRESS: ${{ secrets.DEPLOY_ADDRESS }}

Anyone who has the address can deploy your app, so keep it like a password.

What's kept between deploys

Each deploy starts with fresh files, built from your code, which can't be changed while it runs. Only your app's permanent folders (like Laravel's storage) and its home folder are kept. See The settings file.