Deployment Architecture
The backend runs two different ways depending on environment — with identical route logic either way.
| Environment | Entry point | Storage |
|---|---|---|
| Local dev | src/index.ts | sqlite file on local disk |
| Vercel (serverless) | api/index.ts | Redis (Vercel KV / Upstash) |
Why two storage backends
Serverless functions have no persistent disk — a sqlite file written during one invocation
isn't guaranteed to exist (or be consistent) on the next. api/index.ts always builds the
app with Redis-backed stores instead. Both entry points construct the identical Fastify app
from the same route/business logic; only the injected storage implementation differs.
Note
The Redis-backed rate limiter does a plain read-then-write rather than an atomic transaction — see Rate Limiting Policy for the accepted trade-off this implies under concurrency.
Routing
vercel.json rewrites every incoming path to /api/index, so the deployed API surface is
exactly /healthz, /v1/provision, /v1/salt/:accountId — identical to the local-dev
contract, with no /api prefix leaking into it.
Live deployment
The backend API runs as its own Vercel deployment, entirely separate from this documentation site — deploying a new build of one never redeploys or affects the other.