Unlimited Apps, One Flat Bill: What PocketBaseCloud's $25 Show HN Pitch Reveals About Per-Project Pricing

Your side-project count just 6x'd. Your bill noticed before you did.

That is the entire pitch behind PocketBaseCloud's September Show HN: unlimited small and medium apps for one flat price. No per-project meter, no per-seat ladder, no bandwidth line item waiting to ambush you. The author's comment is worth quoting in full because it names the two pricing models it is running from:

"I built this because I have multiple side projects (thank to AI) and Supabase bill me per projects, I am dont like Vercel as it can give me some surpise bill."

Two grievances, two incumbents, one product. And underneath it, a question worth taking seriously: now that AI can spin up your twelfth side project as cheaply as your second, which pricing shape still makes sense — paying per project, paying per unit of usage, or paying for a flat slice of compute and filling it up?

What $25 actually buys​

PocketBaseCloud's Pro plan is disarmingly simple. Each Pro subscription gets its own dedicated compute — 2 vCPU, 4 GB of RAM, 40 GB of disk — and you deploy as many apps as that slice can handle: unlimited PocketBase backend instances, unlimited static frontends, unlimited Node.js, Next.js, Deno, Bun, or Python backends, across 12 regions. A busy month costs the same as a quiet one. Nothing is billed per request, per seat, or per gigabyte.

The cheaper tiers frame the offer. There is a free plan (one PocketBase instance, 50 MB of storage, 500 API requests an hour, paused after 30 idle days) and a $10/month Starter (one instance, 3 GB of storage, unlimited API requests, on a shared pool). Pro is the plan where the unit of sale stops being the app and becomes the machine. Note the honest operational footnote: dedicated compute is provisioned after checkout and can take up to 48 hours to be ready. Flat capacity is real hardware, not an abstraction that spins up in 400 milliseconds.

The N-app math: 1, 5, and 12 side projects across four options​

Here is the worked comparison the pitch invites. Assumptions, stated up front so the table is checkable: a solo developer, so one seat everywhere seats exist. Each side project is a typical low-traffic experiment — on the order of 5 GB of bandwidth a month, comfortably inside every included quota below. Every app needs to stay always-on, so free tiers that pause idle projects do not count as hosting it. Prices are list prices at the time of writing, before any overages.

† The Vercel column is frontend hosting and serverless compute only — a real stack still pays a database column next to it. That multi-vendor addition is exactly what PocketBaseCloud's own cost calculator prices itself against, and it is the honest reason the Vercel row looks flat here: per-app metering moved to the database line, not away.

Three things fall out of the table. First, the crossover against per-project billing lands almost immediately: at two always-on apps, Supabase-style metering ($25 base plus roughly $10 of compute per additional project) already exceeds the $25 flat slice, and the gap widens linearly from there. Second, the self-hosted floor is dramatically lower than all of them — a comparable 2 vCPU / 4 GB slice on Hetzner lists around $6/month with 20 TB of included traffic — which means the $25 flat price is best read as roughly $6 of raw capacity plus $19 of managed service: updates, backups, domains, deploys, and someone else's pager.

Third, and most important, the table above is the quiet-month table. Pricing shapes differ most when something goes wrong — or viral. So here is the sensitivity row the quiet table hides: one of your twelve apps serves 2 TB in a month.

The spike row is where "deploy as much as the compute can handle" earns its keep. On flat capacity, virality degrades gracefully — the slice gets slow, and slowness is free. On metered plans, virality sends an invoice. Both failure modes deserve a design response, but only one of them arrives as a surprise.

Why per-project metering stings now​

Supabase's current shape is a $25/month Pro base per organization plus compute billed per project — roughly $10 a month per additional project beyond the first Micro instance the included credits cover. The free tier allows two projects and pauses them after a week of inactivity. None of this is unreasonable for one production app. The sting is structural: the bill scales with the count of things you started, not with the resources they consume. Twelve idle experiments cost like twelve commitments.

What changed is how cheaply that count grows. Supabase's own CEO has said that more than 60% of new databases on the platform are now created by AI tools. When scaffolding an app costs a prompt, the number of projects per developer stops being a proxy for seriousness and starts being a proxy for curiosity — and a price that multiplies per project taxes curiosity directly. The Show HN author's parenthetical "(thank to AI)" is doing more work than it seems: AI multiplied the numerator that per-project pricing charges against.

Why metered-everything stings differently​

Vercel's grievance in the Show HN comment is not per-project billing — it is the surprise bill. Vercel Pro starts at $20 a seat per month, includes 1 TB of team data transfer, and then charges overages of roughly $40 per 100 GB of bandwidth. The documented horror stories are real: one widely dissected case ran to $46,000 for what was essentially static pages, almost entirely bandwidth and edge-request overages on an aggressively cached site. Community write-ups of four-figure surprise bills keep recurring with the same ingredients: an unbounded route, a bot or scraping event, and no spend limit configured.

To Vercel's credit, the platform has responded: since September 2025, spend-management notifications are enabled by default on Pro, alerting at 50, 75, and 100 percent of a threshold. But the default sends alerts — it does not pause anything unless the developer configures a hard limit by hand. The failure mode moved from "no warning" to "a warning you might be asleep for," which is better and still not the same as a price that cannot move.

Why flat capacity is technically honest here​

Flat pricing only works if the underlying unit economics cooperate, and here they genuinely do. PocketBase is a single ~15 MB Go binary — SQLite database, auth, file storage, realtime subscriptions, and an admin UI in one process. A backend that small has a tiny idle footprint, which means dozens of small instances genuinely fit inside a 4 GB slice without pretending. The binding constraint is disclosed compute, not a hidden counter: when the slice is full, it is full, and you can see it filling.

That is the difference between a flat price and a flat promise. "Unlimited" backed by a visible 2 vCPU / 4 GB ceiling is falsifiable in a way "unlimited" backed by a fair-use clause is not. The customer can reason about headroom the same way the vendor prices it — in cores and gigabytes, not in projects and seats.

Where flat pricing loses​

Honesty cuts both ways, so here is the other side of the ledger. First, every app on a Pro slice shares one fate: a noisy neighbor is now your own viral app slowing down your other eleven, with no isolation boundary between them except the ones you build. Per-project platforms isolate by default; flat slices consolidate by default. Those are opposite failure domains, and you should pick yours deliberately.

Second, the slice has a ceiling, and growth past it is lumpy. Outgrowing 2 vCPU / 4 GB does not cost 10 percent more — it costs a second slice, a migration, or an architecture conversation. Usage-based pricing, for all its ambush potential, scales smoothly through exactly the growth phase where flat capacity forces a step function.

Third, some workloads genuinely want per-unit economics. An app with spiky, bursty traffic that idles to zero is cheaper on scale-to-zero serverless than occupying a slice it rarely uses. Flat capacity wins for the always-on long tail of small apps; it is not a universal answer, and anyone selling it as one is rounding off the edges this section just drew back in.

The self-hosted endgame​

Step back one level and the Show HN pitch is really an arbitrage observation: raw compute is so cheap that the meter costs more than the machine. The same 2 vCPU / 4 GB / 40 GB slice lists at roughly $6/month on Hetzner with 20 TB of traffic included. PocketBaseCloud charges $25 and keeps the $19 spread in exchange for provisioning, updates, continuous backups, custom domains with TLS, git-push deploys, and support. Whether that spread is worth it depends entirely on what your ops time costs — for many solo developers, it is the easiest $19 they spend.

But notice what the endgame looks like for a team that already operates machines. Consolidate those twelve side projects onto one flat-rate Hetzner box managed declaratively under Cluster API, and the pricing sentence becomes even shorter: the hardware is a sunk $6, every additional app is free until the cores run out, and machine lifecycle is code rather than clicking. No per-project counter, no per-gigabyte meter, no seat ladder — capacity you own, filled as far as it goes.

That is the sentence a self-hosted PaaS wins by default. "Deploy as much as the compute can handle" is not a pricing gimmick when you own the compute; it is just a description of how servers work. PocketBaseCloud deserves credit for porting that sentence into managed hosting. The rest of us should notice how much of the meter was optional all along.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.