Quickstart · Start building · Rullst Academy · Live examples · Documentation · Discord

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.

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"}

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

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

🌐 Showcase — SSR, LiveView, Wasm, ORM, billing, security and AI demos · Open ↗	🎓 LMS — course catalog and learning platform · Open ↗
💼 Portfolio — projects, experience, Nexus and Studio · Open ↗	🛒 SaaS in production — real purchases with Stripe · Open ↗

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

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.

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.

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.

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 ↗

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.

_{The Nexus security radar (recorded screenshot).}

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

🛡️ Open the verification dashboard (37 workflows)

Badges are pinned to the main branch; they report the latest matching run, not a certification or deployment guarantee.

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 ≥90% with zero tolerance. For reference, the LLVM run on the v12.0.0 release commit eb11f892 measured 90.3220% (79,813/88,365 lines) before Codecov upload.
Codecov — framework libraries		Runtime libraries are enforced separately at ≥90%. CLI and proc-macro components stay separately visible; Coverage CI uploads their real LCOV evidence with OIDC.
Cargo Audit		RustSec advisory scan with only governed, expiring exceptions; the daily run also audits the v12 locks.
Security exception governance		Cross-checks scanner allowlists against the owner/expiry ledger, then independently reruns Cargo Audit.
Cargo Deny		Advisory, license, ban, and source policy.
CodeQL SAST		Rust semantic analysis after an all-target/all-feature build, plus JavaScript/TypeScript analysis.
OpenSSF Scorecard		The badge renders the score from the official public Scorecard JSON report; the pinned Scorecard workflow publishes OIDC-authenticated results on each main push and weekly. A score is evidence, not a security certification. Evidence and improvements.
Cargo Machete		Unused direct dependency detection.
SemVer checks		Supported library APIs are compared with exact latest non-yanked registry baselines; never-published packages and unsupported proc-macro/binary surfaces are reported explicitly.
Zero-panics policy		Denies panic-family operations in published production targets and generated runtime templates.
Unsafe boundary		Denies new production unsafe code outside the reviewed OS/FFI allowlist.
Secret scanning		Verified-secret scan across the configured Git history range.
Spellcheck		Repository-wide typo detection.
Crate architecture policy		Compares the real publishable-crate dependency graph with a versioned, reviewed repository policy.
WebAssembly matrix		Compiles Core, the public facade and macros for browser Wasm and WASI Preview 1.
Bare-metal no_std matrix		Builds IoT helpers for Cortex-M and RISC-V targets; this is compile evidence, not hardware testing.
IoT integration		Host tests, signed OTA invariants, and a Cortex-M build.
IoT crypto containment		Path-aware signed OTA, Vault, advisory, and simulator-boundary checks; no PQC/HSM certification claim.
PR security evidence		Pull-request-only bounded IDOR/RBAC heuristics and CycloneDX SBOM artifact. It intentionally has no continuous main status.
PR mutation diff		Pull-request-only cargo-mutants run over the changed Rust lines; a missed mutant fails it. It intentionally has no continuous main status.

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.
v13 Verus pilot	Optional production-linked age-policy proof with pinned tooling and three negative controls. Hosted registration/acceptance remains pending; no framework-wide correctness claim.
GitHub Pages	Deploys development documentation from main; it is not a code-quality gate.
Release and provenance	Exact version tags only: exact-SHA admission of the full CI matrix, package-all, evidence bundle, checksums, GitHub build-provenance attestation, changelog-derived release notes, and ordered crates.io publication. This does not claim a project-wide SLSA level or independent certification.

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

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

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.

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 (build times).
• Progressive web apps: cargo rullst make:pwa (manifest, service worker, offline page), a Google Play Trusted Web Activity configuration and a Microsoft Store guide (guide).
• Studio production monitoring: a read-only monitoring endpoint, and a standalone Studio for remote projects with a project switcher, history and alerts (guide).
• OAuth login: a login challenge store and cargo rullst make:oauth for Google, GitHub, Microsoft and Apple.
• i18n: translations, CLDR plural rules and number, currency and date formatting.
• Typed transactions: Orm::transaction returns the error of its closure.
• Minimal default features: rullst and rullst-orm compile no database code until you select a profile.
• Views and data: html! returns Markup and has @if, @for and @match; dirty-tracking save(); Schema constraints and date/time columns; revocable sessions; multipart uploads.
• Assisted upgrades: cargo rullst upgrade reports v12 → v13 source findings at file:line and applies per-release rules.
• Opt-in candidates: email login, scoped API tokens, active-session management with remote logout, private S3/R2 storage with resumable uploads, durable outgoing webhooks and recurring publications, Redis Streams messaging, distributed tracing and a recoverable Live UI are in the 13.0 prereleases behind their own features; each guide states what has been validated and what is still open.

v13 roadmap · Compatibility policy · v12 release record

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.

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

⭐ If Rullst sparks your curiosity, a star helps more developers discover it.

MIT license · Report a vulnerability privately · Website privacy notice