Appwrite

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 I actually need instead of a hosted Appwrite: authentication, a database, file storage and scheduled jobs, in one Node service on one machine.

Read this first: the product you are replacing is open source, and self-hosting it is a real answer. What you pay for is a managed instance and SDKs for a dozen platforms. Build this instead when your application is one product with one team — a backend platform is a very general answer to a specific question, and the specific answer fits in a few thousand lines.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode. One file, backed up nightly, and it will handle far more than you expect
- Local disk for files, with an S3-compatible target for backups
- Caddy in front

AUTHENTICATION, THE PART WORTH GETTING RIGHT
- users: id, email, email_verified_at, password_hash, name, avatar_path, status, created_at, last_login_at
- sessions: id, user_id, token_hash, ip_hash, user_agent_bucket, created_at, last_used_at, expires_at, revoked_at
- Passwords with argon2id at sensible parameters, never anything else, and never a hand-rolled scheme
- Session tokens are long random strings stored hashed; the cookie is httpOnly, secure, sameSite lax, with a short life and a rotating refresh
- Email verification and password reset by single-use tokens that expire, are invalidated on use, and are compared in constant time
- Magic links as an option, and OAuth against one or two providers if the product needs it
- Two-factor with TOTP: a secret per user, a window of one step either side, and single-use recovery codes stored hashed
- Rate limits on every authentication route by address hash and by account, with a lockout that fails closed and an unlock path
- Never say whether an email exists — the same response for a wrong password and an unknown address, and the same timing

THE DATABASE LAYER
- Real tables with real migrations, applied once in order and never edited after they have run
- Every query parameterised. No string building, anywhere, ever
- A small repository module per entity rather than a generic query API — a generic API over your own database is a lot of work to reinvent SQL badly
- Row-level authorisation checked in the repository, so a missing check is a compile-time-obvious omission rather than a forgotten middleware

FILE STORAGE
- Uploads streamed to disk, never buffered whole in memory
- Type determined from the content, not the filename or the client's claim
- A size cap, a per-user quota, and a per-minute rate limit
- Files stored by hash outside the web root and served through a signed URL with an expiry, or through an endpoint that checks permission
- Images transformed on demand with sharp — resize, crop, format — with the parameters signed so nobody can use your server as a free image farm, and the result cached
- Deletion is real, including the cached derivatives

FUNCTIONS AND SCHEDULES
- Instead of a function runtime, plain modules invoked by a queue table with leases and retries
- Cron with a time zone, computed from the schedule and stored as a next-run instant
- Every run recorded with its input, output, duration and error
- Idempotency keys so a retry never repeats a side effect

REALTIME
- Server-sent events for pushing changes to a browser: one connection, no protocol to implement, and it reconnects by itself
- A channel per user and per resource, with authorisation checked at subscription time
- WebSockets only if the product genuinely needs the client to speak too

THE API
- REST with a clear shape, versioned in the path
- Every write endpoint checks that the request came from your own origin, and every state-changing form carries a token
- Errors in one shape with a code, a message and a field where relevant
- Rate limits per route class, per key and per address hash

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT, SMTP_URL, S3_*
- Migrations on boot, each once
- Nightly backup with VACUUM INTO, gzipped, uploaded off the machine, with a tested restore script
- Structured logs with secrets and tokens redacted by key and by pattern
- Health endpoint that touches the database, the disk and the mail connection

WHAT MATTERS MOST
Authentication. Build sessions, password hashing, the reset flow and the rate limits first, and try to break each one — a reset token that survives use, a login route with no limit, a session that does not rotate. Everything else here is ordinary work; this is the part where a mistake is somebody else's account.

Give me the repository, migrations, .env.example, and a README with deploy steps behind Caddy and the security decisions listed.