One library, not six services
By default every primitive runs on one Postgres database, so there’s nothing else to provision or operate. When one piece needs to scale, move it onto its own backend without changing your code.
Every app needs the same plumbing, and the usual answer is a separate service for each piece: Redis for caching and sessions, a queue for background jobs, object storage for uploads, something for auth, a cron runner, a rate limiter. That’s six things to provision, secure, mock in tests, and learn before you ship a feature. Forge gives you all of it in one library.
One library, not six services
By default every primitive runs on one Postgres database, so there’s nothing else to provision or operate. When one piece needs to scale, move it onto its own backend without changing your code.
The same API in three languages
Rust is the reference implementation. The Node and Python bindings wrap the same core and are checked against the same conformance suite, so behavior matches across all three.
Test on memory, ship on Postgres
The memory and Postgres backends pass the same conformance tests, so your suite runs in-process with no database and still behaves the way production will. Flip between them from an environment variable.
Made to hand to an agent
The API isn’t in any model’s training data. Install the companion skill and a coding agent learns which primitive fits which task before it writes a line.
[postgres]url = "${DATABASE_URL:-postgres://localhost/myapp}"One connection string is the whole setup. init() reads forge.toml, runs Forge’s
own migrations, and hands you a client with all eight primitives on it. Omit any
setting you don’t need and Forge fills in production-safe defaults.