The API framework forged in Rust

Ferra.rs

One #[model]. Five things derived. Production-ready APIs in Rust — without writing the same struct five times.

[dependencies] ferra = { package = "ferra-rs", version = "0.1" }
use ferra::*;
Watch for RC
src/main.rs
#[model]
struct Film {
    #[id]
    id: Id,
    title: String,
}

let app = Foundry::new()
    .mount::<Film>(state)
    .build();
// 5 routes · HAL · OpenAPI · typed SQL — from 8 lines.
5 routes HAL _links OpenAPI 3.1 typed SQL
Three pillars

The three pillars
of Ferra.

Security. DX. AI.

Not features bolted on — gravity. Every design decision in Ferra falls toward a single source of truth: one Rust struct, written once.

What you write once becomes routes, SQL, validation, OpenAPI — all of it, forever, automatically.

01 · Security-first

Refuse first.
Permit second.

An API should close every door before opening any. In Ferra the defaults aren’t safe — they’re hostile to your future bugs.

  • SQL parameterized at the type level
  • #![forbid(unsafe_code)] on every crate
  • Missing auth = startup panic, not silent gap
02 · DX-first

Struct to documented API in five minutes.

Write the model once. Routes, SQL, validation, OpenAPI — all generated, all inspectable. Your time is the product.

  • Errors tell you what / where / how to fix
  • Generated code readable via cargo expand
  • ferra-anvil scaffolds, never lectures
03 · AI-first

Built for the agents that will read it next.

Every response carries its own map. Every endpoint is self-describing. The next generation of software is a consumer, not an afterthought.

  • HAL _links in every response
  • OpenAPI 3.1 at /docs/openapi.json
  • Native MCP tools in v5.0 — Precision Steel
Convergence Three forces. One source of truth. One #[model] struct — everything else follows. See what it gives you
Tie-breaker, when the three pull against each other: security > DX > AI. Documented, not negotiated.
The payoff

One model, everything else.

The three forces converge here. You write a Rust struct — one source of truth — and Ferra hands back the routes, the SQL, the schema, the docs, the hypermedia, and the guarantees. Five jobs collapsed into one.

What you write
What you get
#[model] struct Film
REST routes — GET, POST, PUT, DELETE
·
SQL queries — parameterized, injection-proof
·
OpenAPI 3.1 spec at /docs/openapi.json
·
Interactive API docs (Scalar UI)
·
HAL hypermedia _links in every response
·
Compile-time correctness — if it builds, it’s correct
< 5 min
The zero-to-API benchmark. A developer with a Postgres database and a Rust struct reaches a running, documented, hypermedia-compliant CRUD API in under five minutes.
Foundations

Built on Rust’s strengths.

Ferra doesn’t fight the language — it amplifies it. Every design decision compounds the guarantees you already get from cargo build.

01

Compile-time over runtime

Mismatched routes, missing IDs, broken schemas — caught by cargo build, not in production at 3am.

02

Zero-cost abstractions

No reflection, no caching layer, no runtime overhead. p99 latency target: under 1ms.

03

Security by construction

SQL is always parameterized. CORS is restrictive by default. Auth is a first-class pipeline stage.

04

#![forbid(unsafe_code)]

On every crate, no exceptions. Ferra inherits Rust’s memory-safety guarantees end-to-end.

Targets

Runs wherever Rust runs.

One #[model], every target. Plug Ferra into any Tower-compatible HTTP runtime, ship it to a long-running server, a serverless function, or the edge — the API you wrote stays the API you deploy.

HTTP/1 · 2 · 3
Tower-compatible stack
Axum · Hyper · Actix
Plug into any runtime
Lambda · Cloud Run
Serverless from v0.14
Workers · Edge
Same #[model], any target
The name

Ferrum.

Latin for iron.

Ferra continues Rust’s metallurgical lineage — from ore to vessel to mascot to the metal itself. The roadmap follows the lifecycle of iron: from raw ore to precision steel.

Rust

Iron oxide

Cargo

The vessel that carries ore

Ferris

The mascot — ferrous, iron-bearing

Ferra

Iron itself

The vision

From ore to precision steel.

Five eras, each named for a step in the iron lifecycle. The foundations are shipped; we’re rolling out beta capabilities one version at a time on the way to a stable 1.0.

Shipped
v0.1 → v0.4

The Ore

Foundations are in place. You can already write a working CRUD API in under 25 lines.

  • Excavation · workspace + IR
  • Smelting · #[model] macro
  • Casting · typed SQL
  • Refining · CRUD + HAL
Building
v0.5 → v0.14

Cast Iron

APIs usable but not yet stable. Each version adds one major capability.

  • Rolling · OpenAPI + Scalar (now)
  • Welding · validation + RFC 7807
  • Forging · auth + JWT + roles
  • Polishing · relations + embeds
Next
v0.15 — 1.0

Hardened Steel

Security audit, benchmarks, OSS launch prep. crates.io publication. SemVer guaranteed.

  • Audit & benchmarks
  • Public 1.0 release
  • Long-term support track
Vision
v2.0 — v4.0

The Alloy → Arsenal

GraphQL, WebSockets, SSE, JSON-LD. Multi-backend storage. Plugin system, admin UI, observability.

  • Alloy · GraphQL + WS + SSE
  • Foundry · Mongo, Redis, Scylla
  • Arsenal · plugins + admin
Far horizon
v5.0

Precision Steel

Native MCP tools, LLM schemas, agent SDK — APIs that read themselves to language models.

  • Native MCP tools
  • LLM-aware schemas
  • First-class agent SDK
Invariant
A #[model] written for v1.0 compiles without modification in v2, v3, v4, and v5. Stability is not a feature — it’s the contract.
RC gate

The targets we ship 1.0 against.

Numbers we hold ourselves to before tagging Hardened Steel — measured on a baseline Postgres-backed Film CRUD service.

Zero to working API with docs
< 5min
Lines of code for Film CRUD
< 20loc
GET p99 latency
< 1ms
Incremental compile (1 field change)
< 5s
Server startup time
< 50ms
OpenAPI spec ↔ deployed code
1 : 1
Guaranteed — impossible to compile otherwise.