If you've ever used Django, you know the feeling: one command, and you have an admin panel, an ORM, form validation, middleware, session handling — everything just works. Then you try Rust web development, and you're back to assembling pieces yourself.

That's why I built Runique: a batteries-included web framework for Rust, inspired by Django's philosophy, built on top of Axum and Tokio.

Why "Django for Rust"?

Existing Rust frameworks are excellent at what they do — Axum is fast and composable, Actix-Web is a performance beast — but they're low-level by design. You bring your own ORM, your own session store, your own CSRF protection, your own admin interface. For many projects, that's the right tradeoff.

Runique takes the opposite bet: convention over configuration, with a structured, opinionated setup that gets you from zero to a production-ready app fast, without sacrificing Rust's safety and performance.

The Builder: A Validated Construction Pipeline

The part I'm most proud of is the application builder. You declare your components with a fluent API — in any order — and then a single .build() call runs a fixed, validated construction pipeline at startup:

Validation → DB connection → Templates → Engine → Admin → Middleware → Static files

Here's what a typical app setup looks like:

let app = RuniqueAppBuilder::new(config)

    .routes(url::routes())

    .with_database_config(db_config)

    .with_mailer_from_env()

    .statics()

    .middleware(|m| m

        .with_session_memory_limit(5 * 1024 * 1024, 10 * 1024 * 1024)

        .with_session_cleanup_interval(5)

        .with_allowed_hosts(|h| h.enabled(true).host("example.com"))

        .with_csp(|c| c

            .policy(SecurityPolicy::strict())

            .with_header_security(true)

            .scripts(vec!["'self'", "'strict-dynamic'"]))

        .with_anti_bot())

    .with_admin(|a| a.routes(admins::routes("/admin")))

    .build()

    .await?;



app.run().await?;

The .build() call validates every component — including cross-dependencies — before constructing anything. If your SECRET_KEY is still the default insecure value in production, the build fails with a clear error and a fix suggestion, before a single request is served:

[Security] SECRET_KEY is using the default insecure value

  → Set SECRET_KEY to a random 32+ character string in your .env file

This is the Django check framework equivalent, but enforced at startup — not discovered in production.

Security Included by Default

Security in Runique isn't a plugin you add later. It's part of the construction pipeline itself:

• 
  CSP (Content Security Policy) — configurable profiles, per-request nonce, HTMX hash merging when the admin panel is enabled


• 
  CSRF protection — built into the middleware stack, with per-route exemptions


• 
  Host validation — allowed hosts checked before routing


• 
  Trusted proxies — explicit configuration, not implicit trust


• 
  Security headers on static files — X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options, Referrer-Policy applied automatically
  

// You don't wire ServeDir yourself — `.statics()` does it,

// already wrapping every static/media route with security headers:

.statics()

// → X-Content-Type-Options: nosniff

//   Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

//   X-Frame-Options: DENY

//   Referrer-Policy: strict-origin-when-cross-origin

//   + cache-control

The middleware stack uses numbered slots to guarantee application order — you can't accidentally apply CSRF before sessions, because the slots enforce the correct sequence.

What's Included

• 
  ORM (via SeaORM, optional feature flag)


• 
  Template engine (Tera, with custom filters and a URL registry for named routes)


• 
  Admin panel (auto-generated from your models, merged before the middleware stack so it always has session/auth context)


• 
  Form engine (typed structs with validation, v2 in progress)


• 
  Session handling (memory-first store with database fallback, built on tower-sessions, with periodic cleanup)


• 
  i18n (the FR/EN bilingual doc site is itself built with Runique)


• 
  Middleware system with ordered slots


• 
  Password reset (pluggable, routes registered automatically during build)


• 
  Debug error page — a styled page with collapsible sections and copy-to-clipboard for stack traces

One Concrete Example: Admin Merge Order

Here's a subtle design decision that illustrates Runique's philosophy. In Axum, .layer() only applies to routes present at call time. This means if you merge your admin router after applying middleware, the admin routes run without session, CSRF, or extension context — a silent, hard-to-debug failure.

Runique handles this in the builder:

// Step 4b: admin + password reset — merged BEFORE the middleware stack.

// `.layer()` in Axum only covers routes present at call time;

// merging after means admin routes run without Session/CSRF/Extensions.

let router = if self.admin.enabled {

    router.merge(admin_router)

} else {

    router

};



// Step 5: middleware applied AFTER, covering everything including admin

let (router, session_store) = middleware.apply_to_router(router, config, engine, tera);

You don't have to think about this. The pipeline handles it.

Current Status

Runique is at v2.1.x, MIT licensed, with bilingual documentation (EN/FR) at

Links & Resources