At a glance
- What brokeTwo apps held 54.7% of the shared Hobby account’s compute; deploys were refused for a day at a time across the whole fleet.
- Found byVercel Usage dashboard, 30-day Fluid Active CPU per project
- Where it standsStill open. The log says so, and the write-up grows as the repair does.
The story
Two apps were eating a free plan that the whole fleet shares. The CMS and the old flowingkhaos app held more than half of the account’s compute on Vercel Hobby. The CMS now runs as one container on Railway, for a fixed monthly floor. Its data stayed where it was.
The short version
- The symptom. The Vercel Hobby account kept hitting its limits. Deploys were refused for a day at a time. Every app on the account felt it, not only the heavy ones.
- The cause. Two apps held 54.7% of 30-day Fluid Active CPU: the old flowingkhaos app at 32.5% and the CMS at 22.2% (measured, Vercel dashboard, Jul 31 – Aug 29).
- The repair. The CMS moved to a Railway container on the Hobby plan: 5 USD a month, with 5 USD of usage included. The old flowingkhaos app was paused, then rebuilt as a static site.
- The rule it left. Measure which project spends before you move anything. The app we first planned to rewrite held 7.9%.
Why this is a fix and not a preference
A free plan is not free when it is shared. On Hobby, every app draws from one pool of compute and one daily deploy allowance. One busy app does not get a bigger bill. It takes the pool from the others, and nothing tells you which one did it.
So the real cost was not money. It was a fleet that could not ship on a busy day, and a plan whose terms say it is for personal, non-commercial use, which rules out the paid marketplace this site is built around.
What this fix does not show
The repositories behind it are private, so this fix carries no repository links. It shows excerpts and numbers instead, and every number says where it came from:
- measured: read from our own dashboards or databases, with the date;
- published: read from the vendor’s own pricing page;
- estimate: reasoned, not measured, and marked so it can be replaced.
The evidence
The trace is rough while the fix is open. It runs straight from the repair on.
- Opened
A push to `main` creates no deployment at all. The commit status reads *Deployment rate limited — retry in 24 hours*.
- Diagnosis
Per-project attribution: old flowingkhaos app 32.5%, CMS 22.2%, clevrstart 7.9% of 30-day Fluid Active CPU. The planned clevrstart rewrite is dropped.
- Diagnosis
25 foreign keys cross into `cms.users`. Scope narrowed: the compute moves, the data stays on Neon Free (80 MB of 512 MB, 0 USD).
- Repair
Cutover. The Railway service matched the Vercel copy response for response; every reader was repointed one at a time.
receipt · health, users, videos, workshops and auth responses byte-identical - Monitoring
Neon at 36 of 100 CU-hours for the month, with four days of an always-on CMS inside it. Waiting on the first Railway invoice.
The rule I changed after
Measure which project spends before migrating anything. Migrations run by hand, before the deploy — the platform never migrates a shared database.