A LITTLE LESS GLUE. A LOT MORE POSSIBILITY.
One tree. Every screen. Your cloud.
Write your interface once, as one tree of components, and watch it become real native widgets on every screen — with the backend and the deployment in the same Rust codebase.Open source. Real native widgets. No mandatory cloud. 01 / ONE TREE, EVERY SCREEN
Same tree. Different worlds.
Scroll, and watch one component become each platform's own widgets. The code never changes; the renderer does. Web · Leptos and the DOMView, Heading, Text, and Button become <div>, <h3>, <span>, <button>.
iOS · UIKitView, Heading, Text, and Button become UIView, UILabel, UILabel, UIButton.
Android · Android viewsView, Heading, Text, and Button become FrameLayout, TextView, TextView, Button.
macOS · AppKitView, Heading, Text, and Button become NSView, NSTextField, NSTextField, NSButton.
Windows · Win32View, Heading, Text, and Button become child window, STATIC, STATIC, BUTTON.
Linux · GTK 4View, Heading, Text, and Button become GtkWidget, GtkLabel, GtkLabel, GtkButton.
Terminal · terminal cellsView, Heading, Text, and Button become a box of cells, a line of text, a line of text, [ One more idea ].
HarmonyOS · ArkUI, experimentalView, Heading, Text, and Button become Stack, Text, Text, Button.
02 / NOW TRY THE REAL ONE
One component. No illustration.
The card on the right is the real thing: leptoskit's web renderer running the code on the left. Press its button and three elements answer together. ONE RUST COMPONENTlet count = RwSignal::new(0);
let shipped = count.get();
View()
.child(Heading(3, "Little wins"))
.child(
Text(format!("{shipped} ideas shipped"))
.motion(
Motion::enter(Pose::new().scale(1.35))
.spring(Spring::BOUNCY)
.key(shipped),
),
)
.child(
Button("One more idea")
.on_press(move || count.update(|n| *n += 1)),
)Learn the component model ↗Learn about motion ↗
A REAL LEPTOSKIT COMPONENT · TRY IT This interactive browser example changes local state. Native builds use the same builders with their platform's widgets.
Little wins
0 ideas shipped
Big things start with one small, well-made thing. 03 / THE WHOLE JOURNEY
From a blank file to a living app.
A toolkit for the parts you want to build — and the parts you shouldn't have to assemble again. 01
Build something real.
Components, typed RPC, database schemas, and sign-in. Rust checks how the pieces fit.See how it works ↗ 02
Give it a place to live.
Describe compute, storage, live services, and backups in TOML. Review the OpenTofu plan before applying it.See how it works ↗ 03
Keep making it better.
Roll out container releases and signed native code pushes. Keep migration history and a route back.See how it works ↗ 04 / GOOD PIECES, ALREADY CONNECTED
Bring the idea. The foundations are here.
Explore the toolkit, choose the features your app needs, and leave the rest out.Data with a point of view.
Typed schemas, migrations, row policies, and client-safe projections. Give every caller exactly the view they need.Read the guide ↗A little more alive.
Typed requests, live queries, and relay-backed services that can stay connected. Build collaboration around real application state.Read the guide ↗Native means native.
System widgets, runtime plugins, secure storage, and signed updates. A Wasm interface inside an installed native host.Read the guide ↗Identity, built in.
Sign-in, passkeys, sessions, and an identity provider. Keep authorization close to the data and operations it protects.Read the guide ↗Make it move like yours.
Springs, entrances, and scroll-driven choreography as typed builders, plus Rive, vector graphics, themes, and localization.Read the guide ↗Room to move with confidence.
Accessible controls, component tests, device journeys, and agent-readable analytics. See what the app is actually doing.Read the guide ↗ 05 / YOUR NEXT PLACE TO LAUNCH
Your app. Your choice of cloud.
Deploy from your own machine or pipeline with the CLI. The engine plans, applies, and rolls back infrastructure described in leptoskit.toml. Manage provider credentials in your own environment. BRING YOUR OWN
The CLI plans and applies real infrastructure.
Describe compute, storage, live services, and backups in TOML. Review the OpenTofu plan before anything runs, and keep the deployment history in your own hands.Read about deploying ↗ RELEASE ON YOUR TERMS
Ship, then keep building.
Publish container releases and signed native code pushes from your own workflow. Keep migration history and a route back when a release needs to be reversed.Explore code push ↗ WHAT WILL YOU MAKE?