actix-extras: the supporting crates that sit beside Actix Web

Nine crates that are not part of Actix Web

actix-extras is described as a collection of additional crates supporting the actix and actix-web frameworks, and it is hosted under the actix organisation with the project homepage at actix.rs.

The crate table in the project documentation lists what each one does, and the list is the clearest statement of the scope.

actix-cors provides Cross-Origin Resource Sharing controls. actix-identity handles identity management. actix-limitation does rate-limiting using a fixed window counter for arbitrary keys, backed by Redis. actix-protobuf is a protobuf payload extractor. actix-session is session management. actix-settings makes it easy to manage Actix Web's settings from a TOML file and environment variables. actix-web-httpauth covers HTTP authentication schemes. actix-ws provides WebSockets for Actix Web, without actors. tracing-actix-web is structured logging middleware for actix-web.

Two of those nine, actix-ws and tracing-actix-web, have their reference links pointing at crates.io rather than at local directories, while the other seven are linked as directories in the tree.

There is also a pointer outward. Community crates are listed at actix.rs/community/crates, so the distinction this repository draws is between crates the Actix organisation maintains and everything else that works with Actix but is maintained elsewhere.

That distinction is the useful thing to hold on to. actix-cors and actix-session are infrastructure every serious Actix deployment ends up needing, and having them versioned together with a shared policy is worth something. It also means the release cadence is per crate rather than for the whole set, which the release history shows clearly.

One workspace, one MSRV, one lint policy

The workspace configuration is where the shared policy becomes concrete. The Cargo.toml lists all nine crates as members, and the workspace package section sets the repository, the homepage, the licence and the language requirements.

edition = "2021"
rust-version = "1.89"

The licence field reads MIT OR Apache-2.0, and the repository root carries both LICENSE-APACHE and LICENSE-MIT. That is the standard Rust dual licence, which lets a downstream project pick either one, and it is the same choice actix-web itself makes.

The workspace lint configuration is stricter than the default. Three rustc lints are set to deny rather than warn.

rust_2018_idioms = { level = "deny" }
nonstandard_style = { level = "deny" }
future_incompatible = { level = "deny" }

Denying rust_2018_idioms and nonstandard_style across the workspace means the crates are held to a consistent idiom level, and denying future_incompatible means a change that would break later Rust editions is caught now. For a set of crates that people pull in together, that consistency is the point of having them in one repository rather than in nine.

The workspace also patches several crates.io dependencies to local paths, so actix-cors, actix-identity, actix-limitation, actix-protobuf, actix-session, actix-settings and actix-web-httpauth all resolve to the local directory during development. There is a commented block explaining how to uncomment a patch to test against a local actix-web checkout, which covers actix-http, actix-router, actix-web and awc.

The toolchain requirement is pinned rather than floated. The justfile computes the MSRV dynamically from cargo metadata, querying the first workspace package that has a source of null and a rust_version, then normalises a two component version into three. The result is used as a rustup toolchain override for the lint commands, so the checks run against the oldest supported compiler rather than whatever the developer happens to have installed.

The lint matrix reveals two crates that cannot be built all-features

The justfile is the most instructive file in the repository, because it shows how a nine crate workspace with heterogeneous features is actually checked.

The clippy recipe runs the whole workspace with all targets and all features, but excludes two crates from that pass.

cargo {{ toolchain }} clippy --workspace --all-targets --all-features --exclude tracing-actix-web --exclude actix-settings

The comment above it explains why, and it is a real constraint rather than a stylistic choice. tracing-actix-web and actix-settings have mutually exclusive feature sets, therefore all-features cannot be used for the entire workspace.

So those two are linted separately, with their feature combinations enumerated one at a time. tracing-actix-web is linted with no features, then with uuid_v7, then with opentelemetry_0_13, then with opentelemetry_0_32. actix-settings is linted over its tests, examples and bins, and then with the openssl feature and again with the rustls-0_23 feature.

The two OpenTelemetry versions are the interesting detail. Having both opentelemetry_0_13 and opentelemetry_0_32 as separate feature names means the crate supports two incompatible generations of the OpenTelemetry API at once, and the lint matrix checks each path independently.

The rest of the justfile follows the same pattern of verification rather than convenience. Formatting uses cargo +nightly fmt, and the YAML and Markdown files are formatted with prettier through fd, with fd and cargo-check-external-types named as external dependencies at the top of the file. There is a separate recipe to update the crate README files from the crate root documentation, and the fmt recipe depends on it, so the README content is generated rather than hand maintained.

The check recipe runs the same formatting steps in check mode, and a Rust toolchain file, rustfmt.toml, a .prettierrc.yml, a .cspell.yml for spell checking, and a deny.toml for dependency licence and advisory checks all sit at the root. There is also a zizmor.yml, which configures that tool's GitHub Actions security checks.

What each crate is actually for, in practice

Going through the list with a deployment in mind tells you more than the one line descriptions do.

actix-cors is the one most projects need first, because a single page application calling an API on another origin needs explicit CORS handling rather than the absence of it.

actix-identity and actix-session cover the two halves of a login system. Identity is the who, session is the continuity of that who across requests, and a project usually needs both or neither.

actix-web-httpauth is for the schemes that sit above identity, basic authentication and the digest variants, which is the answer when you want HTTP's own authentication model rather than a token in a header.

actix-ws is the WebSocket implementation, and the phrase without actors in the description points at a deliberate difference from the actor based approach in the wider Actix ecosystem. Actix Web itself moved away from actors, so this crate matches the direction the framework took.

actix-protobuf is a payload extractor, so a handler can take a protobuf body the way it would take JSON.

actix-settings is the configuration crate, and the description of managing Actix Web's settings from a TOML file and environment variables is the interesting part, since it means the server's own settings can be driven from the same place as the rest of your deployment configuration.

actix-limitation is the odd one out and worth reading closely. Rate-limiting using a fixed window counter for arbitrary keys, backed by Redis. The fixed window algorithm counts requests within a window that resets on a boundary, which is simpler than a sliding window and can let through a burst across the boundary. The Redis backing means the counter is shared across instances, which is the point of using it rather than an in-process counter.

tracing-actix-web is the observability piece, structured logging middleware, and the fact that it is the crate with the most active release history in the repository, with three releases on the same afternoon in September 2026, tells you where the attention has been.

Where actix-extras is the wrong choice

Three things to weigh before you take a dependency from here.

The first is that the crates are individually versioned and individually supported, which cuts both ways. The tracing-actix-web tags in the release list are named tracing-actix-web-v0.7.25, tracing-actix-web-v0.7.24 and tracing-actix-web-v0.7.23, three releases on 2026-09-20. That is a crate being shipped actively. Your Cargo.lock will end up with a version constraint per crate rather than one for the set, and you will be pulling them from crates.io individually in practice, whichever directory they live in.

The second is the mutual exclusivity of features, which the justfile documents and an end user will hit. If you enable actix-settings with openssl and also want rustls, you are in territory the project's own lint configuration has to work around, and the recipe splits actix-settings into two separate runs precisely for that reason.

The third is that this is an add-on collection, not a framework decision. Nothing in actix-extras makes you use Actix Web. The CORS crate, the session crate and the identity crate are all small and mostly self-contained, and each has a different maintenance story depending on where it lives. If you are choosing a web framework, actix.rs is the place to look, and if you only need CORS handling you could equally reach for a middleware crate outside this organisation.

The alternative approaches differ by what they cost. Writing the small pieces yourself, a CORS layer or a session middleware, is often a hundred lines and removes a dependency, though it puts the maintenance on you. Reaching for a framework that ships these features in the box avoids the dependency question entirely but commits you to that framework's larger surface. And taking only the crates you need from here, rather than treating the collection as a unit, is the pragmatic middle path, with the caveat that you are then tracking their release lines separately.

Editorial conclusion

actix-extras suits a team already committed to Actix Web that needs CORS handling, identity, sessions, HTTP authentication or tracing middleware without picking each crate from a different corner of the ecosystem. It does not suit a team choosing a web framework, since nothing here is a framework, and it does not suit anyone who wants the whole set by default, since each crate is a separate dependency with its own version line. Before adopting one, check the MSRV, which the workspace pins at Rust 1.89, and read the justfile, because the lint configuration shows that two of these crates have mutually exclusive feature sets and cannot simply be built with all features enabled.

Frequently asked questions

Official sources

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