PocketBase: The Backend in a Single File That Puts Your Data Back Under Your Roof

1. What PocketBase Actually Is

PocketBase is an open-source backend that ships as a single executable file. There is no database container to orchestrate, no message broker to stand up, no reverse proxy required just to get moving, and no control plane phoning home to a vendor. You download one binary, run it, open a browser, and you have a working API with authentication, a relational-ish data layer, realtime subscriptions, file uploads, and a full admin dashboard. That is the entire pitch, and it is a genuinely good one.

The project positions itself as a self-hostable Firebase alternative, and it has found an enormous audience doing exactly that job. As of late 2026 it carries well over 60,000 GitHub stars and is published under the MIT license, which is about as permissive as open source gets. The maintainer describes it as a "backend in a single file," and that phrase is not marketing fluff — the SQLite database, the realtime WebSocket layer, the auth engine, and the admin UI are all compiled into the same Go binary and embedded at build time.

For the self-hosting and data-sovereignty crowd, PocketBase is interesting precisely because of what it does not do. It does not ask you to trust a cloud provider with your users' rows. It does not meter you per seat. It does not hold your schema hostage behind a proprietary console. The trade you make is operational: you become responsible for the server, the backups, and the upgrades. This article walks through that trade in detail — what the software is good at, what it quietly cannot do, what it really costs to run, and where your bytes actually end up.

2. Architecture: Why a Single Go Binary Changes Everything

Most backends are a stack. A typical "build your own backend" project in 2026 means a Postgres container, a Redis container, an API server in Node or Python, a separate auth service, an object storage bucket, and a reverse proxy — all wired together with a Docker Compose file that quietly becomes the most important and least documented artifact in your company. PocketBase collapses that stack into one process.

The reason this works is Go's ability to produce static, dependency-free executables. PocketBase is built with CGO disabled, which means the binary does not depend on a system libsqlite3 or any C runtime. You can cross-compile it for linux/arm64, linux/amd64, macOS, Windows, and even more exotic targets like linux/riscv64 from a single machine. The result is a file you can scp to a server and run with no installation step. There is no npm install, no virtualenv, no apt-get, no shared library mismatch to debug at 2 a.m.

This single-binary design has real consequences for self-hosters. First, your attack surface is smaller because there are fewer moving parts and fewer network listeners. Second, your deployment story is trivial to reproduce: the binary is the deployment. Third, upgrades are a pull-and-restart operation rather than a coordinated migration across four services. The cost is that you trade horizontal scale for that simplicity, and we will come back to that ceiling in detail because it is the single most important thing to understand before you commit.

The admin UI is worth calling out here because it is not a separate frontend service. The dashboard's compiled assets are embedded directly into the binary using Go's embed package. When you hit the admin route, the same process that answers your API calls serves the dashboard. There is even a build variant, embed_no_ui.go, that strips the dashboard entirely if you want a pure API server with the smallest possible footprint.

3. The Embedded SQLite Engine

Under the hood, PocketBase stores everything in a SQLite database file. The specific driver is modernc.org/sqlite, a pure-Go implementation of SQLite that needs no CGO. This is a deliberate and consequential choice. Because there is no C dependency, the binary stays portable and the build stays reproducible, but you are also committing to SQLite's single-writer model — a fact that shapes the entire scaling discussion later.

SQLite is, by almost any measure, the most deployed database engine on the planet. It is rock solid for the read and moderate-write workloads that the vast majority of applications actually have. PocketBase wraps it with a lightweight query builder (github.com/pocketbase/dbx) rather than a heavy ORM, and it adds an expression parser (fexpr) that powers the filter= query syntax you see throughout the API. A query like status = "active" && created >= "2026-01-01" is parsed and turned into safe parameterized SQL rather than concatenated as a raw string, which is the right way to avoid injection bugs.

Recent releases have tightened the database layer further. As of v0.40.0, PocketBase enables SQLite's defensive=1 mode by default, which adds a layer of protection against certain classes of corruption and misuse, and it bumped the driver to a current version that hardens backup behavior. For a self-hosted product whose entire state lives in one file, those defensive defaults matter more than any feature checkbox.

The honest caveat is that SQLite is a single-writer database. One process writes at a time. On a single server this is completely fine for enormous numbers of real applications, but it means you cannot trivially spread writes across three nodes the way you would with Postgres streaming replication. If your mental model of "scale" is "add another container and it just works," PocketBase will surprise you. If your mental model is "one capable server with a fast disk," it will delight you.

4. Collections, Not Migrations: Schema as Live Data

In a conventional stack, your database schema lives in migration files that you write, review, and apply with a CLI. In PocketBase, your schema is data. Collections — the equivalent of tables — are stored inside the SQLite database itself, and you can create, modify, and delete them from the admin UI or the API without writing a single migration file or restarting anything.

This is a genuinely different workflow and it has upsides and downsides. The upside is velocity. You sketch a data model in the dashboard, immediately get a REST and realtime API for it, and iterate visually. For a solo founder or a small team, this compresses the distance between an idea and a working backend dramatically. The import and diff logic even lets you move a collection definition between environments as JSON, which is a reasonable stand-in for migrations when you are disciplined about exporting.

The downside is governance. Because schema changes can happen from a web UI with no code review, it is easy to end up with a production schema that no commit history records. The mature way to operate PocketBase in a team is to treat collection definitions as exportable artifacts checked into version control, and to make schema changes through that exported JSON rather than by clicking in the live dashboard. PocketBase supports this — you can import a collection definition via the API and it will diff against what exists — but the tool does not force the discipline on you. That is a people problem, not a software problem, and it is worth naming now.

Field types cover the usual suspects: text, number, boolean, date, email, url, select, json, relation, file, and user-links for auth. Relations are real foreign keys under the hood, and the API rules system (covered below) controls who can read or write across them. You can also define "view" collections that are read-only SQL queries over your data, which is a clean way to expose derived datasets without duplicating rows.

5. Realtime Subscriptions: Websockets Without a Broker

Realtime is one of PocketBase's headline features and one of the reasons it feels modern next to a plain REST scaffold. Clients subscribe to a collection, a filtered set of records, or a single record, and they receive push notifications over a WebSocket when something changes. There is no separate pub/sub server to run — the same binary that holds the SQLite file also holds the subscription registry and broadcasts changes as transactions commit.

For chat apps, live dashboards, collaborative editors, and any "see it update instantly" UX, this is a huge convenience. You get it for free the moment a collection exists. The subscription protocol is documented and the official SDKs (JavaScript, Dart/Flutter, and others) wrap it cleanly, so a typical "subscribe to this list and re-render on change" block is a handful of lines.

The limitation to keep honest: realtime is per-instance. Because state lives in a single SQLite file owned by one process, subscriptions are served by that process. If you ever do run multiple PocketBase instances (for example, behind a load balancer for read redundancy), each instance only broadcasts the changes it personally commits. Cross-node invalidation is not built in. For the single-server deployments this article recommends, that is a non-issue. For a hypothetical multi-node fan-out, it is a real gap you would have to engineer around.

6. Authentication and OAuth: Sessions, Not Just JWTs

PocketBase ships a complete auth layer out of the box. You get email/password signup and login, password reset, email verification, and a long list of OAuth2 providers (Google, GitHub, GitLab, Apple, Microsoft, and more) configured through the admin UI. Tokens are JWTs, but the system also tracks auth origins and sessions in a dedicated table rather than firing a stateless token into the void and forgetting about it. That session awareness is a more careful approach to security than many minimal auth libraries take.

From a data-sovereignty standpoint, this is exactly what you want: the user table, the password hashes, the OAuth tokens, and the session records all live in your SQLite file on your disk. No third-party identity provider is required, no Auth0 bill arrives, and no anonymous telemetry about who logs in leaves your network. You can run the entire identity layer air-gapped if you are willing to forgo OAuth providers that themselves require outbound internet.

A couple of practical notes the docs are honest about. On mobile, you must persist the auth token yourself across app restarts using the SDK's storage hooks (SharedPreferences, secure storage, or a local file). That is a few lines, not a project, but it is a step a Firebase-trained developer might expect to be automatic. Also, access control in PocketBase is modeled as collection API rules — authorization is part of the data model, not a layer you bolt on afterward. The recommended pattern is to design those rules early, because retrofitting them onto a schema that assumed "everything is public" is unpleasant.

7. File Storage: Where Your Uploads Actually Live

PocketBase handles file uploads as a first-class feature. When a collection has a file field, uploaded bytes land on the local filesystem in a pb_data/storage directory (or whatever you configure), and the API serves them back through signed, rule-controlled endpoints. Thumbnails are generated on the fly for images via the disintegration/imaging library, so you get sized previews without standing up a separate image pipeline.

This is the crux of the data-sovereignty story for binary data. Your users' avatars, documents, and media do not go to an S3 bucket you do not control and cannot audit. They go to a folder you own, on a disk you chose, in a jurisdiction you picked. You can back that folder up with rsync, restic, or rclone exactly like any other file. There is no proprietary blob format and no egress fee when you want your data back.

Two honest limitations. First, the default filesystem is local disk, which means file storage scales with the server's block device, not with an object store's near-infinite ceiling. If you expect to store terabytes of user media, you will want to mount network storage or point the filesystem layer at an S3-compatible backend you control — and PocketBase's filesystem abstraction does allow custom writers, though the simplest path for most people is "a big enough volume plus regular backups." Second, filesystem hooks for custom upload handling (introduced in recent releases) are exposed to Go plugin authors rather than the main API surface yet, so advanced file routing still means writing Go rather than clicking in the dashboard.

8. The Admin Dashboard: A GUI You Actually Keep

The embedded admin UI is one of PocketBase's most underrated assets. Many "backend in a box" tools give you an API and a shrug; PocketBase gives you a real management console where you can browse records, edit schema, manage users, configure OAuth, inspect logs, and trigger backups. Because it is embedded in the binary, there is no separate dashboard service to deploy, secure, and keep version-matched.

For a self-hoster, the dashboard is the difference between "I can actually operate this" and "I need to write my own admin panel first." You can hand a non-developer teammate a URL and let them manage content. You can use it as a crude CMS. You can debug production data without a SQL client. And because the dashboard is just another route on the same server, the same API rules that protect your data from the public API also apply to what the dashboard can show to non-superusers.

The one operational wrinkle worth knowing: there is no first-party, officially maintained Docker image in the PocketBase repository. The project ships a prebuilt binary and expects you to wrap it yourself. Community images exist, and the maintainer's own docs show a Dockerfile, but if your compliance posture requires "built from the vendor's official image," you will be writing that Dockerfile yourself or pinning a specific binary hash. For most self-hosters this is a non-event; for regulated buyers it is a procurement note.

9. The JavaScript VM: Hooks Without Recompiling Go

A backend is only as useful as the business logic you can attach to it, and PocketBase gives you two ways to extend it: Go and JavaScript. The JavaScript path runs on goja, a Go-native ECMAScript engine embedded in the binary. This means you can write hook logic — "on record create, send an email," "before auth, enforce a rule," "on file delete, clean up a side table" — in plain JS files that PocketBase loads at runtime, with no Go toolchain and no recompile.

For the solo developer or the prototyper, this is the sweet spot. You get the event-bus pattern (OnRecordCreateRequest, OnRecordAfterUpdateSuccess, and dozens of lifecycle hooks) without leaving your editor's JavaScript comfort zone. The framework itself is composed through these same hooks internally, so custom logic and built-in logic travel the identical extension points — your code is not second-class.

The honest boundary: PocketBase is not a cloud-function platform. If your workflow is "spin up a 30-minute video encode on every upload," that work belongs in an external service you operate, and PocketBase triggers it via a hook rather than running it inline. The JS VM is for request interception, validation, light transforms, and outbound calls — not for heavy asynchronous jobs. For those, the recommended pattern is a hook that enqueues work to a queue or notifies an external worker. That separation keeps the single binary fast and crash-resistant.

10. Serving Your Frontend From pb_public

A small but genuinely useful feature: PocketBase will serve static frontend assets from a pb_public directory sitting next to the executable. That means a common deployment for a small SaaS or side project is literally one binary plus a folder of built HTML/JS. The API, the realtime layer, the auth, the file storage, and the static site are all served by the same process on the same port.

This collapses the operational footprint to almost nothing. There is no separate web server container, no CDN config to debug for a prototype, and no CORS dance between your frontend and your API because they are the same origin. For production you will usually still put a proper reverse proxy or CDN in front for TLS termination, caching, and rate limiting — but the fact that you can start with one process and grow into a hardened setup without rewriting your architecture is a real advantage.

The trade-off is that you should not serve a heavy marketing site or a globally distributed frontend purely from pb_public at scale. For that, a static host or CDN is cheaper and faster. Use pb_public for the app shell and let a real edge network handle the public-facing html when traffic matters. The point is that PocketBase gets out of your way instead of forcing a choice up front.

11. Installing PocketBase: Binary, Docker, or Source

Getting started is deliberately easy. If you run the prebuilt executable directly, PocketBase even ships a built-in updater — ./pocketbase update pulls the latest release. From source, because the project is CGO-free, a CGO_ENABLED=0 go build produces a working static binary for a dozen OS and architecture combinations. For Docker users, the usual docker compose pull && docker compose up -d workflow applies, though as noted you supply the Dockerfile or use a community image since the repo does not publish an official one.

A minimal real deployment looks like this in spirit: run the binary (or container) on a host, mount a persistent volume for pb_data (this folder holds your SQLite file, your uploads, and your config — it is your entire state), point a domain at it through a reverse proxy that handles TLS, and open the admin route to create your superuser. That is the whole install. There is no cluster bootstrap, no etcd, no operator to install.

The single most important operational rule is this: back up pb_data. Everything that matters — schema, records, files, sessions, logs — lives there. If that folder is safe, your product is safe. If that folder is gone and unreplicated, your product is gone. We will quantify backups next, because it is the part no feature list mentions and the part that determines whether self-hosting is a freedom or a liability for you.

12. A Minimal Production Setup With a Reverse Proxy

For an internet-facing instance, the recommended shape is PocketBase behind a reverse proxy that terminates TLS and adds a few hardening touches. Tools like Caddy or Traefik (both covered elsewhere on this blog) make the TLS part nearly automatic with Let's Encrypt. Recent PocketBase releases also send a Cross-Origin-Opener-Policy: same-origin header by default to guard against tab-nabbing if a custom UI plugin opens links without rel="noopener", and they cap log entry size (around 16KB per entry, messages at 8,000 characters) to stop a malicious or buggy client from bloating your database with giant log rows.

A sane production checklist, in plain terms: terminate TLS at the proxy; force HTTPS; put PocketBase on an internal port the proxy reaches, not the public internet directly; set a strong superuser password and store it in a secrets manager; enable a scheduled backup of pb_data; restrict the admin route by IP or VPN if the instance is sensitive; and keep the binary version current because security fixes (like the v0.39.7 worker-panic patch) are real and sometimes same-week important. None of this is exotic. It is the same hygiene you would apply to any small service, just condensed onto one process.

13. Backups: The Part Nobody Markets

Backups are where the self-hosting fantasy meets the self-hosting responsibility. PocketBase gives you a backup command and a pb_data folder, but it does not back itself up to the cloud for you — that is the entire point of owning your data. The modern SQLite driver in PocketBase no longer locks the whole database during a backup, so scheduled backups no longer stall writes on busy instances, which is a meaningful production-quality improvement.

A practical backup plan for a single-node PocketBase: stop accepting writes is not required; instead, use the built-in backup endpoint or simply copy pb_data while the process runs (SQLite handles concurrent readers/writers, and the backup command is designed for online use), then push the archive somewhere off-box with rclone or restic to an S3-compatible bucket, another server, or an external disk. Keep at least daily snapshots and a couple of weeklies. Test a restore once. The number of "I lost everything" self-hosting stories that reduce to "I never tested a restore" is not small, and it is the one failure mode no software feature can save you from.

For extra durability you can pair the SQLite file with a continuous-replication tool like Litestream, which streams SQLite WAL changes to object storage. That is not built into PocketBase, but because the state is "just a SQLite file," the wider SQLite backup ecosystem applies directly. This is the quiet superpower of the single-file design: you can use decades of SQLite tooling instead of waiting for the vendor to invent a backup product.

14. Real Self-Hosting Cost Numbers

Now the numbers, because "free software" and "free to run" are different things. PocketBase the binary costs $0 under MIT. What you pay is compute, storage, a domain, and your time. Here is a realistic range for a small-to-medium instance in late 2026.

Option A — Raspberry Pi at home. A Raspberry Pi 4 or 5 (8GB) runs PocketBase effortlessly; the process idles around 30–60 MB of RAM. One-time hardware of roughly $75–120, plus a microSD or NVMe hat, plus maybe $1.50/month in electricity. Recurring software cost: $0. You supply the bandwidth and accept that "home" means "down when your power or ISP is down." Good for personal projects and internal tools.

Option B — Small VPS. A Hetzner CAX11 (2 ARM vCPU, 4 GB RAM) runs about €3.79/month (roughly $4.10). A DigitalOcean or Linode shared-core droplet in the 1–2 GB RAM class is about $5–6/month. Add a domain at ~$10–12/year (about $1/month amortized) and you are at roughly $5–7/month all-in for a reliably-up, publicly reachable instance. Storage on these tiers is 20–40 GB, which covers a surprisingly large SQLite database plus uploads for most apps; expand the volume when you outgrow it.

Option C — Always-free tier. Oracle Cloud's ARM free tier gives 4 cores and 24 GB RAM at $0/month, and a few other providers run free credits. This is genuinely $0 recurring, with the caveats that free tiers require a payment instrument, can be region-limited, and are not a substitute for a real SLA. Fine for hobby and learning, risky for anything your income depends on.

Backups and egress. An off-box backup to Wasabi or another S3-compatible store runs about $6/TB/month, and a small app's pb_data is usually megabytes to low gigabytes, so backup storage is effectively free until you are successful. Bandwidth on most VPS tiers is generous or metered cheaply. The real cost that never shows up on a calculator is your time: patching, monitoring, and the occasional 2 a.m. "why is it down" — which is why the next section on where data goes matters for whether that time buys you sovereignty or just a second job.

15. Where Your Data Goes: A Data Sovereignty Audit

This is the section the whole blog exists for, so let us be precise. When you self-host PocketBase, your data lives in exactly three places you control: (1) the SQLite file in pb_data, containing every record, every user, every session, every log; (2) the pb_data/storage directory, containing every uploaded file; and (3) your off-box backups, which you chose and which you can encrypt, air-gap, or delete at will. No row, no password hash, no uploaded document transits a vendor you do not operate unless you explicitly configure an outbound integration (for example an OAuth provider or an email SMTP server you point at).

Contrast that with a managed backend-as-a-service. There, your users' data resides in the vendor's database, in the vendor's object store, in the vendor's jurisdiction, under the vendor's subprocessor list, and behind the vendor's uptime and retention policies. You gain convenience and someone else's on-call; you lose the ability to point at a file and say "this is mine, on my disk, and I can take it offline right now." PocketBase inverts that trade completely. The server is yours, the disk is yours, the backup is yours, and the legal footprint is "your infrastructure, your rules."

The sovereignty caveats are real and worth stating plainly. If you run on a VPS, your data is physically in the host's datacenter and legally under that jurisdiction — self-hosting the software is not the same as owning the metal. If you use OAuth login, an identity assertion does flow to the provider you configured. If you send transactional email through a third-party SMTP, message content leaves with it. And if you never test your backups, your "sovereignty" is theoretical. Sovereignty is a practice, not a checkbox, and PocketBase gives you the tools to practice it without charging you for the privilege.

16. The Scaling Ceiling: The Single-Writer Truth

Here is the limitation that deserves the most airtime before you commit, because it is structural and not a bug. PocketBase is built around a single SQLite file owned by one process. SQLite handles one writer at a time. On one capable server with a fast SSD, that single writer serves an enormous number of real applications — SQLite happily does tens of thousands of reads per second and comfortably handles write rates that dwarf what most products ever see. The ceiling is not "small," it is "single-node."

What you cannot do, out of the box, is spread writes across multiple PocketBase nodes the way you would horizontally scale a stateless API behind a load balancer. Realtime subscriptions are per-instance. The database is per-instance. If your plan is "we'll just add nodes when we grow," PocketBase will not cooperate with that specific plan without you engineering around it (read replicas are possible for SQLite with external tooling, but write scaling is the hard part and it stays single-writer). For the typical self-hoster — a SaaS with a few thousand users, an internal tool, a side project, a community site — this ceiling is never reached. For a consumer-scale, write-heavy global product, it is a real constraint you should choose something else for.

The right framing: PocketBase trades horizontal write-scaling for operational simplicity and total ownership. That is a defensible trade for the majority of builders, and a disqualifying one for a specific minority. Know which you are before you build.

17. Security Reality Check

No honest review skips the security posture. PocketBase is MIT-licensed and actively maintained; recent releases have shipped genuine security and stability fixes, including a v0.39.7 patch that wrapped internal worker goroutines so a panic could no longer crash the whole process, and a v0.40.0 bump to SQLite's defensive mode plus tighter default headers. The maintainers also swapped a validation dependency to a trusted fork after an upstream maintainer-trust concern surfaced — a supply-chain precaution that signals attentiveness.

The other side of the ledger is maturity signals that a cautious operator should note. Public OpenSSF Scorecard ratings for the project have sat in the mid-single-digits (out of 10), reflecting gaps in provenance and disclosure signals rather than a known exploit in the door. A few security advisories have been filed over the project's life. The maintainer bus factor is effectively one — Gani Georgiev is the primary author — which is common for indie OSS but is a concentration risk for anything mission-critical. None of this means "do not run it"; it means "run it like you would any small but important dependency: pin versions, read release notes, patch promptly, and keep tested backups." The simplicity of a single binary cuts in your favor here, because patching is a restart, not a migration weekend.

18. PocketBase vs Supabase vs Appwrite vs Firebase

A backend comparison is only useful if it is honest about fit. Firebase is the managed incumbent: fastest to start, deepest ecosystem, but your data lives in Google's cloud and your bill scales with usage and lock-in deepens over time. Supabase is the open-source, self-hostable Postgres option — you get a real relational database with streaming replication, a mature SQL story, and horizontal scale when you need it, at the cost of operating Postgres plus a handful of companion services. Appwrite is another self-hostable BaaS with a broader multi-service surface and a BSD license, trading some of PocketBase's "one binary" simplicity for more moving parts.

PocketBase's wedge is the opposite of all three on the operations axis: minimum moving parts, maximum ownership, smallest footprint. You give up Postgres-grade SQL power and horizontal scale; you gain an install that is a single file and a backup that is a single folder. For a solo dev shipping a product this quarter, that trade is often correct. For a team that already lives in Postgres and expects to scale writes across regions, Supabase is the more natural home. Choose by deployment constraint, not by star count — and note that because all of these are covered on this blog, you can read the self-hosting deep dives for Supabase and Appwrite back to back with this one.

19. Who Should — and Shouldn't — Run It

Run PocketBase if you are a solo founder, indie hacker, small team, or homelabber who wants a backend you fully own without becoming a DBA. It is excellent for side projects, MVPs, internal tools, community sites, prototypes that might become products, and anyone who values "I can see my data as a file on my disk" over "someone else scales it for me." If your expected load fits on one server — which is most loads — you will likely never feel the ceiling.

Do not reach for PocketBase as your primary backend if you know upfront that you need write-horizontal scaling across regions, a deep SQL analytics warehouse, or a vendor-backed SLA with support contracts. It is also a weaker fit if your organization forbids single-maintainer dependencies on architecture-critical paths and will not accept the mitigation of pinning plus backups. And if your team cannot commit to the operational basics — TLS, patching, tested backups — then no self-hosted tool serves you; the managed option exists precisely to absorb that work, and you should pay for it rather than pretend the responsibility vanished.

20. Migrating Away: The Exit Strategy

Sovereignty is also about the freedom to leave, so the exit deserves a concrete look. PocketBase stores your data in a standard SQLite file with a documented schema, and it exposes your collections through a REST API and a full export. Migrating out means: export your collections as JSON definitions, pull your records via the API (or read them straight from SQLite with any SQLite client), copy pb_data/storage for your files, and re-import into whatever comes next. There is no proprietary blob format and no "please contact sales to retrieve your data" gate.

The realistic friction is translation, not extraction. PocketBase's API-rule model, its realtime semantics, and its hook logic do not map one-to-one onto Postgres-plus-XXX or Firebase. You will rewrite access-control as SQL policies or security rules, reimplement hooks as functions or triggers, and rebuild realtime on your target's pub/sub. The data itself is portable; the behavior around it is work. That is the honest shape of every migration, and it is exactly why starting on an open format like SQLite — rather than a closed one — keeps the most expensive part of you, your records, free to move.

21. The Bus Factor and Governance Question

Every piece of infrastructure you depend on has a human behind it, and PocketBase's human count is small. The project is overwhelmingly the work of one maintainer, funded largely through GitHub Sponsors and a growing paid "PocketBase Cloud" offering that the author runs. This is a common and not dishonorable structure for successful indie open source, but it is a concentration risk you should price into anything you stake on the software.

The MIT license is your shield here. Because the code is permissively licensed, you can fork it, pin it, and keep building on your fork forever if the upstream ever stalled — you are not at the mercy of a license that snaps shut. The practical mitigations are simple: pin a known-good version, mirror the source and the binary, keep your pb_data backed up and exportable, and treat upgrades as reviewed events rather than blind pulls. Do that, and the bus factor becomes a manageable risk rather than a ticking clock. Ignore it, and you have replayed the oldest story in open source: a dependency you loved, run unattended, on something you cannot afford to lose.

22. Bottom Line

PocketBase is the closest thing we have to a backend you can hold in one hand. One MIT-licensed Go binary gives you a database, realtime, auth, file storage, and an admin UI you actually keep — and every byte of it lives in a folder you own, on a disk you chose, under rules you write. For the self-hosting and data-sovereignty mission of this blog, that is about as on-theme as software gets.

The price of that simplicity is operational and structural. You run the server, you patch the binary, you back up pb_data and you test the restore. You accept a single-writer SQLite ceiling that is generous for most apps but disqualifying for write-heavy global scale. You note a small bus factor and a middling supply-chain scorecard, and you mitigate both with pinning and backups. None of these are reasons to avoid it; they are the honest terms of ownership, which is the entire point of self-hosting in the first place.

If you are a builder who wants to ship something real this quarter without renting your users' data back from a vendor, PocketBase is one of the strongest starting points available in 2026. Run it on a $5 VPS or a Pi on your shelf, point a domain at it, back up the folder, and you have a backend that is genuinely, verifiably yours.