Pockethost: a multi-tenant hosting platform for PocketBase

One PocketBase per tenant, on its own subdomain

Pockethost is a multi-user, multi-tenant hosting platform for PocketBase, and with it you can run hundreds or even thousands of PocketBase instances on a single server or across a global edge network.

The multi-tenancy is the interesting part. PocketBase is an excellent single-tenant backend, and it is also an embeddable Go application that a host can run many copies of. What Pockethost adds is everything around that copy: a place in the DNS, a certificate, a routing rule, a way to know which tenant owns which instance, and a way to create and destroy instances on demand.

The four headline features are the summary of that. Unlimited instances, so you spin up as many PocketBase instances as you need. Per-instance subdomains, where each instance is isolated and accessible at its own subdomain, so a tenant never shares a hostname with another. Secure by default, running in Docker with automatic SSL certificates, which removes the part of running a public backend that most often goes wrong. And custom domain support, connecting a customer's own domain via a CNAME.

The quickstart is a single command:

npx pockethost serve

which is a reasonable thing for a platform whose basic job is running a well-known single-binary backend for other people.

The command surface, from one server to an edge network

The README groups the commands by what you are trying to do, and the grouping is the clearest description of the architecture.

The scaling section covers pockethost firewall, pockethost mothership, pockethost edge:daemon, pockethost edge:syslog, pockethost edge ftp, and pockethost sftp.

So there is a mothership, which is the control plane, and edge components, which run the instances close to the users. The firewall command is the network control point, the edge:daemon is the process that serves instances, edge:syslog handles log shipping, and edge:ftp is a file transfer path for the edge nodes. The sftp command gives Ed25519 SSH key file access on port 2222, and the README points at the /docs/ftp page on the dashboard for that.

The other commands are pockethost download and pockethost health, which are the everyday ones, fetching a binary and checking on the state of things.

The fact that the edge nodes are separate processes with their own log pipeline is what makes the global edge network claim more than marketing. A single server running a thousand instances is a different problem from a thousand instances spread over a network with a control plane that keeps score, and the command list covers both.

The monorepo behind the CLI

The repository is a pnpm workspace, and the root package.json names the pieces, which is the clearest way to understand the project.

The CLI lives in packages/pockethost, with dev:cli and prod:cli scripts that change into that directory. There is a phio package, run in development with node --import tsx packages/phio/src/cli.ts, which is a separate command line entry point. The dashboard is packages/dashboard, published under the scope @pockethost/dashboard, and there is a mothership app, pockethost-mothership-app, with its own dev and check scripts.

The check:push script shows how the pieces are verified together. It runs the lint, then type checks for pockethost, for phio and for the dashboard, then a dedicated check of the mothership hooks, then the test suite. check:ci takes that and adds a dashboard build, which is the check that matters for a deployment, since it is the only one that proves the front end compiles rather than merely type checks.

The rest of the root scripts are operational rather than developmental. prod:cli starts the CLI in production mode, mail runs the mail command, live-sync runs a shell script in the pockethost package, and nofile simply cats /proc/sys/fs/file-nr, which is a utility for checking the host's file descriptor limits when you are running many instances at once.

The tree also carries a setup.sh, a mothership.sh, an ecosystem.config.cjs for the process manager, a patches/ directory, a .env-template, a vacuum-plan.md for the database maintenance, a backlog.md and a ROADMAP.md, and a MEMORY.md.

Tooling that leans on pnpm workspaces and modern Node

The root package metadata sets the constraints clearly. The package is marked as an ES module, the engine requirement is Node 24 or newer, and the package manager is pinned to pnpm 11.6.0, with a pnpm-lock.yaml and a pnpm-workspace.yaml in the tree.

The dependency choices are all current. TypeScript 6.0.3, Vitest 4.1.8 for the tests, and Prettier 3.8.4 with a small set of plugins, one for JSDoc formatting, one to organise imports, and one for Svelte, which tells you the dashboard is a Svelte application. Husky handles the commit hooks, and lint-staged runs Prettier over every changed TypeScript, JavaScript, Svelte and JSON file. The test script is vitest run, with a watch variant, and a vitest.config.ts at the root.

A .nvmrc is present, .prettierignore and .npmignore keep the published package tidy, and a .cursor directory with a .cursorignore suggests the project is developed with AI assistance configured in the repository, alongside a cspell.json for the spell checker.

For an adopter, the important number is Node 24. The platform runs other people's backends, often many per host, and the host has to be a modern one, so this is a floor rather than a suggestion.

Where Pockethost is the wrong choice

The first wrong-tool case is running your own application. If you need one PocketBase instance for one application, a PocketBase binary and a reverse proxy are the entire solution, and Pockethost adds a control plane, an edge topology, a dashboard and a tenant model you do not need. The platform's value is entirely in the multi-tenant case.

The second is a host that cannot run Docker. The secure-by-default feature is described as running in Docker with automatic SSL certificates, and that is the mechanism, so a locked-down environment without container support is outside the model rather than a supported configuration with a workaround.

The third is a team that wants to own the routing and the certificates. Pockethost takes over subdomain allocation and certificate issuance, which is a convenience if you are hosting for other people and a constraint if you want those decisions in your own infrastructure, behind your own wildcard certificate and your own ingress.

There is also a licensing and business dimension worth naming. The code is MIT, which is permissive, and the README carries a line that the project is sponsored by pockethost.io, an instant host for PocketBase projects. So the open source repository and the hosted service are the same project, and the hosted service is the obvious default for anyone who does not want to run the edge network themselves.

MIT, an active main branch, and a young platform

The project is MIT licensed, with LICENSE.md at the repository root, and the package metadata names the author as Ben Allfree with a link to their GitHub profile. The default branch is main, the repository is not archived, and the last push was on 2026-10-13, days before this review, so the work is current.

There are no GitHub releases, and the version of the platform is not in the root package, which is a private workspace root whose version field is not the shipped artifact. For a platform distributed as a command through npx, that is a reasonable arrangement, though it does mean the thing you run is whatever the registry currently serves.

The repository also carries the documents that show how the project is run. A ROADMAP.md and a backlog.md sit at the root next to a vacuum-plan.md, which is a plan for the database maintenance that a system with many tenants will need. There is a docs/ directory matching the documentation site, an assets/ directory with the banner, and a scripts/ directory.

The overall picture is a young, well-organised monorepo for a platform whose hard problems are the boring ones: certificates, routing, isolation, and the operational tooling to run many small services on one host.

Editorial conclusion

Adopt Pockethost if you are hosting PocketBase for other people, for example an agency giving each client its own instance, and you want per-instance subdomains, certificates and isolation handled for you. Do not adopt it for your own single application, since a single PocketBase binary is all that needs, and do not adopt it if you cannot run Docker on the hosts, because the secure-by-default model is built on it. Before you deploy, read the docs at pockethost.io/docs, decide how the edge nodes and the mothership relate to your own infrastructure, and check the engine requirements, since the package requires Node 24 or newer and pnpm 11.6.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pockethost/pockethost on GitHub
4. Project website
5. README