Multi-instance & auto-scaling

Run multiple containers behind a single Caddy load balancer with active health checks. Configure it in percher.toml with either [resources].instances (a fixed count) or [resources.autoscale] (a range) — setting both is rejected when the file is parsed:

One caveat, and it applies to autoscaling only: a fixed instances = N fan-out gives every container the same fully-assembled environment, but a replica that autoscaling adds later gets only your stored env vars plus PORT — not PERCHER_APP_*, the egress-proxy variables, or the PocketBase/Convex/Supabase connection vars. If your app needs outbound HTTPS or a managed database, prefer a fixed instance count over autoscale for now.

Static fan-out

[resources]
instances = 2   # runs 2 containers, load-balanced

Plan caps: free=1, starter=1, maker=2, max=4. Exceeding the cap is silently clamped with a note in the build log.

CPU-based autoscaling

[resources.autoscale]
min = 1
max = 4

Percher samples CPU every 30s, evaluates every 50s, and scales by ±1 when sustained average crosses the threshold (default: scale up at >80% for 2 min, scale down at <20% for 10 min). Scaling up is conservative — one instance per action — and a cooldown prevents thrashing.

Active Caddy health checks route traffic around any unhealthy instance. A single-instance crash in a multi-instance deploy stays at severity warning (the app continues serving); an app only becomes crashed when all instances are down simultaneously. Per-deploy scale history lives on the deploy detail card in the dashboard.