# Loco (loco-rs) review: Rails-style framework for Rust side-projects

> Loco is a Rust web framework modelled on Ruby on Rails, aimed at single developers shipping APIs and small SaaS apps. This review covers what the CLI generates, how to install it, and where the Rails analogy stops helping.

**loco-rs/loco** — 🚂 🦀 The one-person framework for Rust for side-projects and startups

- Repository: https://github.com/loco-rs/loco
- Website: https://loco.rs
- Stars: 9,358 · Forks: 436
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/loco-rs-loco

## What Loco solves, and who it is actually for

Rust has good HTTP libraries and almost no opinion about how an application should be arranged. Axum gives you routing and extractors and then stops. The README describes Loco as "Rust on Rails", and the package description on the repository calls it "the one-person framework for Rust for side-projects and startups". That second phrase is the more useful one. The target user is a single developer who wants a database-backed HTTP service with authentication, background work and file storage, and who does not want to assemble those from separate crates and make the architectural decisions himself.

The feature list in the README is the argument: convention over configuration, an ORM layer so you model entities instead of writing SQL, controllers built on Axum, views for templating, background jobs on a Redis-backed queue or on threads, a scheduler that the README contrasts with crontab, mailers that ride on the background worker, storage that can be in-memory, on disk, or on AWS S3, GCP and Azure, and a cache layer. Each of those is a decision Loco has already made. If you disagree with several of them, the framework is working against you rather than for you.

## Inside the generated app: Axum, SeaORM and a task runner

The architecture is a composition rather than an invention. Controllers are Axum, and the README says so directly, which means request handling, middleware and the response model follow Axum's rules and your existing Axum knowledge transfers. Persistence goes through SeaORM: the Cargo.toml declares a `with-db` feature that pulls in `sea-orm`, and the workspace comment notes that the minimum supported Rust version was raised to 1.94 to match Sea-ORM 2.0 and sqlx 0.9. The ORM is not optional decoration; it is the layer through which models, relationships and validation are expressed.

The second piece of the design is the task surface. `cargo loco` is a CLI subcommand, not a standalone binary you invoke separately. Starting the server, generating code and running tasks all go through it. That is the Rails `rails` command pattern transplanted: one entry point that understands the application's structure. Background jobs are implemented by writing a `perform` function against a `Worker` trait, and the README states that mailers reuse that same worker infrastructure. So a slow email send and a slow report generation share one execution path and one set of operational concerns.

Feature flags carry the module boundaries. The default set is `auth`, `cli`, `with-db`, `cache_inmem` and `worker`. A comment in the manifest explains that the `auth` feature selects jsonwebtoken's pure-Rust `rust_crypto` backend so that enabling `auth` alone still builds without a C toolchain. That is a deliberate choice in favour of easy onboarding over linking against a system crypto library.

## Installing Loco and generating a first app

Installation is two cargo installs. The README marks the second as conditional, needed only when the application talks to a database.

```bash
cargo install loco
cargo install sea-orm-cli # Only when DB is needed
```

With the CLI on your path, `loco new` runs an interactive generator. The README's transcript shows the prompts and the answers used in its example: an app name, a project shape ("Saas App with client side rendering"), a database provider (Sqlite) and a background worker type ("Async (in-process tokio async tasks)").

```bash
loco new
```

After the prompts, the generator prints the directory it created and, for the client-side rendering choice, a note that the frontend lives in `frontend/` and must be built with npm before it will serve anything. That step is easy to miss when you pick the SaaS template.

```bash
cd frontend/
npm install && npm run build
```

Back in the application directory, the server is started through the cargo subcommand. The README shows the ASCII banner and the line `listening on port 5150`, so 5150 is the port to expect on a default generated app.

```bash
cargo loco start
```

If you see the banner and that port line, the generator, the configuration and the database connection all resolved. If the process exits before the banner, the first place to look is the generated configuration rather than your own code, because nothing of yours is running yet.

## Where Loco is the wrong tool

The framework's value comes from the decisions it makes on your behalf, and that is also its main cost. If you are building a service whose interesting part is a non-standard persistence model, you are fighting SeaORM rather than using it, and the ORM integration that makes Loco attractive for a CRUD backend becomes overhead. The same applies to teams that already have a working Axum service: adopting Loco means adopting its project layout, its task runner and its configuration conventions, which is closer to a rewrite than a library upgrade.

The toolchain floor is a concrete constraint. The workspace manifest sets `rust-version = "1.94"`, with a comment tying that to Sea-ORM 2.0's own MSRV and to edition 2024 requiring at least 1.85. A team on an older pinned compiler cannot build it at all, and the fix is upgrading the toolchain, not configuring around it.

The background job story has a deployment dependency. The README lists a Redis-backed queue as one option and threads as another, so the choice is real, but a Redis-backed queue means Redis is part of your production footprint. The README does not describe what happens to in-flight jobs on shutdown or how retries are handled, and the repository's SECURITY.md and AGENTS.md files were not part of the material reviewed here. Treat job durability as something you verify in your own deployment rather than something the front page answers.

Finally, the documentation site is where the depth lives. The README repeatedly points to loco.rs for guides and API references, and the repository excludes `website/` from the published crate. What ships on crates.io is the library, not the explanation.

## Loco against plain Axum, and what the Rails comparison costs

The honest alternative is Axum alone, or Axum plus SeaORM wired by hand. The difference is not capability. Axum handles HTTP at least as directly, and you can add SeaORM, a job runner and a cache yourself. The difference is who makes the decisions and when. With plain Axum you decide the module layout, the migration strategy, the error type, the configuration format and the job runner before you write the first endpoint. With Loco those exist on the first `loco new`, and you accept them as given.

That trade is worth it exactly when the application is conventional. Loco's own feature list is a list of conventional things: authentication, an ORM, background jobs, mailers, storage, cache. If your application is mostly those, the framework removes weeks of assembly. If your application is mostly something else, the framework adds a layer you will spend time working around.

The Rails comparison is useful for predicting behaviour and misleading as a promise. The README says Loco is "strongly inspired by Rails" and that you do not need to know Rails to use it. What carries over is the shape: one CLI, generators, convention over configuration. What does not carry over is Rails' ecosystem depth. Loco is one crate with a documentation site and a small set of example applications in the repository (`examples/demo/` and `examples/reference_spa/`), not a twenty-year accumulation of gems. Budget for reading source when a behaviour is not documented.

## Maintenance, licensing and the upgrade question

The repository is not archived, and the last push was on 2026-09-16, days before this was written. The release history is recent and dense: v1.0.0 landed on 2026-07-29 with the title "Loco is stable", v1.0.1 on 2026-07-31, and v1.1.0 on 2026-08-16. A 1.0 line reached in mid-2026 means the API has been declared stable recently rather than for years, so expect the 1.x series to keep moving.

Licensing is Apache-2.0, declared both in the repository metadata and in the workspace manifest's `license` field. That is a permissive licence with an explicit patent grant, and it is the same licence used by much of the Rust ecosystem, so combining Loco with other Apache-2.0 or MIT crates is unremarkable. This is a description of what the files say, not legal advice; if your organisation has licence policy, run the dependency tree through it.

The upgrade cost is concentrated in the toolchain and the ORM. Because the MSRV tracks Sea-ORM, a Sea-ORM major release can force a compiler upgrade on you, which is exactly what the 1.94 floor records. The Cargo.toml also sets a workspace-wide `edition = "2024"`, so the whole workspace moves together. Before upgrading Loco, check the changelog in the repository and confirm your toolchain meets the new floor; the manifest comment shows the maintainers document these raises at the point of change.

## Conclusion

Adopt Loco if you are one developer building an API or small SaaS backend in Rust and you want the CLI to decide project layout, ORM wiring and background jobs for you. Do not adopt it if you need a long-lived, narrowly scoped HTTP layer that you control piece by piece, or if you are pinned to a Rust toolchain below the 1.94 floor the workspace manifest declares. Before committing, run loco new, start the generated app, and read the generated configuration to see which of database, cache, worker and auth features you are actually pulling in.

## FAQ

### How do I install Loco?

Run cargo install loco, and add cargo install sea-orm-cli when your application needs a database. The README marks the second install as conditional on database use.

### What port does a Loco app listen on by default?

The README's startup transcript shows the banner followed by the line listening on port 5150, so that is the port to expect from a freshly generated app started with cargo loco start.

### Is Loco the Rust equivalent of Django or Rails?

Loco is explicitly modelled on Rails rather than Django: the README describes it as "Rust on Rails" and says it is strongly inspired by Rails, with convention over configuration, generators and a single CLI. It does not claim Django compatibility.

### What Rust version does Loco require?

The workspace manifest sets rust-version = "1.94", with a comment tying that floor to Sea-ORM 2.0's own MSRV and noting that edition 2024 needs at least 1.85. Older pinned toolchains cannot build it.

### What licence does Loco use?

Apache-2.0, declared in the repository metadata and in the license field of the workspace manifest.

## Sources

- [License: Apache-2.0](https://github.com/loco-rs/loco/blob/master/LICENSE)
- [loco-rs/loco on GitHub](https://github.com/loco-rs/loco)
- [Project website](https://loco.rs)
- [README](https://github.com/loco-rs/loco/blob/master/README.md)
- [Releases](https://github.com/loco-rs/loco/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/loco-rs-loco