# Deployment strategies

> Pick how Falak ships a release — zero downtime, in place, rolling, canary, blue/green or compose — and tune batch size, health checks and releases kept.

Source: https://falak.sh/docs/guides/deployment-strategies/

A **strategy** decides the order in which servers switch to a new release. Configure it under the site's **Settings → Deploy**, together with the health check and how many releases to keep.

## Available strategies

| Strategy | Value | Available for | Use when |
|---|---|---|---|
| **Zero downtime** | `zero-downtime` | Native runtimes (default) | Almost always. All servers fetch and prepare, then switch together. |
| **In place** | `in-place` | Native | Speed matters more than consistency; servers may run different releases for a moment. |
| **Rolling** | `rolling` | All | Many servers and you want to limit blast radius: batches of *batch size* switch one after another, each must pass its health check. |
| **Canary** | `canary` | All | You want one server to prove the release first; the rest follow only if it is healthy. |
| **Blue / green** | `blue-green` | Docker (default) | Container sites: new container next to the old one, swap after the health check. |
| **Compose** | `compose` | Compose (default) | Compose sites: pull everywhere, `up --wait` everywhere, restore the previous files on failure. |

## Settings

| Setting | Default | Range |
|---|---|---|
| Strategy | Per runtime (see above) | |
| Batch size (rolling) | 1 | 1–100 |
| Releases to keep | 5 | 1–50 |
| Health check enabled | yes | |
| Health check path | Preset (`/up`, `/`) | starts with `/` |
| Expected status | 200 | 100–599 |
| Timeout | 10 s | 1–120 s |
| Attempts | 3 | 1–30 |
| Delay between attempts | 5 s | 0–300 s |

## What "zero downtime" guarantees

- The new release is fully fetched, has its `.env` and shared paths, and has run your pre-activation steps on **every** server before any server switches.
- Migrations run once, on the leader, before the switch.
- The switch is an atomic symlink change plus a reload of the PHP runtime or a restart of the web process.
- If any server fails before activation, **no** server switches. If a health check fails after activation, every switched server goes back to the previous release.

It does not make incompatible database migrations safe: the old release keeps serving while migrations run.

## Rolling and canary in practice

```text title="Rolling, 4 servers, batch size 2"
fetch + prepare: all 4
migrate: leader
batch 1 (2 servers): activate → restart → health
batch 2 (2 servers): activate → restart → health
```

```text title="Canary, 4 servers"
fetch + prepare: all 4
migrate: leader
canary (1 server): activate → restart → health
rest (3 servers): activate → restart → health
```

A failed batch rolls back the servers that switched.

Health checks only verify publicly trusted certificates. Sites that use internal TLS are checked without certificate verification.

## Next steps