Leptos Full-Stack Rust (SSR + Hydration on Axum)
Full-stack Rust web app rules: Leptos 0.8 SSR with hydration, server functions on Axum, sqlx + PostgreSQL, cargo-leptos and Tailwind, written for AI agents.
- Formats
- 4 files
- AGENTS.md
- 50 lines
- CLAUDE.md
- 17 lines
- Languages
- Rust
- Updated
- Oct 2026
- Used by
- 4 projects
Writes .claude/skills/rust-leptos-fullstack/SKILL.md
$ curl -s --create-dirs -o .claude/skills/rust-leptos-fullstack/SKILL.md https://stackitfast.com/rules/rust-leptos-fullstack/SKILL.mdRule files
Works with Claude Code · Cursor · Windsurf · AGY
Architecture notes
Architecture Overview
One language end to end. Leptos renders components on the server for fast first paint and SEO, hydrates them in the browser as WebAssembly, and calls typed #[server] functions instead of a hand-written REST API. Axum hosts it, sqlx talks to PostgreSQL, and cargo-leptos builds both halves.
Why it suits AI coding agents
- The client-server contract is a Rust function signature. Change a server function’s return type and every call site in the UI fails to compile, so an agent cannot ship a frontend and backend that disagree.
- Feature gates make boundaries explicit. Database code behind
ssrcannot leak into the browser bundle without a compile error. - Progressive enhancement by default.
ActionFormposts work before the WASM loads, which keeps end-to-end tests simple.
Trade-offs
Two compile targets mean slower loops than the Axum + htmx stack, WASM bundles add weight, and the component ecosystem is young. Start with htmx unless the UI genuinely needs client-side state. Background: Building web apps in Rust in 2026.
Frequently asked questions
Is Leptos production-ready in 2026?
Leptos 0.8 is stable and actively maintained, with SSR, hydration, server functions and an Axum integration. Its ecosystem is much smaller than React's, so expect to write more components yourself; none of the open-source Rust apps in the STACK IT FAST directory ships a Leptos UI yet.
Leptos or Dioxus?
Pick Leptos for web apps that need server-side rendering and SEO, because SSR, hydration and server functions are its core design. Pick Dioxus when the same Rust UI code has to run on desktop and mobile as well as the web.
Why does the agent need to check two targets?
A Leptos app compiles twice: once for the server with the ssr feature and once to WebAssembly with the hydrate feature. Code that compiles for the server can still break the WASM build (for example by importing sqlx), so cargo check must pass for both before a change is done.
Do I still need a separate API?
Not for your own UI. Server functions are typed RPC endpoints generated from Rust functions, so the client calls them like async functions. Add a separate Axum JSON API only when third parties or mobile apps need a stable public contract.
Used in production
Explore all stacksRustFS
1RustFS splits a MinIO-style object store into dozens of single-purpose Rust crates behind one binary, keeps extra protocols behind cargo features, and moves inter-node traffic to gRPC, so storage, healing and IAM evolve separately.
Axum
Axum skips a custom middleware system and treats every route and layer as a Tower service, so it inherits timeouts, tracing, compression and auth from tower-http and shares middleware with Hyper and tonic code.
Leptos
Leptos separates its reactive graph, renderer and server-function RPC into independent crates and keeps the core server-agnostic, so the same components run as SSR HTML or WebAssembly, and Axum or Actix Web plug in through thin integration crates.
Dioxus
Dioxus keeps one virtual DOM and component model and swaps renderers per platform (WebAssembly, WebView, SSR, LiveView, native), while its own dx CLI handles hot-patching, asset bundling and packaging for every target.