Show HN: Replaces Supabase and FastAPI

Humanity's last backend. Built for AI agents.

The AI-native Rust backend framework + generation platform. Agents design, generate, verify and package complete backends. You never write the code.

jerrycan.cc · AI-native docs · Why jerrycan exists · llms.txt

$ jerrycan new --design bookmarks.json       # describe it once
  ✓ scaffolded a crate-per-module workspace

$ jerrycan gen-tests --module bookmarks      # the test suite is generated for you
  ✓ 8 acceptance tests written

  …an agent fills in ~12 lines of obvious handler glue…

$ jerrycan --json check                      # build · clippy · audit · tests · lints
  {"ok":true,"diagnostics":[]}               # all green: safe + tested, no internals leaked

0.2.0, published onExpect rough edges as it grows.[crates.io]. Early but real.

Agents build it, you don't. Describe the API once; jerrycan generates the workspace, a working data layer, and the tests. Handlers come out as a few lines of obvious glue.Secure by default. Secure response headers, body limits, strict input handling,no internals leaked in errors,#![forbid(unsafe_code)]

everywhere, and stableJC####

codes that deep-link into the docs.Tested before it's "done". jerrycangeneratesthe acceptance suite test-first;jerrycan check

won't go green until it passes. What the generator can't derive from the contract becomes an explicitAGENT TODO

in the test file, so the gaps are named instead of silent.Fail loud. Conflicting routes are build-time errorsbeforeserving; missing dependencies and cycles are coded errors, not mysteries.Multi-agent ready. Generated apps are crate-per-module workspaces with compiler-enforced boundaries, so parallel agents merge without conflicts.Deploy anywhere, deployed by the agent.jerrycan package

produces a static binary, a hardened container image, k8s manifests, or a systemd unit, with an SBOM.jerrycan deploy render

writes a deploy kit the agent executes with an API key: design file to live URL, no human in the loop.Docs that can't lie. Every example in the docs is a doctest executed in CI.

cargo install jerrycan          # the CLI + MCP server

Wire the MCP server into your agent, then ask for a backend in one prompt:

claude mcp add jerrycan -- jerrycan mcp
// Cursor / any stdio MCP client
{ "mcpServers": { "jerrycan": { "command": "jerrycan", "args": ["mcp"] } } }

The agent drives the whole loop: design → scaffold → gen-tests → implement → check → package → deploy. Claude Code users also get the bundled jerrycan-backend skill that guides the process end to end. Point any other agent at

docs/aior

jerrycan.cc/llms.txt; the docs are written to be sufficient on their own.

cargo add jerrycan --features db,auth,validate,observe

A route module is Flask's Blueprints, reborn with compiler-enforced boundaries. Everything a handler needs is visible in its signature, and guards are just dependencies:

use jerrycan::prelude::*;

pub fn module() -> Module {
    Module::new("todos")
        .route("/", get(list).post(create))
        .route("/{id}", get(show).delete(remove))
        .mount("/{id}/comments", comments::module()) // subroutes nest arbitrarily
        .provide(TodoRepo::new())                    // module-scoped dependency
}

async fn list(repo: Dep<TodoRepo>) -> Result<Json<Vec<Todo>>> {
    Ok(Json(repo.all().await?))
}

async fn remove(_: Dep<Admin>, repo: Dep<TodoRepo>, Path(id): Path<i64>) -> Result<NoContent> {
    repo.delete(id).await?;            // `Dep<Admin>` is the guard: a dependency that must resolve
    Ok(NoContent)
}

Testing runs real requests in memory, no sockets, and any dependency can be faked in one line:

let t = app().into_test().override_dep(Db::fake());
assert_eq!(t.get("/todos/").await.status(), jerrycan::http::StatusCode::OK);

The agent drives one fixed loop; jerrycan does the generation and the gating:

jerrycan_design    → requirements become a validated design.json (pointed questions, not guesses)
jerrycan_scaffold  → a crate-per-module workspace, one route crate per module
jerrycan_gen_tests → failing acceptance tests, generated from the design
   (the agent implements the handler bodies, guided by the docs tools)
jerrycan_check     → build + clippy + audit + tests + jerrycan lints, machine-readable diagnostics
jerrycan_package   → hardened artifacts + SBOM, only when everything is green
jerrycan_deploy    → a deploy kit for the target platform (Render first), run by the agent

Project layout of the framework itself

crates/
├── jerrycan          # facade + the CLI/MCP binary, apps depend on this
├── jerrycan-core     # routing, extractors, DI, modules, middleware, errors, test client
├── jerrycan-macros   # #[jerrycan::main]
├── jerrycan-db       # data layer + migrations (SeaORM)
├── jerrycan-auth     # sessions, JWT, OAuth2, guards
├── jerrycan-validate  # validation + OpenAPI
├── jerrycan-observe   # logs, /healthz, /metrics
├── jerrycan-ratelimit # rate limiting (429 JC0429)
└── jerrycan-jobs      # background jobs, cron, retries (Postgres / Redis)
docs/
├── ai/               # the AI-native docs, every example is a CI-run doc-test
└── contracts/        # MCP tool schemas, design.json schema, CLI UX spec

Yes, and it's measured, not asserted. A docs-only agent (given only jerrycan docs

, no framework source, no fixtures) builds real backends that pass jerrycan check

and serve real HTTP:

5/5 of the reference CRUD apps: green on the first run, zero doc gaps.- The full multi-tenant SaaS slice: green across 6 modules + 2 background jobs, driven** live over HTTP**. Auth, per-tenant isolation, signed webhooks, CSV import, scoped API keys, OAuth. A** negative control**(breaking tenant scoping) correctly turns the gate** red**, so the green isn't hollow.

It's wired as an un-skippable release gate (CI + a fail-fast pre-publish block), so it can't silently regress. Full write-up: conformance/eval/results.md.

For: CRUD-shaped, multi-tenant REST APIs. The backbone of most SaaS.

Not (yet): realtime / WebSockets, GraphQL / gRPC, blob storage, edge / serverless. jerrycan runs as a normal long-lived service. We'd rather name the edges than oversell the middle.

jerrycan stands on the Rust ecosystem you already trust, and emits plain Rust you own:

Rust · Tokio · hyper · SeaORM · serde · clippy · cargo-audit

Phases 0-4 + the full v2 cycle, all complete (click to expand)

The v1 plan is in the v1 design spec; the v2 roadmap is in the v2 design spec; deferred items are in the backlog.

Build · test · lint · bench · fuzz

cargo test --workspace --all-features   # CI runs this, every docs example is a doc-test
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo fmt --all --check
cargo bench                             # criterion benches (routing, extraction)
cargo +nightly fuzz run <target>        # fuzz targets live in fuzz/ (outside the workspace)

The project is built docs-first and test-first: documentation examples are the executable specification.

jerrycan is built by one developer and a fleet of agents. Sponsorship pays for the eval infrastructure, the deploy targets, and the time it takes to keep the gate honest.

Licensed under the MIT License.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be licensed under the MIT License, without any additional terms or conditions.

jerrycan.cc · AI-native docs · GitHub @backant-io