Cot: a Django-shaped web framework for Rust built on axum

The pitch: familiar if you know Django

Cot describes itself as an easy to use, modern and fast web framework for Rust, and the design brief is stated in the second sentence. It has been designed to be familiar if you have ever used Django, and easy to learn if you have not. It is a batteries included framework built on top of axum.

That framing is the whole positioning. Rust web development has historically meant choosing a routing library and assembling the rest yourself, and Cot is the position that the parts Django gives you, an ORM, an admin, templates, migrations, a security posture, are worth having as one opinionated package rather than a dozen decisions.

The five feature headings are the easy to use API, ORM integration, type safety, an admin panel and secure by default. Two of those are worth reading twice. The ORM integration says Rust types are the source of truth, and that the ORM translates them to and from the database while creating the migrations automatically. The type safe entry says that not only views but also the ORM, the admin panel and even the templates use the type system to catch errors as early as possible.

The project is independent and open source, with a homepage at cot.rs, a guide served from the same site, API docs on docs.rs, and sponsorship through GitHub Sponsors and Open Collective. The licence is dual, Apache License 2.0 or MIT at your option, and the last push to the repository was on 2026-10-19.

Getting started: cot-cli, cot new, cargo run

The entry point is a command line tool, and the three commands are short enough to state in full.

You need Rust installed, and the README points at the official Rust website instructions if you do not have it. Then you install the CLI:

cargo install cot-cli

From there a project is created with the new command, which creates a directory of that name:

cot new my_project

And the development server is started with cargo run from inside the project directory.

cargo run

The CLI is also packaged by operating system package managers, which the README says can be found through the repology packaging status badge. The advice attached to that badge is worth repeating because it is the sort of thing people get wrong. Most of those packages are maintained by the community, so you should always check what exactly is included in the package, and the version in the package manager might not be the latest, so the project recommends using the official package installed with cargo install cot-cli.

The guide at cot.rs/guide/latest is the recommended next step, and the README asks you to read it to learn how to use Cot.

The ORM: Rust types as the source of truth

The ORM is the part of Cot that most changes what a day of work looks like, and its design rule is that Rust types are the source of truth. The ORM takes care of translating them to and from the database, and it creates the migrations automatically.

Automatic migrations are the headline. In a framework where you define a struct and change a field, the schema change and the migration that records it are generated rather than written by hand. That removes a class of work that is pure overhead in a project that does not need versioned schema history.

The style of interaction is described as feeling Rusty and intuitive, which is a promise the type safety claim backs up. Since the type is the source of truth, a query against a model carries the type of the model, and a field rename becomes a compile error rather than a runtime surprise.

The repository layout backs up the claim that this is a substantial subsystem rather than a thin wrapper. The workspace has cot as the main crate, cot-core, cot-macros, cot-codegen for the code generation that migrations and the admin panel need, cot-test for testing helpers, and cot-cli. The presence of a dedicated codegen crate is what a framework with generated migrations and a generated admin has to have.

The examples directory shows the ORM in use against a real application, with a todo-list example, a forms example, an admin example and a sessions example, next to json, file-upload, send-email, custom-task and custom-error-pages examples.

The admin panel: data management with no extra work

Cot ships an admin panel out of the box, so you can manage your app's data without writing an interface for it. The README says that adding new models to the admin panel is, in its words, stupidly simple, and that this makes it a good tool not only for rapid development and debugging but also, with its customization options, for production use.

The debugging angle deserves emphasis. Any project with a database and a model layer ends up needing a way to look at and fix rows by hand, and the usual answer is a database client, a script, or a throwaway view. An admin that is generated from the same types as the ORM removes that step, and the interesting part is that it is typed as well, which the type safety claim extends to the admin panel specifically.

The customization options are what the production claim rests on. A generated admin is only useful in production if you can control which fields appear, which actions are available, and how things are presented, and the README is explicit that this is possible.

The examples directory contains a dedicated admin example, which is the place to look for what the generated panel looks like in practice rather than inferring it from the feature list.

Secure by default, with the reasoning stated

The security feature is framed as a policy rather than a list. The README says security should be opt-out, not opt-in, that Cot takes care of making your web apps secure by default, defending against common modern web vulnerabilities, and that you can focus on building the app rather than securing it.

That is a defensible position for a batteries included framework, and it is also a position with a cost, because a framework that decides your security defaults is making choices you may disagree with. A team with an existing threat model, a house rule about cookie flags, or a compliance requirement, has to check that the defaults match the requirement rather than assuming they do.

The sessions example and the CSRF-related parts of the surrounding stack are the places to look for the concrete behaviour, since a framework that handles sessions and forms for you is making several security decisions at once.

The rest of the feature set follows the same philosophy. Sensible defaults are described as making it easy for rapid development while the API still empowers you when needed, and the documentation is called a first class citizen in the project, which is an unusual thing for a framework README to claim and an unusual thing to see honoured by a guide that is built from the docs directory in the repository.

The workspace, the services and the toolchain

The build configuration says a lot about how the project is developed.

The workspace is on edition 2024 with a rust-version of 1.94, which is a high floor and a deliberate choice, since it lets the project use recent language features. The lint configuration is strict: clippy's all group is denied, pedantic is warned, and the rust lints warn on things like deprecated safe functions, trivial casts, unreachable public items, unstable features and unsafe code.

The developer tasks run through just. Coverage uses cargo llvm-cov with branch coverage and doctests, and needs cargo-llvm-cov installed plus a nightly toolchain. Documentation is generated with rustdoc using a docsrs cfg, also on nightly. Tests run with cargo nextest, and there is a separate test-all alias that also runs the ignored tests.

The compose file defines the services the test environment expects: MariaDB 11, PostgreSQL 17 on alpine, Redis 8 on alpine, and a Selenium standalone Firefox image for browser driven tests, each with a health check.

  postgres:
    image: docker.io/postgres:17-alpine
    container_name: cot-postgres
    environment:
      POSTGRES_USER: cot
      POSTGRES_PASSWORD: cot
    ports:
      - "5432:5432"

The presence of two relational databases and Redis in the compose file is a signal about scope. Cot is not a framework for a single database, and the ORM and sessions layers are expected to work across more than one engine.

The limits: a 0.x API, a high toolchain floor, and a choice about scope

Three things to weigh before committing.

The first is versioning. The recent releases are cot-v0.7.0 and cot-cli-v0.7.0 from 2026-07-13, with cot-v0.6.0 from 2026-03-19. A 0.x line means the API can change in a minor release, and the repository carries a CHANGELOG.md, so the history is tracked, but the semver promise you would normally rely on does not exist yet.

The second is the toolchain floor. Rust 1.94 as a minimum, edition 2024, plus a nightly toolchain for documentation and coverage tasks, and cargo nextest for the test suite. That is fine for a team that already lives in the Rust ecosystem, and it is a barrier for a team whose CI images are older.

The third is the scope question, and it is the one to think about hardest. Cot is built on axum, and axum is a good answer if what you want is a routing and extraction layer with the rest of the architecture left to you. Cot's answer is that the rest of the architecture is the same for most applications, so it should be one decision instead of ten, and that the ORM, the admin and the migrations are the parts worth sharing.

If your application is unusual in its data model, or you need to make a different choice about sessions, storage or background jobs, the batteries included approach becomes something you work around rather than with. The examples directory, with its dedicated examples for sessions, forms, custom tasks and file uploads, is the place to check which of those decisions the framework already makes for you.

Editorial conclusion

Adopt Cot if you want the Django programming model in Rust, with an ORM that generates its own migrations, an admin panel that appears with the models, and security defaults you do not have to opt into. Do not adopt it if your team wants a bare routing layer, because axum is the foundation Cot is built on and Cot adds a large surface on top of it. Before you start, check the toolchain floor, since the workspace requires Rust 1.94 and the release line is still 0.x, so the API can move between minor versions.

Frequently asked questions

Official sources

1. cot-rs/cot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases