Resource pools per account
Pricing moved from "X apps × Y memory × Z instances" to a single per-account RESOURCE POOL per tier: RAM, vCPU, and disk that you distribute freely across your apps. Per-app [resources] in percher.toml is a default the platform fills in for new apps, not a hard ceiling — what gets enforced is the sum across all your apps.
The new tier shape:
| Tier | Price | RAM pool | vCPU pool | Disk pool | Apps (soft cap) |
|---|---|---|---|---|---|
| Free | €0 | 512 MB | 0.5 | 1 GB | 2 |
| Starter | €3/mo | 1.5 GB | 0.75 | 5 GB | 5 |
| Maker | €12/mo | 4 GB | 2 | 50 GB | 10 |
| Pro | €29/mo | 10 GB | 4 | 200 GB | 25 |
Concrete: on Maker you can run 1 app at 4 GB, 4 apps at 1 GB, 8 apps at 500 MB, or any mix — as long as the sum stays under 4 GB.
Why this changed. "X apps × Y memory" was the old model, but the actual constraint that mattered was always how much you committed in total. Selling "10 apps × 1 GB × 2 instances = 20 GB" on a 4 GB pool wasn't an honest contract — it set up the expectation that you could fill all those slots when the box couldn't deliver. Pool framing is what we actually enforce.
The app cap is a soft UX limit. It keeps the route table, watchdog scan, and uptime probes bounded per account; it doesn't multiply into pool capacity. Most indie/maker apps are 1–3 anyway, so the headline number stopped being meaningful.
What this changes for the deploy flow. Nothing for an existing app within its pool. A deploy that would push you over your pool fails fast with a clear message (build log + dashboard) — reduce [resources], delete an unused app, or upgrade. The pool widget on the Settings page shows live usage.