DocsThe ecosystem
Official packages
Rahti is published on crates.io as ten crates on four independent release lines: the framework itself, an optional UI component installer, an optional icon package, and optional native packaging. This page says which line each crate is on, whether you install it or depend on it, and what happens if you never touch it at all.
Four release lines
Everything published under the framework's name is here. They are grouped by how they are versioned, because that is the thing you have to know before upgrading anything: crates on the same line move together, and crates on different lines do not.
The framework
Five crates, one version number, released in lockstep. html! expands to paths inside rahti, and rahti-build writes code that calls functions in it — a project that mixed versions would fail to compile with an error naming neither crate. Releasing them together is what makes that mismatch unreachable.
| Crate | How you get it | What it is |
|---|---|---|
| rahti | cargo add rahti | The server runtime: Html, layouts, errors, RPC, streaming, uploads and auth — plus optional ws sockets and mcp Streamable HTTP. |
| rahti-macros | nothing — re-exported | html!, #[component], #[rpc], #[socket]. Never named in a manifest; rahti carries it. |
| rahti-build | a build dependency | The build step: scans src/app/ and src/components/, writes the router and the module wiring, compiles CSS. |
| cargo-rahti | cargo install cargo-rahti | The scaffolder: cargo rahti new and cargo rahti upgrade. The one piece every project installs globally. |
| rahti-mcp | cargo install rahti-mcp for local stdio; wired by --mcp for HTTP | Read-only project inspection, public service context, and conventions over stdio or secured Streamable HTTP. See MCP server. |
# The scaffolder. The only thing a Rahti project needs installed globally.
cargo install cargo-rahti
# Optional, on the same release line: read-only project context for an
# Local MCP client. The HTTP library is an optional application feature.
cargo install rahti-mcp# What `cargo rahti new` writes. `rahti-macros` is never named here:
# `rahti` re-exports every macro, so one pin covers both.
[dependencies]
rahti = "0.0.24"
[build-dependencies]
rahti-build = "0.0.24"rahti-mcp has two deliberately separate entry points. The default feature builds the standalone stdio executable. Rahti's optional mcp feature links only the HTTP library into an opted-in application. A project that never asks for MCP resolves neither the dependency nor its routes.
UI components
One crate, and the only line here with no runtime beside the tool. A rahti-ui component is not imported from a crate: it is fetched once and written into src/components/rahti_ui/ as source the application owns, and the file is the component. So there is nothing to release in lockstep with, and no version an installed component depends on.
| Crate | How you get it | What it is |
|---|---|---|
| cargo-rahti-ui | cargo install cargo-rahti-ui | The installer: cargo rahti-ui add, update, remove, list, theme. shadcn/ui ported to Rahti — 62 components, and the shadcn theme they are written against. |
# One tool, and nothing to add to Cargo.toml: a component is source,
# written into src/components/rahti_ui/ and owned by the application.
cargo install cargo-rahti-ui
cargo rahti-ui add button card dialogAn add brings the whole graph — the components a component imports, and the icons it imports, which it hands to cargo-rahti-icons rather than fetching itself. UI components has the props, the component boundary rule, the theme and every command.
Icons
Two crates on their own version line, released together for the same reason the framework's five are: a file written by one version of the installer is read by the runtime of the same version. Optional — a project that never adds an icon has neither.
| Crate | How you get it | What it is |
|---|---|---|
| rahti-icons | cargo add rahti-icons | The runtime. Attribute merging behind the icon! macro, which is what a generated icon file expands through. |
| cargo-rahti-icons | cargo install cargo-rahti-icons | The installer: cargo rahti-icons add, update, remove, list. |
# Two halves of one release line: the runtime is a dependency, the
# installer is a tool.
cargo add rahti-icons
cargo install cargo-rahti-icons
cargo rahti-icons add userAn icon is fetched once and written into src/components/rahti_icons/, where the Rahti build already looks — so what compiles into the binary is the icons the application actually uses, not a catalog of 1,600. Icons has the props, the merge order and every command, and the catalog those 1,600 names come from is ppicons.tsnc.tech.
Native packaging
Two more crates on a fourth line, and the most optional thing here: nothing in them is compiled, downloaded or resolved by a project that has not run cargo rahti native init.
| Crate | How you get it | What it is |
|---|---|---|
| rahti-native | a dependency of native/ | The platform-neutral runtime: packaged paths, the loopback-only embedded server, the per-installation session key, the launch gate, the security headers, the native bridge. No Tauri dependency of its own. |
| cargo-rahti-native | cargo install cargo-rahti-native | The CLI: init, doctor, dev, build. Generates the Tauri shell and delegates the packaging to Tauri's own CLI. |
# The packaging tool, and the Tauri CLI it delegates to. Neither is
# compiled into your application.
cargo install cargo-rahti-native
cargo install tauri-cli --version "^2" --locked
cargo rahti-native init --identifier com.example.myapp --windowsYou never write rahti-native into a manifest yourself — init puts it in the shell it generates under native/, which is excluded from your workspace. Native packaging has the paths, the database policy, the session key and the security model.
The whole list
Ten crates, four lines. Version numbers move; what does not move is which line a crate belongs to and how it reaches your project.
| Crate | Line | Reaches you as |
|---|---|---|
| rahti | framework | A dependency |
| rahti-macros | framework | Re-exported by rahti |
| rahti-build | framework | A build dependency |
| cargo-rahti | framework | An installed tool |
| rahti-mcp | framework | An installed local tool or optional HTTP dependency |
| cargo-rahti-ui | ui | An installed tool |
| rahti-icons | icons | A dependency |
| cargo-rahti-icons | icons | An installed tool |
| rahti-native | native | A dependency of the generated native/ shell |
| cargo-rahti-native | native | An installed tool |
The header badge on this site reports rahti's newest stable release, asked of crates.io rather than kept as a number in a file — so what it shows is what cargo add rahti would resolve to right now. The registry is the same place to check the rest: all ten are published from one crates.io account, and each crate's page names its repository.
Upgrading
One command moves the framework line. It refreshes the scaffold files whose recorded hashes show you never edited them, and moves the rahti and rahti-build pins in Cargo.toml to the version of the tool that is running — so upgrading the framework starts by upgrading cargo-rahti itself.
# The framework's crates move together, so one command moves the pins.
cargo rahti upgrade
# The optional lines are separate installs on their own schedule.
cargo install cargo-rahti-icons # re-install to move the icon line
cargo rahti-icons update # re-fetch what this project installed
cargo install cargo-rahti-ui # re-install to move the UI line
cargo rahti-ui update # re-fetch components, keeping your editsThe UI, icon and native lines are separate installs, upgraded when you choose to. None of them is read by cargo rahti upgrade, and none of them holds the framework back. The UI line is the one with a second half to the upgrade: re-installing the tool moves what it fetches, and cargo rahti-ui update is what brings the new version of a component into your repository — leaving alone any file you have edited.
What is not on crates.io
- The demonstration application at the framework workspace root, which is marked
publish = falseso a straycargo publishcannot put it on the registry.
Editor support
Not a crate, and worth having: a VS Code extension that injects a grammar into Rust files so an html! block stops rendering as undifferentiated Rust tokens. Markup, component tags, @{rust} and {javascript} each get their own colour — which is exactly the distinction the framework asks you to keep straight.
Search Rahti in the extensions panel, or install the Rahti extension from the marketplace. It also flags the runtime-managed attributes you are not supposed to write — pp-component, data-pp-* — and the pp-* names that do not exist.