For AI agents: the complete documentation index is available at https://a3s-lab.github.io/Boot/en/llms.txt, the full documentation bundle is available at https://a3s-lab.github.io/Boot/en/llms-full.txt, and this page is available as Markdown at https://a3s-lab.github.io/Boot/en/index.md.
A3S Boot
  • English
  • v0.2.0

      • Modular applications.Rust-level control.

      Compose modules, providers, controllers, and protocol pipelines without hiding adapters or runtime boundaries.

      Get startedRead the application model
      Registered entry point
      #[controller("/users")]
impl UserController {
  #[get("/{id}")]
  async fn find(#[param("id")] id: Uuid) {}
}
      Execution stages
      1. 01Middleware
      2. 02Guard
      3. 03Interceptor
      4. 04Pipe
      5. 05Handler

      Start with defaults. Add capabilities explicitly.

      Defaults include Axum, attribute macros, and graceful shutdown. Every other module is feature-gated.

      a3s-boot = "0.2.0"

      Familiar module boundaries. Explicit Rust ownership.

      Boot borrows NestJS organization without hiding the dependency graph, protocol adapter, or error types.

      ModuleRef

      Modules and dependency injection

      Visibility, imports, exports, scopes, async factories, and lifecycle live in a typed container.

      #[controller]

      Controllers and macros

      Attributes generate registration for ordinary Rust types while explicit builders remain available.

      ExecutionContext

      Deterministic request pipeline

      Middleware, guards, interceptors, pipes, validation, and filters have a fixed order.

      MessageTransport

      Multi-protocol execution

      HTTP, WebSocket, and message transports share scope, validation, and enhancer semantics.

      Four stages from module declaration to a serving app.

      Every stage remains testable, inspectable, and replaceable.

      1. 01

        Declare boundaries

        Modules list providers, controllers, gateways, and imports

      2. 02

        Compile the graph

        Validate tokens, visibility, scopes, and route conflicts

      3. 03

        Resolve instances

        Construct singleton, request, or transient dependencies

      4. 04

        Attach adapters

        Axum or a message transport takes the network boundary

      One application core. Multiple entry points.

      Application and technique modules

      Compose config, logging, cache, database, sessions, security, CQRS, events, scheduling, health, and files on demand.

      • Provider-first design
      • Global and local enhancers
      • Testing module overrides

      Protocols and background work

      HTTP, WebSocket, TCP, Redis, NATS, MQTT, RabbitMQ, Kafka, gRPC, queues, and iLink use explicit contracts.

      • Replaceable adapters
      • Protocol-specific contexts
      • Delivery semantics remain visible
      Browse every capability

      The framework supplies mechanisms. Applications choose deployment policy.

      Read production boundaries
      • Axum is the default HTTP adapter, while the application core remains Axum-independent.
      • Optional features do not pull service dependencies into disabled builds.
      • Queue delivery is at least once, so business processors must be idempotent.
      • Distributed rate limits, broker durability, and secret storage are deployment choices.

      Start with one module and one route.

      Run the default Axum app, then enable modules and protocols at business boundaries.

      Get started