The capsule — starting a full-stack app, not just hosting one

Update, 31 July 2026 — managed inference is switched off. This post is

kept as written on 4 July 2026, and one thing in it is no longer true: the

capsule's src/lib/ai.ts no longer works. /capsule/<app>/ai returns

503 INFERENCE_DISABLED and the build no longer injects its URL. Nothing is

missing from the feature — it was disabled pending the data-transfer

paperwork for sending an app's prompts to a US provider. It is being rebuilt

on Scaleway-hosted models in Paris and stays off until that processing is

approved; GET /capabilities reports the state of any one instance, and a

capsule never receives a provider key either way. Everything else below still

describes the capsule accurately. See

Managed AI inference.

Most of what Percher does is host an app you already have. The capsule template is the other direction: it hands your assistant a working full-stack app to start from.

The problem it solves is the blank folder. Ask an assistant to "build a full-stack app with a database and login" and it faces a dozen decisions before it writes a line of feature code: which database, how migrations run, where auth lives, how the client talks to the server, how secrets get in. Each one is a place to guess wrong. And you often don't find out until the deploy fails or the login silently doesn't work.

The capsule makes those decisions ahead of time. One command scaffolds the app:

bunx percher create my-app --template capsule
bunx percher publish

What comes up is a real app, not a skeleton. A PocketBase database whose schema Percher provisions before the container goes live, so the tables exist on the first request rather than after a migration you forgot to run. Email-and-password sign-in, with Google a single percher data oauth google away. Realtime subscriptions. A typed database client. And, at the time of writing, managed inference in src/lib/ai.ts with no API key to paste — that part is currently switched off, see the note above.

From there it's the normal loop. You describe a feature, your assistant edits the capsule and republishes, and the schema, auth, and AI are already there to build against. It's the difference between "wire up a database" and "add a table" — the first is where assistants stall, the second is where they're good.

Two honest edges. The capsule is for starting something new; if you already have an app, the framework detection in percher init is the path, not this. And the database is PocketBase — SQLite with auth and file storage in one container. It's the right shape for the apps the capsule is for, but not a drop-in for Postgres. If you need Postgres, point DATABASE_URL at one you run.

That's the whole idea. Your assistant is good at building on something that works and worse at assembling the foundation. The capsule is the foundation, provisioned and live, so the building can start on the first prompt.