PocketBase

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the backend in the shape PocketBase has: SQLite, authentication, file storage, realtime and an admin interface, in one process on one machine.

Read this first: PocketBase is free and is a single binary — nothing is being saved in fees. Build this when you want the same shape in your own language and with your own decisions, and read the honest note at the end about where the one-process design stops.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode. One file, and it will handle far more than you expect
- Local disk for files
- Server-rendered admin, no client-side framework
- Caddy in front

THE SHAPE
- One process, one database file, one command to run it. That simplicity is the entire proposition, and every design decision below defends it
- Migrations applied on boot, each once, in order, from files in the repository
- Everything configured by environment variables, with sensible defaults so it runs with none

COLLECTIONS
- collections: id, name, kind, schema_json, rules_json, indexes_json — a base collection, an auth collection, or a view
- Data lives in real SQL tables, created and altered by generated migration files. Not a generic key-value store: real columns mean real constraints, real indexes and fast queries
- Field types: text, number, boolean, email, url, date, select, relation, file, json, editor. Each with a parser, a validator, a formatter and a filter set
- A relation is a real foreign key; a multiple relation is a join table. Both created properly
- Schema changes through the admin write a migration file, so the production deploy applies the same change rather than a different one

API RULES, WHICH IS THE IDEA WORTH COPYING
- Each collection has five rules — list, view, create, update, delete — each an expression over the request's authenticated user and the record
- `@request.auth.id != "" && owner = @request.auth.id` is most of what an application needs, expressed in one line and enforced in the query
- Parsed into an AST and compiled into a WHERE clause. Never string-concatenated, never evaluated
- An empty rule means locked to admins only. Default deny, always
- The rule is applied inside the query, so a forbidden record is absent rather than filtered afterwards

AUTHENTICATION
- An auth collection is a normal collection with identity fields attached
- Passwords with argon2id and nothing else
- Email verification, password reset and email change, each by a single-use expiring token compared in constant time
- OAuth against the common providers, with the token exchange on the server
- Sessions as long random tokens stored hashed, in an httpOnly secure sameSite cookie, with a device list and central revocation
- Rate limits on every authentication route by address hash and by account, with identical responses and timing for an unknown address and a wrong password

FILES
- Uploads streamed to disk, never buffered whole
- Type from the file's own content, size capped per field, stored by hash outside the web root
- Served through a handler that applies the same access rules as the record, or through a signed expiring token
- Image transforms on demand — resize, crop, format — with the parameters signed so nobody uses your server as a free image farm, and the result cached
- Deletion is real, including derivatives, and refused while a record still references the file

REALTIME
- Server-sent events, one connection per client, subscribing to collections or records
- The subscription is authorised at connection time and re-checked against the rule for every event, so a rule change takes effect immediately
- Events emitted after the transaction commits, never before

THE ADMIN
- Collections, records, rules, files, logs and settings
- A rule tester: pick a user and a record and see whether the rule passes and why
- Server-rendered, fast, works on a phone
- Behind its own authentication, separate from application users, with the option to bind it to a private interface only

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL, HASH_SALT, OAUTH_*
- Nightly backup with VACUUM INTO, gzipped, uploaded off the machine, with a tested restore script
- Structured logs with tokens and secrets redacted
- Health endpoint touching the database, the disk and mail

THE HONEST LIMIT
- One process and one SQLite file means one machine. That is fine for a very large number of applications — SQLite on a modern disk handles thousands of writes a second — but it does not scale sideways, and a long-running query blocks writers
- Write down what you would do if it stopped being enough: read replicas, or a move to a client-server database with the same schema. Knowing the exit is what makes the simple choice safe
- Backups are the whole disaster-recovery story here, so test the restore rather than assuming it

WHAT MATTERS MOST
The rule engine and authentication. Compile rules into the query rather than filtering afterwards, and get sessions, hashing and rate limits right before anything else. Those two are where a mistake is somebody else's data.

Give me the repository, migrations, .env.example, an example application built on it, and a README with deploy steps behind Caddy and the scaling limit stated.