If you've ever shipped a side project with PocketBase, you know the feeling: the backend itself takes 5 minutes to set up... and then you spend the next 5 hours on the VPS, SSL certs, firewall rules, systemd services, backups, and monitoring.
I love PocketBase. Single binary, embedded SQLite, real-time subscriptions, built-in auth, admin dashboard — it's the perfect backend for small and medium projects. What I didn't love was doing the same DevOps dance for every new idea.
So I built PocketBase Cloud — fully managed PocketBase hosting that gets you a live, secured, monitored instance in about 30 seconds.
What it does
You click deploy, and you get:
- ⚡ A running PocketBase instance in ~30 seconds — zero server config
- 🔒 Automatic SSL + DDoS protection — no certbot, no Cloudflare tutorials
- 🌍 6 global regions — Germany, Finland, US East/West, and Singapore
- 📦 Frontend hosting included — deploy your SPA next to your backend
- 💾 Automated backups and live monitoring (CPU, memory, bandwidth)
- 🤖 AI-agent friendly — docs and prompts ready so your LLM/coding agent can build against it directly
Real-time subscriptions work out of the box, exactly like self-hosted PocketBase — because it is PocketBase, just without the babysitting.
The part I'm most proud of: multi-instance hosting
Here's the thing about indie developers: we don't have one project. We have twelve, and eleven of them get 40 visitors a month.
Paying $5–10/month per project on typical BaaS platforms kills side projects fast. So PocketBase Cloud's Pro plan works differently: you pay for a dedicated server (from $13/month), and you can run as many PocketBase instances on it as the resources allow. Each instance is fully isolated — its own database, credentials, and URL.
Lightweight apps are efficient enough that many users comfortably run 10–20 instances on the base plan. That's roughly $1/project/month. The Pro plan also supports Node.js/Deno/Bun backend hosting if you need custom server code alongside PocketBase.
Pricing
| Plan | Price | Best for |
|---|---|---|
| Free | $0/mo | 1 instance, 50 MB storage, frontend hosting — try it out |
| Starter | $5/mo | 1 instance, 3 GB storage, custom domain, 6 regions, SSL + DDoS |
| Pro | From $13/mo | Unlimited instances on a dedicated server, pay as you go |
All plans come with a 99.9% uptime SLA. The Free plan asks for a Stripe subscription (no charge) just to prevent abuse, and free instances are removed after 30 days of inactivity — fair warning.
Why not just self-host?
You absolutely can! PocketBase is famously easy to self-host, and if you enjoy managing servers, go for it.
But "easy to start" and "easy to run in production" are different things. Self-hosting means you own updates, SSL renewals, backups, uptime monitoring, and the 2 AM "why is my server down" investigation. For me, the math was simple: my time debugging nginx configs is worth more than $5/month.
Try it
The Free plan takes about 30 seconds to set up — genuinely, that's the whole pitch:
If you deploy something on it, I'd love to hear what you're building. And if you hit any rough edges, tell me — it's an indie product and feedback directly shapes the roadmap.
Happy shipping! 🚀
Questions about PocketBase itself, migrating from Firebase/Supabase, or running multiple projects on one server? Drop them in the comments — I've spent way too much time in this ecosystem and I'm happy to nerd out.
Top comments (5)
The 30-day cleanup on free instances made me wonder about the URL afterwards. If someone's abandoned app still has a frontend or mobile build pointing at its old instance URL and that subdomain gets handed to a new customer later, the stale app would start talking to a stranger's backend. Do released instance names get retired for good, or recycled?
instance URL is unique, it use uuid. So we never reuse instance url
Makes sense — uuid closes that door. Since you offered to nerd out on the multi-instance side: when someone runs 10-20 instances on one dedicated box, what does the isolation look like under the hood — separate processes with their own limits, or one supervisor juggling SQLite files? Mainly curious what the neighbors feel when one instance catches a traffic spike.
Each instance run on their own process within their own container. When multiple instances request CPU resource at the same time, it share the same portion. For example, you have 20 instances running on decicated server. At 10:00AM 3 instances have incoming API requests and other 17 instances idle (no API request or cronjob), so both 3 instances use 33% of CPU
So the fair-share only splits between whoever's busy, and the idle seventeen are effectively free headroom. That makes the $1/project math click. Appreciate you walking through the under-the-hood stuff this straight, most hosts stop at 'each instance is isolated' and leave it there.