Context
What was running where
In August 2026 the fleet ran on one Vercel account, on the Hobby plan:
| App | What it does | Shape of its load |
|---|---|---|
| cms | The Payload CMS: one admin panel and one REST API that every content site reads | Always reachable, many small reads, a heavy admin UI |
| flowingkhaos (old) | Next.js app with accounts, a gated docs page and billing | Rendered on every request |
| clevrstart, luke-sidney, ccc, psa, … | The other sites and services | Mostly static or light |
The database was never on Vercel. It is one Neon Postgres instance, with one schema per service
(cms, ccc, scheduling, …).
What “Hobby” means in practice
Hobby is Vercel’s free tier. It is a good plan for what it says: a hobby. Three of its limits shaped this fix:
- One shared pool. Compute, requests and deploys are counted per account, not per app.
- A daily deploy cap. When it runs out, a push to
maincreates no deployment at all. Not an error, not a queued build — nothing. We first read it as a broken Git webhook. The only honest signal was the GitHub commit status: “Deployment rate limited — retry in 24 hours.” (measured, 2026-08-25). - Personal, non-commercial use only (published, Vercel fair-use terms). A site that sells code licences cannot run there. The paid step is Vercel Pro, at 20 USD per seat per month (published).
Why the shape of the load matters
Serverless bills are made of requests, CPU time and memory time. That is cheap for a site that sleeps. It is expensive for a server that is always being asked something.
The CMS is that server. Every content site reads it at build time. Editors keep its admin panel open. Webhooks call it. On Vercel, each of those calls starts a function, pays its cold start and its CPU, and then stops. A container pays for its memory by the hour and answers everything in between for no extra charge.
That is the whole argument, in one line: an always-busy server fits a container, and a sleeping page fits a free static host.