AL Workers

How to read this tab

Capacity-planning view, separate from Live Servers. Numbers here are derived from the per-script CPU/memory limits in docker/docker-compose*.yml and the Hetzner spec table — they don't depend on Prometheus / cAdvisor being up.

• Strict packing assumes every container could simultaneously saturate its cgroup limit. That's why cpx31 / Core shows max equity_update = 0: with initial_equity (2 vCPU / 4 GB) + sidecars + OS reserve already committed, only ~0.65 vCPU and ~2.7 GB are left, less than one equity_update (1 vCPU / 4 GB).
• In practice we run 1–2 equity_update on server2 / server3 fine because CPU limits are CFS shares (soft — only enforced under contention), and actual memory use of equity_update sits well below the 4 GB cap. Live replica counts are on the Live Servers tab.
• Memory limits are hard, so the mem-bound column is the safety ceiling we should respect long-term — once real RSS approaches the limit, the kernel will OOM-kill.

Strict packing — assumes every container can saturate its cgroup limit at the same time. CPU limits are CFS shares (soft), so in practice we over-commit and live replica counts (on Live Servers) exceed these numbers; memory limits are hard, so the mem-bound column is the number we must respect to stay OOM-safe.

Projected monthly cost at common account milestones, including the Supabase tier we'd need to keep DB CPU at ~70% comfort. Extra Hetzner capacity uses cpx31 workers (the type autoscale provisions) at —, packed at the over-commit cap of 3 replicas/server.