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

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

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.

Tip

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

Next steps

RollbacksManual and automatic rollbacks.

Multiple serversAdd servers and a load balancer.