Roadster vs. Loco
Loco and Roadster serve similar purposes -- they both aim to reduce the amount of configuring, wiring, and other boilerplate code required to build a backend or full-stack web app in Rust. There are some notable differences, however, both in mission statement and the list of supported features. This section will give a summary of both the similarities and differences between Loco and Roadster.
Feature breakdown
Below is a detailed breakdown of the features built-in to Roadster and Loco. Note that because both frameworks are based on Axum and Tokio, there's not a lot technically preventing either framework from implementing features they're missing compared to the other. Features that Roadster would like to add in the near future are marked with '*'. Other missing features are not planned but we'd be open to adding if there was interest in them.
Last updated in July 2025.
| Feature | Roadster | Loco |
|---|---|---|
Separate cargo CLI to help with generating code and other tasks | ❌ | ✅ |
| Custom CLI commands | ✅ | ✅ |
| HTTP APIs via Axum | ✅ | ✅ |
| ↳ Default "ping" and "health" HTTP routes | ✅ | ✅ |
| ↳ Default routes can be disabled via config | ✅ | ❌ |
| ↳ Default middleware configured with sensible defaults | ✅ | ✅ |
| ↳ Middleware can be customized via config files | ✅ | ✅ |
| ↳ Middleware execution order can be customized via config files | ✅ | ❌ |
| OpenAPI support | ✅ | ✅ |
| ↳ built-in via Aide | ✅ | ❌ |
| ↳ 3rd party integration, e.g. Utoipa | ✅ | ✅ |
| ↳ OpenAPI docs explorer http route provided by default | ✅ | ❌ |
| GRPC API with tonic | ✅ | ❌ |
| Channels (websockets and/or http long-polling) | ❌ | ✅ |
| Support for arbitrary long-running services | ✅ | ❌ |
| Health checks | ✅ | ✅ |
| ↳ Run in "health" API route | ✅ | ✅ |
| ↳ Run on app startup | ✅ | ❌ |
| ↳ Run via CLI | ✅ | ❌ |
| ↳ Consumer can provide custom checks | ✅ | ❌ |
Custom app context / Axum state using Axum's FromRef | ✅ | ❌ |
| SQL DB | ✅ | ✅ |
| ↳ via Diesel | ✅ | ❌ |
| ↳ via SeaORM | ✅ | ✅ |
| ↳ SeaORM migrations for common DB schemas | ✅ (in lib) | ✅ (in starters) |
| Sample JWT Axum extractor | ✅ | ✅ |
| ↳ Multiple JWT standards supported | ✅ | ❌ |
| ✅ | ✅ | |
| ↳ via SMTP | ✅ | ✅ |
| ↳ via Sendgrid's Mail Send API | ✅ | ❌ |
| Storage abstraction | ❌* | ✅ |
| Cache abstraction | ❌* | ✅ |
| Background jobs | ✅ | ✅ |
| ↳ via Sidekiq | ✅ | ✅ |
| ↳ via Postgres | ✅ | ✅ |
| ↳ via in-process threading with Tokio | ❌ | ✅ |
| Periodic jobs | ✅ | ✅ |
| ↳ via Sidekiq | ✅ | ❌ |
| ↳ via Postgres | ✅ | ❌ |
| ↳ via custom scheduler | ❌ | ✅ |
| Configuration via config files | ✅ | ✅ |
| ↳ Toml | ✅ | ❌ |
| ↳ Yaml | ✅ | ✅ |
| Config files can be split into multiple files | ✅ | ❌ |
| Config values can be overridden via env vars | ✅ | ✅ |
| Config values can be fetch from async sources, such as secrets manager services | ✅ | ❌ |
| Tracing via the tracing crate | ✅ | ✅ |
| ↳ Built-in support for trace/metric exporting via OpenTelemetry | ✅ | ❌ |
| Testing support | ✅ | ✅ |
| ↳ Test app bootstrapping | ✅ | ✅ |
| ↳ insta snapshot utilities | ✅ | ❌ |
| ↳ Data seeding and cleanup | ❌* | ✅ (⚠️ makes tests non-parallelizable) |
| Mock DB support for tests | ✅ | ❌ |
| ↳ via Temporary Test DBs | ✅ | ✅ |
| ↳ via SeaORM's MockDatabase | ✅ | ❌ |
| ↳ via TestContainers | ✅ | ❌ |
| Allows following any design pattern | ✅ | ❌ (MVC only) |
| Lifecycle hooks | ✅ | ✅ |
| ↳ Customizable shutdown signal | ✅ | ❌ |
| HTML rendering | ✅ | ✅ |
| ↳ Built-in | ❌ | ✅ |
| ↳ via 3rd party integration, e.g. Leptos | ✅ | ⚠️ (Partial support) |
| Deployment config generation | ❌ | ✅ |
| Starter templates | ❌* | ✅ |