Rullst

⚡ Rullst in 30 seconds

With Rust installed (rustup.rs):

cargo install cargo-rullst --version =13.0.0-alpha.4 --locked
cargo rullst new my_app    # choose the Blank, API or SaaS starter
cd my_app
cargo rullst dev           # rebuilds and restarts every time you save

That's it: a running application, generated as readable Rust you can change — no hidden runtime magic. The first build compiles the framework's dependencies and can take a few minutes; later rebuilds are much faster (build times). The version is named because 13.0 is still a prerelease (why). Want a bigger starting point? Copy an application from examples/: a complete LMS, ERP or portfolio, or the blog showcase (where the examples live).

Installation and prerequisites · Zero-to-Hero tutorial · Build a JSON REST API · CLI reference

Stuck? cargo rullst doctor checks your toolchain and free disk space and, inside a project, its configuration, database and migrations. cargo rullst --help lists every command, cargo rullst tour walks through the main ones, and cargo rullst alone opens an interactive menu.

Recorded screenshot; layout and controls can differ by version. Development workflow.

🦀 Code that says what it does

use rullst::{html, routes, Markup, Server};

async fn home() -> Markup {
    html! {
        <div class="min-h-screen bg-slate-900 text-emerald-400 flex flex-col items-center justify-center font-sans">
            <h1 class="text-5xl font-extrabold mb-4">"Hello, Rullst! 📜🦀"</h1>
            <p class="text-slate-400 text-lg">"Your first typed route is running."</p>
        </div>
    }
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let app = routes![
        get("/" => home)
    ];

    Server::new(app).run(3000).await?;
    Ok(())
}

HTML lives in a compile-time html! macro, routes are typed and pages are server-rendered — HTMX-ready, with no JavaScript bundle to build. This snippet comes from the Zero-to-Hero tutorial, and CI compiles it straight from that page.

use rullst::{Server, ServerError, routes, server::Json};
use serde::Serialize;

#[derive(Serialize)]
struct HealthResponse {
    status: &'static str,
    framework: &'static str,
}

async fn health() -> Json<HealthResponse> {
    Json(HealthResponse {
        status: "ok",
        framework: "Rullst",
    })
}

#[tokio::main]
async fn main() -> Result<(), ServerError> {
    let app = routes![
        get("/api/health" => health),
    ]
    .layer(rullst::server::from_fn(
        rullst::security::headers_middleware,
    ));

    Server::new(app).run(3000).await
}

curl http://127.0.0.1:3000/api/health
# {"status":"ok","framework":"Rullst"}

Build your first REST API step by step.

Every capability has a documented boundary — security middleware does not replace your authorization rules, and databases are not interchangeable. See the capability ledger · Why Rullst? · Axum & SQLx escape hatches

🌍 Built with Rullst

Real applications running today, every one of them built with Rullst. Click to explore.

The demos scale to zero when idle, so the first visit can take a few seconds to wake up — that is hosting startup, not Rullst's request time. The SaaS checkout is live and charges real money; the Showcase payment demos are not.

▶️ Watch: how to build a SaaS with Rullst

Where the examples live

Rullst's examples have two homes:

• The live demos above — their code and deployment recipes are in the Rullst/examples repository. They are upgraded on their own schedule, so a demo can run an earlier Rullst release than the one this page describes.
• examples/ in this repository — applications built and tested with the current framework source: complete LMS, ERP and Portfolio applications (the former starters of cargo rullst new), the blog showcase and a WebGPU wave demo. The SaaS recipe generates the SaaS starter and runs its sign-in and tenant-scoped notes on a disposable SQLite database (Linux). Copy any of them to start from it; the examples guide shows how to run each one.

🏗️ Architecture

Rullst is a family of focused crates in one versioned workspace: v13 publishes 20 packages with the same version, and the rullst facade compiles only the features you select. Each package has a maturity tier. Core packages are needed by every application. Extensions are optional and supported. Experimental packages are optional, may change between 13.x releases and are not validated in every scenario — experimental does not mean broken. The maturity tiers page defines each promise, and the specification records the detailed feature and provider boundaries.

Crate	Focus	Tier
rullst	Public framework facade and feature selection	Core
rullst-core	HTTP runtime, routing, lifecycle and telemetry	Core
rullst-orm	Relational models, transactions and capability-specific persistence	Core
rullst-security	Defense-in-depth middleware, guards and audit helpers	Core
rullst-macros	Compile-time HTML and application macros	Core
rullst-orm-macros	Typed ORM code generation	Core
cargo-rullst	Project scaffolding, development and upgrade CLI	Core
rullst-auth	Passwords, sessions, passkeys and authorization helpers	Extension
rullst-connect

🤖 For AI assistants

The documentation site publishes llms.txt (an index of every book page in reading order) and llms-full.txt (the full Markdown of those pages in one file). Projects created with Rullst get their own AGENTS.md, .llms.txt and .rullst/context-map.json (cargo rullst generate:ai-context), and commands whose result is data accept --json (machine-readable output). Use them with the coding assistant you already have: 13.0 has no built-in terminal assistant (the cargo rullst ai command of earlier prereleases was removed). The rullst-ai crate, which adds AI features to your application, is not affected.

🎓 Learn with Rullst Academy

Rullst Academy is a free learning platform — built with Rullst — where you can learn Rust, Rullst, Git/GitHub, web development, databases and more through short lessons and practical projects, in Portuguese, English or Spanish.

Start learning at Rullst Academy ↗

🛡️ Engineered like critical infrastructure

Rullst is maintained with the rigor you expect from security software:

• No panics in production code, enforced by CI across the published runtime crates.
• No new unsafe outside a reviewed OS/FFI allowlist.
• At least 90% line coverage, enforced, plus 42 fuzz targets, property tests, sanitizers and Kani/Miri checks on selected critical code.
• Supply-chain hygiene: RustSec and license policy on every change, SHA-pinned Actions, and an SBOM with build-provenance attestation for every release.
• A fast Linux gate on every pull request, with the complete Linux/macOS/Windows matrix every night and before every release.

These results are evidence for their stated scope, not a security certification of every application built with Rullst.

Continuous or change-aware gate	Development main status	Actual scope
Rust CI		Format, all-target/all-feature Clippy, a Linux gate on pull requests, every Linux shard after merge and the complete Linux/macOS/Windows matrix nightly; Cargo-aware doctests sourced from every tutorial and the main guides, strict DB boundaries, feature boundaries, generated-code checks, and MSRV 1.96.0.
Declared MSRV		Every publishable manifest declares Rust 1.96.0 and CI runs an explicit workspace all-feature check with that toolchain.
GitHub Actions lint		Validates workflow syntax, expressions, embedded shell, and full-SHA third-party Action pins.
Documentation		Builds the mdBook and rejects broken local links and anchors; scheduled/manual runs also preserve an informational external-link report.
End-to-end smoke		Boots the release blog example and verifies HTTP, security headers, form flow, and SQLite persistence.
Codecov — whole repository		The badge reports the current branch aggregate. The enforced repository floor is with zero tolerance. For reference, the on the v12.0.0 release commit measured (79,813/88,365 lines) before Codecov upload.

Deep or irreversible workflows are intentionally not presented as continuously green main gates:

Deep evidence	Trigger and enforcement
Benchmark regression	Weekly, main push, or manual; eight published groups backed by nine Criterion benchmark binaries emit non-blocking alerts at a 20% regression.
Property testing	Weekly/manual release-mode invariant testing with 10,000 configured cases.
TSan and ASan	Daily/manual package matrices on a pinned verifier-only nightly.
Fuzzing / corpus minimization	Forty-two manual libFuzzer jobs, one per declared target, required as release evidence; weekly/manual corpus maintenance is informational.
OWASP ZAP	Manual baseline over three release surfaces: the generated REST API and the LMS example are blocking with no ignored alerts; the deliberately CDN-backed blog showcase remains an explicitly informational boundary.
Kani, Miri, mutation testing, cargo-udeps	Manual or scheduled research signals: selected Kani/Miri scopes are strict, while mutation and unused-dependency findings remain explicitly informational.

Scheduled events use the repository's default branch, so scheduled and continuous development evidence refer to main; the frozen v12 line has its own branch. The branch-protection profiles and the exact scope of all 37 workflow definitions in this source branch are documented in WORKFLOWS.md.

• 📖 CI/CD and security workflows: the exact scope of all 37 workflow definitions and the branch-protection profiles.
• 🧰 How the repository is maintained: workstation rules, CI gates, fuzzing evidence and release admission.
• 📋 Capability status · capability ledger · per-commit quality scorecard · OpenSSF Scorecard evidence · v12 release audit

🔄 Upgrade with a preview

To move an existing application to a newer Rullst, install the newer CLI and run, from the application's root:

cargo rullst upgrade --dry-run
cargo rullst upgrade

The CLI coordinates dependency updates, reports the source changes a release needs at file:line, backs up controlled files and runs compiler checks. Review the plan and your application's behavior; it does not migrate production data. Assisted upgrade tutorial · v12 → v13 adoption guide

🚀 Versions: v13 is a prerelease

13.0.0-alpha.4 is the latest v13 prerelease and the 13.0 feature freeze; 13.0.0-rc.1 (fixes and documentation only) and then 13.0.0 follow. Cargo never selects a prerelease on its own, so cargo install cargo-rullst and cargo add rullst without a version still pick the end-of-life 12.x. Until 13.0.0 is released, name the exact version:

cargo install cargo-rullst --version =13.0.0-alpha.4 --locked

Projects generated by cargo rullst new already pin the framework with =13.0.0-alpha.4. In a hand-written Cargo.toml, use = too: a plain "13.0.0-alpha.4" also accepts later prereleases, whose API may change. rullst has no default features, so name the database profile you use and capabilities such as auth or nexus (feature matrix):

[dependencies]
rullst = { version = "=13.0.0-alpha.4", features = ["strict-postgres"] }

The v12 line reached end of life on 16 October 2026: 12.3.0 is its last release and the v12 branch is frozen (v5 is no longer maintained either). crates.io has since yanked the zip releases that 12.x's Studio needs, so a new 12.x project no longer resolves its dependencies; existing projects with a Cargo.lock keep building. Start new work on v13, and move existing applications with the v12 → v13 adoption guide.

What is new in v13

Since 12.x. The changelog and the v13 adoption guide list every change.

• Three starters and complete examples: cargo rullst new offers Blank, API and SaaS through a wizard that previews the files and commands before writing anything (--dry-run without prompts) and initializes a Git repository (--vcs none skips it). The LMS, ERP, Portfolio and blog applications are in examples/ to copy from.
• A friendlier CLI: cargo rullst tour (a guided walkthrough of the main commands), a searchable command list on the cargo rullst home screen, live request metrics in cargo rullst dash, toolchain, project, database, migration and disk checks with fixes in cargo rullst doctor, cargo rullst completions <shell>, and cargo rullst add <capability> to enable mail, auth, AI, Nexus or Studio in an existing project.
• One deployment path: cargo rullst deploy writes a Dockerfile, compose.yaml and Caddyfile for any Linux VM with Docker or Podman, with guides for Hetzner Cloud, DigitalOcean, Oracle Cloud and Google Cloud (guide).
• Security evidence report: cargo rullst audit --report writes a Markdown, HTML or JSON report mapped to OWASP ASVS 5.0 Level 1, with a personal-data inventory and accessibility checks — evidence for a reviewer, not a certification (guide).
• Efficiency figures (Experimental): cargo rullst green reports measured binary and image size, idle memory, dependency count and CPU time per request, each with its method, and a carbon figure only as a labelled SCI estimate from your own inputs (guide).
• For AI assistants: every --json output follows one contract with a schema id, and the site publishes llms.txt and llms-full.txt.
• Faster development builds: generated projects get a development profile that shortened their first build by 15 to 19 % and a rebuild after an edit by about half on the measuring machine ().

• The Omni Tauri shells (make:omni, omni) and offline-sync: use a PWA.
• rullst-capital providers other than Stripe and the experimental InfinitePay, payouts and NFS-e: use those or an application-owned adapter on the provider traits.
• rullst-mail providers other than Resend, AWS SES, SendPulse and SMTP: write a MailDriver in your application.
• The orm-polyglot and polyglot features, which enabled every storage adapter at once: name the adapters you use.
• The CLI's Foundry (foundry:init, foundry:deploy), Nix (nixify, new --nix), Buildah (generate:buildah, new --buildah) and gRPC (make:grpc) generators: files they wrote stay yours, and the Advanced deployment page shows Nix, Buildah, Podman Quadlet and Kubernetes setups.
• The Fly.io, Render and Railway targets of cargo rullst deploy: it writes the Dockerfile, compose.yaml and Caddyfile for a Linux VM; existing provider files keep working with the provider's own CLI.
• The self-updater's download and binary replacement (update check, update verify, update stage, update install): install a newer CLI with cargo install cargo-rullst --version =<version> --locked, which a daily notice prints.
• The LMS, Blog, Portfolio and ERP starters of cargo rullst new: they are applications in examples/.

The v13 adoption guide gives each change its replacement, and cargo rullst upgrade --dry-run reports the ones your application uses.

v13 roadmap · Compatibility policy · v12 release record

⚡ Performance you can inspect

The benchmark hub publishes eight Criterion groups backed by nine benchmark binaries. They measure specific workloads and regressions — not universal speed or a ranking of frameworks. Read the methodology alongside the results.

🤝 Build Rullst with us

Try a starter or an example, report a reproducible bug, improve a tutorial or contribute a focused change with tests. Documentation, accessibility and integration feedback matter as much as new features.

Contributing · Issues · Discord · Community links · Our story and philosophy

MIT license · Report a vulnerability privately · Website privacy notice