DEV Community: tienbuilds

10 Side Projects for $13/month: A Tour of PocketBase Cloud

tienbuilds — Thu, 16 Jul 2026 05:43:20 +0000

Every indie developer I know has the same problem. It's not ideas. It's not code. It's the $10/month × 12 half-finished projects problem.

Most backend platforms charge per project. Each one needs its own compute instance, its own bill. So your dead side project from last March is still quietly charging you rent. At some point you stop starting new things — not because you ran out of ideas, but because you ran out of budget for ideas.

I built PocketBase Cloud to break that math. Here's a tour of what it does and the reasoning behind each piece.

1. You pay for a server, not per project

This is the whole thesis, so let's start here.

On the Pro plan, you rent a dedicated server (from ~$13/month for 2 cores / 4 GB) and run as many PocketBase instances on it as you want. Each one is fully isolated — own database, own credentials, own URL. Since PocketBase is a ~15 MB binary, a 2-core box comfortably hosts around 10 instances.

Run the numbers against a per-project platform:

Projects	PocketBase Cloud	Per-project pricing (e.g. Supabase)
1	$5/mo (Starter)	$25/mo
3	$11/mo (Starter + add-ons)	~$45/mo
10	~$13/mo (one Pro server)	~$115/mo

Ten projects for roughly the price of one. Your costs stay flat while your project count multiplies — which, if you're an agency doing per-client deployments or an indie hacker with a graveyard of experiments, is the only line on this page that matters.

2. Deploy in 30 seconds, zero server config

Click deploy, pick a region, and ~30 seconds later you have a live PocketBase instance with a URL and a working admin dashboard. No VPS provisioning, no nginx, no certbot, no systemd unit files.

The pitch is boring on purpose: the backend should be the part you don't think about.

3. Real-time works out of the box

PocketBase streams record changes over Server-Sent Events, and subscriptions respect your API rules automatically. No extra infrastructure, no separate realtime service to wire up:

pb.collection("messages").subscribe("*", (e) => {
  if (e.action === "create") addMessage(e.record);
});

That's the entire realtime setup. SSE also passes cleanly through ordinary HTTPS proxies — no special WebSocket infrastructure required. And it scales further than the lightweight design suggests: a single instance on 2 cores / 4 GB handles 1,000+ concurrent realtime connections.

4. Security you don't configure

Every instance gets automatic SSL certificates, localized firewall rules, DDoS protection, and automated backups — set up for you, not documented for you to set up.

I'm specifically proud of the backups. Self-hosting PocketBase is famously easy right up until the day you realize you never actually tested your restore path.

5. Frontend hosting is included

Static site hosting ships on every plan — 5 frontends on Free and Starter, unlimited on Pro.

Most backend platforms don't host frontends at all, which means pairing them with Vercel or Netlify: another dashboard, another bill, another free tier with its own limits, and CORS config between them. Here your frontend, database, and backend live in one project, on one bill.

6. Full backends, not just functions (Pro)

JavaScript hooks are included on every plan — custom API routes, record event handlers, cron jobs, outbound HTTP calls — running inside your instance right next to your data. Critically: no invocation billing. A hook that fires a million times costs exactly the same as one that fires once. Compare that to per-invocation edge function pricing, where your costs scale with your traffic.

And when a workload outgrows hooks — long-running jobs, websockets, heavy dependencies, a full Next.js app — Pro runs full backend containers (Node.js, Deno, Bun, Next.js) on your dedicated server at the server's flat price. No per-request billing. This is the piece that surprises people most, because most backend-as-a-service platforms have no equivalent at all: anything beyond their function model means renting a separate service with its own bill.

I use this myself — my World Cup live-score app runs its Socket.io backend, its React PWA, and its PocketBase instance all on the same platform.

7. Six global regions

Deploy close to your users:

🇩🇪 Falkenstein · 🇩🇪 Nuremberg · 🇫🇮 Helsinki · 🇺🇸 Ashburn, VA · 🇺🇸 Hillsboro, OR · 🇸🇬 Singapore

Europe, North America, and Asia-Pacific covered.

8. Live monitoring (Pro)

CPU, memory, and bandwidth for every instance, in real time, from one unified dashboard. When you're running ten projects on one server, knowing which one is eating the box isn't a nice-to-have.

9. AI-agent friendly

This one's newer and I like it a lot: the docs ship with prompts ready for your AI agent/LLM to build against. If you're using Claude Code, Cursor, or similar to scaffold an app, you can point it at the docs and let it wire up the backend directly instead of hallucinating an API surface.

10. No egress meter

Bandwidth is included with your server. There's no per-GB egress billing, so a traffic spike or a popular file download doesn't turn into a surprise invoice. Storage scales with your plan (50 MB Free / 3 GB Starter / your server's disk on Pro), and PocketBase also supports S3-compatible storage if you want to plug in a bucket at commodity prices.

Predictable beats cheap-until-it-isn't.

The honest part

I'm not going to pretend this fits everyone. PocketBase is SQLite under the hood: writes are serialized, and you scale vertically by getting a bigger server. If your workload is genuinely write-heavy at high concurrency, or you depend on Postgres extensions like PostGIS or pgvector, use Postgres — Supabase is excellent and I'd tell you to go use it.

But most apps are read-heavy CRUD. SaaS dashboards, mobile backends, content sites. For those, SQLite's write serialization is never the bottleneck, and you get to have one simple system you fully understand instead of a multi-container stack.

I wrote up the full comparison — architecture, auth, permissions, realtime, extensibility — here: PocketBase vs Supabase. It's deliberately honest about where PocketBase loses.

Try it

The Free plan gets you 1 instance + 5 frontends, and instances stay running — no hibernation, no cold starts.

👉 pocketbasecloud.com

If you're sitting on a pile of side projects you've been rationing your budget across, I'd love to hear what you'd deploy first. And if something's rough, tell me — it's an indie product and comments genuinely shape the roadmap. 🚀

I Deployed My Entire Realtime App — Frontend, Node Backend, and Database — on PocketBase Cloud

tienbuilds — Sat, 11 Jul 2026 03:25:49 +0000

Most "deploy your side project" tutorials end with you juggling three dashboards: one for the frontend, one for the backend, one for the database. Three hosts, three sets of env vars, three billing pages, three things that can silently break.

I built a full realtime app — a mobile-first World Cup live-score + fan chat platform — and deployed the whole thing (React PWA, Node.js/Socket.io backend, and database) on a single platform: PocketBase Cloud.

This post is about that setup: what the app is, how it's built, and why running the entire stack on one platform turned deployment from the worst part of the project into a non-event.

Code is open source 👉 github.com/HoangTien0204/apprealtime

What the app does

📺 Follow matches with live score updates as they happen
💬 Realtime fan chat per match, with presence and typing indicators
🏆 Fill out brackets and make predictions
📱 Installable PWA — feels native on mobile, works offline

The stack

Frontend — React 19 + Vite + TailwindCSS + Framer Motion, built as a PWA
Backend — Express 5 + Socket.io 4 (Node.js), with a live-match simulator
Database — PocketBase, for persisting chat messages and predictions

Three services, cleanly separated. And all three deployed on PocketBase Cloud.

Why PocketBase Cloud for the whole stack

Here's the thing people don't realize about PocketBase Cloud: despite the name, it isn't just a place to park a PocketBase instance. On the Pro plan it hosts:

🗄️ The PocketBase database — managed, with SSL and backups handled
🌐 The frontend — static hosting for the React PWA build
⚙️ A Node.js / Deno / Bun backend — so my Express + Socket.io server runs right there too

That covers every layer of my app. So instead of wiring my frontend on Vercel to a backend on Railway to a database on some VPS — and debugging CORS and env vars across all three — everything sits behind one dashboard, on one dedicated server.

Layer	Where it runs
React PWA (frontend)	PocketBase Cloud — frontend hosting
Express + Socket.io (backend)	PocketBase Cloud — Node.js backend hosting
PocketBase (database)	PocketBase Cloud — managed instance

Full disclosure: PocketBase Cloud is a product I also build. I run this real project on it precisely because I built it to solve this exact pain — and dogfooding it on something with a live Socket.io backend and a real database is the best way to keep it honest. If a deploy step is annoying, I feel it before my users do.

How the realtime part works (and where each tool fits)

The one design decision I want to highlight: realtime transport and realtime persistence are two different jobs.

┌─────────────┐   Socket.io    ┌──────────────┐   writes    ┌─────────────┐
│  React PWA  │◄──────────────►│   Express +  │────────────►│ PocketBase  │
│  (browser)  │   REST /api    │   Socket.io  │             │ (database)  │
└─────────────┘                └──────────────┘             └─────────────┘
     live scores · chat · presence         chat history · predictions

Socket.io does the live layer — pushing score changes, match events, chat messages, presence, and typing indicators to every connected client at once.
PocketBase does persistence — every chat message and prediction gets written so history survives a reload or a restart. Single binary, admin UI, SQLite underneath, JS migrations. Zero database setup.

And all of it — the Socket.io process and the PocketBase database — lives on PocketBase Cloud. The Node backend talks to the database over a local POCKETBASE_URL on the same platform, which keeps latency low and config simple.

The live-match simulator

So the app isn't dead outside match days (and so I don't burn API quota while building), the backend ships with a match simulator: 8 seconds = 1 in-game minute, generating goals and events and pushing them over Socket.io exactly like real data. For production you swap it for a real feed via an API_FOOTBALL_KEY env var — and since it's all on one platform, that's a single env var change in one dashboard.

Running it locally

npm run install:all   # install deps in each subproject
npm run dev           # frontend :5173, backend :4000, pocketbase :8090

The PocketBase binary auto-downloads on first launch — no manual database install. Migrations create the chat_messages, predictions, and favorites collections for you. Then deploying to PocketBase Cloud is just pointing each service at the platform instead of localhost.

What I learned

Two takeaways:

"Realtime" isn't one problem, it's two — transport (Socket.io shines) and persistence (PocketBase is a joy). Keep them separate and every piece stays simple.
Deploying a multi-service app doesn't have to mean multi-platform — putting the frontend, the Node backend, and the database on PocketBase Cloud collapsed my deploy story from three dashboards to one. That's the part that surprised me most.

Try it

🧑‍💻 Read / clone the code: github.com/HoangTien0204/apprealtime
🚀 Deploy your own full stack in ~30 seconds: pocketbasecloud.com (Free plan works to try it)

If you build on it or spot something I could do better, I'd love to hear it in the comments — and a ⭐ on the repo never hurts. ⚽

Curious how a Node/Socket.io backend runs on PocketBase Cloud, or how to migrate a scattered stack onto one platform? Ask below — happy to go deeper.

I Got Tired of Babysitting My PocketBase Servers, So I Built PocketBase Cloud

tienbuilds — Wed, 08 Jul 2026 10:20:04 +0000

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:

👉 pocketbasecloud.com

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.

Build a Realtime Chat App in 5 Minutes with PocketBase Cloud + React

tienbuilds — Fri, 03 Jul 2026 07:42:28 +0000

Realtime features usually mean one of two things: paying for Firebase, or wrestling with WebSocket servers at 2 AM. Today we're doing neither.

We're going to build a live chat app where messages appear instantly across all connected browsers — using PocketBase Cloud for the backend and React for the frontend. No servers to configure, no WebSocket code to write. PocketBase handles realtime over Server-Sent Events (SSE), and the JS SDK wraps it in one function call.

Total time: about 5 minutes. Let's go. ⏱️

What we're building

A public chat room (no auth, to keep this short)
Messages stored in PocketBase (SQLite under the hood)
Realtime updates via SSE — open two tabs and watch them sync

Step 1 — Deploy PocketBase (30 seconds, literally)

Go to pocketbasecloud.com and sign up (Free plan works fine for this tutorial)
Click Deploy, pick a region close to you (there are 6 — Germany, Finland, US East/West, Singapore...)
Wait ~30 seconds. You'll get a URL like:

https://your-app.pocketbasecloud.com

That's a full PocketBase instance with SSL already configured. Open /_/ on that URL to access the admin dashboard and create your admin account:

https://your-app.pocketbasecloud.com/_/

Self-hosting fans: everything below works identically on a self-hosted instance. The cloud just skips the VPS + nginx + certbot ritual.

Step 2 — Create the `messages` collection

In the admin dashboard:

Collections → New collection → name it messages (type: Base)
Add two fields:
- username — Plain text, required
- text — Plain text, required
Open the API Rules tab and set both List/Search rule and View rule and Create rule to empty (unlock them) so anyone can read and post.

⚠️ Empty rules = public access. Fine for a demo chat; for a real app you'd lock Create to authenticated users with a rule like @request.auth.id != "".

That's the entire backend. No migrations, no ORM, no REST controllers.

Step 3 — Scaffold the React app

npm create vite@latest pb-chat -- --template react
cd pb-chat
npm install pocketbase
npm run dev

Step 4 — The realtime magic

Replace src/App.jsx with this (~60 lines, that's the whole app):

import { useEffect, useRef, useState } from "react";
import PocketBase from "pocketbase";

// 👇 your PocketBase Cloud URL
const pb = new PocketBase("https://your-app.pocketbasecloud.com");

export default function App() {
  const [messages, setMessages] = useState([]);
  const [text, setText] = useState("");
  const [username] = useState(
    () => "guest-" + Math.random().toString(36).slice(2, 7)
  );
  const bottomRef = useRef(null);

  useEffect(() => {
    // 1. Load the latest 50 messages
    pb.collection("messages")
      .getList(1, 50, { sort: "created" })
      .then((res) => setMessages(res.items));

    // 2. Subscribe to realtime changes (SSE under the hood)
    pb.collection("messages").subscribe("*", (e) => {
      if (e.action === "create") {
        setMessages((prev) => [...prev, e.record]);
      }
    });

    // 3. Clean up the subscription on unmount
    return () => pb.collection("messages").unsubscribe("*");
  }, []);

  useEffect(() => {
    bottomRef.current?.scrollIntoView({ behavior: "smooth" });
  }, [messages]);

  async function send(e) {
    e.preventDefault();
    if (!text.trim()) return;
    await pb.collection("messages").create({ username, text });
    setText(""); // no manual state update needed — SSE delivers it back
  }

  return (
    <div style={{ maxWidth: 480, margin: "40px auto", fontFamily: "sans-serif" }}>
      <h2>⚡ PB Cloud Chat — you are {username}</h2>
      <div style={{ height: 360, overflowY: "auto", border: "1px solid #ddd", padding: 12, borderRadius: 8 }}>
        {messages.map((m) => (
          <p key={m.id}>
            <b>{m.username}:</b> {m.text}
          </p>
        ))}
        <div ref={bottomRef} />
      </div>
      <form onSubmit={send} style={{ display: "flex", gap: 8, marginTop: 12 }}>
        <input
          value={text}
          onChange={(e) => setText(e.target.value)}
          placeholder="Type a message…"
          style={{ flex: 1, padding: 8 }}
        />
        <button>Send</button>
      </form>
    </div>
  );
}

Run it, open two browser tabs, and send a message. Both tabs update instantly. 🎉

Notice the neat trick in send(): we don't append the message to local state ourselves. We just create() the record, and the realtime subscription delivers it back to every client — including the sender. One source of truth, zero sync bugs.

What's actually happening under the hood?

PocketBase's realtime API uses Server-Sent Events, not WebSockets:

The SDK opens a long-lived HTTP connection to /api/realtime
It submits which collections/records you want to watch
The server pushes JSON events (create / update / delete) down that stream

SSE is simpler than WebSockets (plain HTTP, auto-reconnect built into the browser) and passes through proxies and firewalls more reliably. For server→client pushes like chat, feeds, and dashboards, it's honestly all you need.

Step 5 — Ship it

Build the frontend:

npm run build

PocketBase Cloud includes frontend hosting on every plan (even Free), so you can deploy the dist/ folder right next to your backend — one dashboard, one URL, no CORS headaches. Or push it to any static host you like; the backend URL is public either way.

Where to go from here

🔐 Add auth: PocketBase ships with email/password + OAuth2 (Google, GitHub...) built in — then lock the Create rule to @request.auth.id != ""
🗑️ Handle update/delete events in the subscription for message editing
📄 Paginate history with getList(page, perPage)
🚀 Running multiple side projects? The Pro plan (from $13/mo) lets you run unlimited PocketBase instances on one dedicated server — many users fit 10–20 apps on it

Try it here 👉 pocketbasecloud.com — the Free plan is genuinely 30 seconds to a live backend.

If you build something with this, drop a link in the comments. I'd love to see it! 💬

The Time Spent on Infrastructure Can Easily Surpass the Time Spent Building Features

tienbuilds — Tue, 30 Jun 2026 14:37:27 +0000

One thing I've realized after building several products is this:

Sometimes, I spend more time managing infrastructure than actually building features.

I've always enjoyed using PocketBase.

It's lightweight, fast, and an excellent choice for building MVPs.

However, self-hosting PocketBase means every new project starts with the same checklist:

Setting up a VPS
Configuring a reverse proxy
Installing SSL certificates
Planning backups
Monitoring the server
Deploying and updating PocketBase

None of these tasks are unnecessary.

They're important.

But they don't directly create value for users.

So a few months ago, I decided to give PocketBaseCloud a try.

The first thing that impressed me was how quickly I could get started.

Within minutes, I had a fully functional backend ready to use.

No SSH.

No Nginx configuration.

No SSL setup.

Just create a project and start building.

What I appreciate most isn't just the convenience.

It's the peace of mind.

Instead of asking myself:

Is the server still running?
Is disk space running low?
Is the SSL certificate about to expire?
Is it time to update PocketBase?

I can focus on things that actually move the product forward:

Building new features.
Improving the user experience.
Talking to customers.
Growing the business.

After using PocketBaseCloud for a while, I realized the biggest benefit isn't the list of features it offers.

It's that the backend becomes almost invisible.

When you no longer have to think about your infrastructure every day, you gain more time and energy to focus on building something people actually want.

Sometimes, that's the most valuable feature of all.

DEV Community: tienbuilds

10 Side Projects for $13/month: A Tour of PocketBase Cloud

1. You pay for a server, not per project

2. Deploy in 30 seconds, zero server config

3. Real-time works out of the box

4. Security you don't configure

5. Frontend hosting is included

6. Full backends, not just functions (Pro)

7. Six global regions

8. Live monitoring (Pro)

9. AI-agent friendly

10. No egress meter

The honest part

Try it

I Deployed My Entire Realtime App — Frontend, Node Backend, and Database — on PocketBase Cloud

What the app does

The stack

Why PocketBase Cloud for the whole stack

How the realtime part works (and where each tool fits)

The live-match simulator

Running it locally

What I learned

Try it

I Got Tired of Babysitting My PocketBase Servers, So I Built PocketBase Cloud

What it does

The part I'm most proud of: multi-instance hosting

Pricing

Why not just self-host?

Try it

Build a Realtime Chat App in 5 Minutes with PocketBase Cloud + React

What we're building

Step 1 — Deploy PocketBase (30 seconds, literally)

Step 2 — Create the messages collection

Step 3 — Scaffold the React app

Step 4 — The realtime magic

What's actually happening under the hood?

Step 5 — Ship it

Where to go from here

The Time Spent on Infrastructure Can Easily Surpass the Time Spent Building Features

Step 2 — Create the `messages` collection