Rustelo

About Rustelo

A full-stack Rust web framework built on Leptos and Axum, where a site's routes, content types and languages are configuration and the framework's internals are never forked.

What it is

Rustelo is a Rust web framework for sites and applications whose shape is declared rather than coded. Routes, menus, content kinds, themes and languages live in Nickel configuration; the framework generates the Rust that serves them at build time.

It is organised in three layers: your application, a stable ports API (rustelo_web, rustelo_auth, rustelo_content), and the foundation that implements configuration, i18n, RBAC, the Axum server, the Leptos client, components and page generation.

Every route renders in one of two profiles — HTMX-SSR, server-rendered HTML with no WebAssembly, or Leptos hydration — chosen in configuration, per site or per route.

What it provides

  • ▸ Language-agnostic routing: per-language routes in configuration, languages discovered from configuration and content.
  • ▸ Markdown content with structured front matter, content kinds and categories, rendered with syntax highlighting.
  • ▸ Multilingual UI through Fluent FTL files, embedded at compile time.
  • ▸ Authentication and authorization: JWT, OAuth2, two-factor TOTP, Argon2 password hashing and RBAC policies.
  • ▸ PostgreSQL and SQLite through SQLx, with separate migrations per database.
  • ▸ Cargo feature composition — auth, content-db, content-static, email, tls, metrics, crypto — so a build carries only what it uses.

Core concepts

Six building blocks, each declared or selected in configuration.

Three layers

Your application on top, framework ports in the middle, the foundation underneath. Implementations depend on the ports, never on foundation internals.

Build-time generation

Nickel configuration is read by build.rs and turned into routes, pages, menus and the FTL registry in OUT_DIR, included with include!(). The generated code is never edited by hand.

Routing

A custom routing system driven by per-language route configuration. URL patterns come from configuration, not from code.

Rendering profiles

A typed RenderingProfile axis: HtmxSsr or LeptosHydration, resolved route over workspace over default, so one binary can serve both.

Layered overrides

Local over Feature over Template over Framework: the first layer that provides a value wins, and a site customises in its local layer instead of editing the framework.

Plugins

ResourceContributor and PageContributor traits, registered at startup and compiled in — extension with no runtime plugin loader.

What never changes

Four commitments hold across the whole framework. They are recorded as invariants and architectural decisions, not as guidelines.

Configuration-driven

Everything is configurable and nothing is hardcoded: no literals in code for routes, paths or content types.

Language-agnostic

No language is built in. The language set is discovered from configuration and content, and URL patterns come from per-language route files.

No framework forks

Implementations extend through overrides and plugins and never modify framework internals, so the framework stays safe to update.

Generated at build time

The route table, pages and menus a binary is built with are validated when it compiles and inlined into it. A site adds its own routes on top at startup, never by editing generated code.

See the whole framework

The layers, the crates, the Cargo features and the technology underneath, in one place.