About RustClamp
RustClamp is a composable application framework that brings independent Rust components together without taking Rust away from the developer.
A clamp does not replace the pieces. It holds them together.
Names
| RustClamp | The project and brand. |
| Clamp | The framework: a Clamp application, a Clamp module, the Clamp kernel. |
| rustclamp.com | This site, home of the documentation. |
RustClamp is a framework built for Rust. It is not an official Rust project and is not endorsed by the Rust project.
Why it exists
Rust has excellent libraries for almost every job — Tokio, Axum, SQLx, Serde, Tracing. What it lacks is a shared application architecture across the kinds of software people build with them: CLIs, APIs, workers, schedulers, services, simulations, devices. Each project reinvents its own structure. Clamp's job is architectural coherence: one vocabulary from a single closure to a multi-process platform.
Principles
- Composition over ownership. Clamp connects components rather than replacing them.
- Explicit over magical. Convenience must stay explainable.
- Modular over monolithic. Applications select what they need.
- Rust-native over framework-native. Ownership, concurrency and types stay visible.
- Progressive control. Use, configure, extend, replace, own.
- Zero-cost absence. Unused architecture should disappear.
- One architecture, many scales. From pico to platform.
AI-native, not AI-dependent
The architecture is meant to be machine-readable: modules, capabilities, requirements, providers, contributions and processes can already be inspected from a frozen plan, and humans and tools should read the same truth. A Clamp application will never need an AI provider, key or network call to build, test or run. AI integrations, when they come, will be ordinary modules with no privileged place in the architecture. Planned
How the design evolved
Clamp began as a series of architecture specifications before any code was written. Each revision answered one question:
| Revision | Question | Outcome |
|---|---|---|
| 1.0 | What is an application? | The application as root concept; modules, capabilities, adapters; explicit anti-goals. |
| 1.1 | What does application code do? | Operations as first-class units of work. |
| 1.2 | Where does work execute? | Application versus process; explicit process boundaries. |
| 1.3 | How does execution communicate? | Outcomes and presenters — HTTP is not JSON. |
| Bootstrap | How is a kernel assembled? | Presets, additive and subtractive composition, progressive control. |
| 1.4 | How does an application live? | The lifecycle model; foundations and profiles. |
| Corrections | What did stress-testing break? | Provider became a role, kernel became composed, core vocabulary cut to a handful of terms. |
| 1.5 | How is an application assembled? | Requires/Provides/Contributes, capability versus contribution, reachability, freeze, layered crates. |
Version 1.5 was play-tested on paper against web, CLI, game and embedded scenarios before the prototypes started. The prototypes now test it in code, one measured phase at a time.
Status and license
Early prototype. Source is public at github.com/rustclamp. A license has not been chosen yet, and packages will not be published until it is. See the Roadmap.