Axum vs Actix-web: which Rust framework in production?

Axum and Actix-web both run on Tokio, the reference asynchronous runtime in Rust. The Actix-web README states this bluntly — “Full Tokio compatibility” — and its official code example does not use any actor from the historical actix framework: a classic async fn handler, annotated #[get(...)], is sufficient. The confusion “Actix-web necessarily requires actors” no longer corresponds to the current API.

Axum was born in Tokyo's direct orbit: the repository belongs to the GitHub organization tokio-rs, and its official documentation is unambiguous — “axum is designed to work with tokio and hyper. Runtime and transport layer independence is not a goal, at least for the time being. »

So it's not a choice between two competing runtimes, but between two ways of building an HTTP API on top of the same async engine. This comparison covers four verifiable areas – middleware model, declared memory security, native HTTP surface, adoption measured on crates.io and GitHub – then explains, with supporting code, why the Rust core of Aurabase chose Axum.

Axum does not build any proprietary middleware systems. It relies entirely on tower::Service: timeouts, tracing, compression, authorization — everything comes “for free” via the Tower ecosystem, according to its own README. Middleware written for a Hyper or Tonic application can be reused as is in an Axum application, without adaptation.

Actix-web takes the opposite path: it embeds its own middleware system (Logger, Session, CORS, etc.), documented in its user guide, with its own associated HTTP client (awc). It's a more integrated platform — fewer parts to assemble, but also less direct reuse with the rest of the generic Rust async ecosystem.

Routing follows the same explicit composition logic. Axum claims a “macro-free API” for declaring routes — Router::new().route(...) remains an ordinary Rust value — where Actix-web relies on dedicated macros by HTTP method (#[get(...)]) placed directly above the handler. Two statement styles, not a difference in ability.

Axum claims #![forbid(unsafe_code)] in its source code: 100% of the framework is written in secure Rust, with no loopholes. Actix-web does not make an equivalent statement in its README — this does not mean that the framework is dangerous, only that no such guarantee is publicly displayed by the project.

The two frameworks set a different minimum version of Rust: Axum is compatible from Rust 1.80, Actix-web requires Rust 1.88. A narrower window for Actix-web, which may matter if your toolchain is stuck on an older version.

Actix-web lists a large HTTP surface directly in its crate: HTTP/1.x and HTTP/2, WebSockets, transparent compression (br, gzip, deflate, zstd), TLS via OpenSSL or Rustls. Everything comes together, with no additional dependencies to choose from.

Axum remains deliberately minimal: routing, extractors, error handling — the rest (compression, CORS, request limitation, tracing) comes from tower-http, a companion crate from the same ecosystem. Aurabase, for example, only enables the cors, trace, compression-gzip, request-id, timeout , and limit features of tower-http — a deliberate selection, not the entire package.

Actix-web claims its speed by citing a precise external source: “One of the fastest web frameworks available according to the TechEmpower Framework Benchmark” (round r21, composite), with a direct link to techempower.com in its own README. This is the type of quote you can verify yourself.

Axum makes no comparable claim. Its README is limited to a more modest statement — “axum is a relatively thin layer on top of hyper and adds very little overhead” — with two links to third-party community benchmarks, not an official project figure.

On crates.io, Axum has 436,464,896 downloads in total, including 109,000,226 over the last 90 days. Actix-web accumulates 78,074,020 downloads in total, including 9,730,975 on the same recent window (crates.io, accessed August 23, 2026). On this point, the gap is clear: Axum today receives around 11 times more recent downloads than Actix-web.

The paradox: Actix-web is the older of the two, published on crates.io since October 2017, compared to July 2021 for Axum. On GitHub, the popularity gap is narrower — 26,931 stars for tokio-rs/axum against 24,793 for actix/actix-web (GitHub, accessed August 23, 2026) — and Actix-web keeps more forks (1,880 compared to 1,462), a sign of a historical contributor base still active.

Actix-web remains far from being abandoned: its version 4.15.0 was published on August 21, 2026, three days before the writing of this article. On the GitHub issue queue, Axum displays 75 open tickets compared to 192 for Actix-web — a maintenance signal to be read with caution: a history almost four years longer mechanizes a longer queue, this is not proof of a less careful project.

The Aurabase root Cargo workspace has eleven services. Ten rely directly on Axum — from the API gateway (aura-gateway) to thenative AI engine (aura-ai), including authentication and storage. The eleventh, aura-migrator, is a migration CLI tool without an HTTP server: it simply has nothing to choose from. No Cargo.toml in the repository — nor any entry in the root Cargo.lock — declares actix-web, even in transitive dependency; and no .rs file contains use actix_web::instruction.

axum       = { version = "0.8", features = ["ws", "multipart", "macros"] }
tower      = { version = "0.5", features = ["full"] }
tower-http = { version = "0.6", features = ["cors", "trace", "compression-gzip", "request-id", "timeout", "limit"] }
hyper      = { version = "1", features = ["full"] }

This choice is not cosmetic: the Aurabase gateway (aura-gateway) stacks its middleware with tower::ServiceBuilder and Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer — supplemented by in-house layers via axum::middleware::from_fn for request identifier, authentication and security headers. This is exactly the composition model that Axum's README highlights: a Tower middleware is stacked, tested and reused independently of the rest of the router.

Sources: crates.io API (/api/v1/crates/axum, /api/v1/crates/actix-web) and GitHub API, accessed August 23, 2026. Official READMEs tokio-rs/axum and actix/actix-web for the rest.

You start a modular, multi-service Rust backend. Axum is a natural fit — its Tower composition makes it easier to share middleware between services, as Aurabase does between its ten HTTP services.

You have an existing and working Actix-web code base. There is no rush to migrate. Actix-web remains actively maintained and covers HTTP/2, WebSockets and compression natively, without additional dependencies.

You want as much HTTP functionality as possible delivered in a single crate, without assembling tower-http yourself. Actix-web directly responds to this need.

You already share Tower middleware with other Hyper or Tonic (gRPC) services. Axum reuses these layers as they are – this is the argument that weighed at Aurabase.