{"id":135,"date":"2026-04-21T13:02:21","date_gmt":"2026-04-21T13:02:21","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/rust-web-frameworks-2026-axum-actix-rocket\/"},"modified":"2026-04-21T13:02:21","modified_gmt":"2026-04-21T13:02:21","slug":"rust-web-frameworks-2026-axum-actix-rocket","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/rust-web-frameworks-2026-axum-actix-rocket\/","title":{"rendered":"Rust web frameworks in 2026: axum, actix-web, and Rocket in practice"},"content":{"rendered":"

Honest opener: I spent two days last month picking between axum and actix-web for a new internal service. I had opinions going in, and somewhat different opinions coming out. This is the write-up I wish I’d had before I started.<\/p>\n

I’ve shipped Rust to production four times now, three of those were web services. Every time I sit down to pick a framework, I think the decision will be easy. Every time I end up re-reading docs and re-running benchmarks anyway. So here’s where I’ve landed in 2026, what I’d actually run on a fresh project, and the cases where I’d reach for something else.<\/p>\n

Short version for the impatient: axum for almost everything, actix-web when you need its actor model or have battle-tested middleware you don’t want to rewrite, Rocket for small services where developer ergonomics matter more than the rest of the ecosystem.<\/p>\n

The short version (and when each one wins)<\/h2>\n

I keep coming back to this table in my head, so here it is up front.<\/p>\n\n\n\n\n\n\n\n
Framework<\/th>\nReach for it when<\/th>\nAvoid when<\/th>\n<\/tr>\n<\/thead>\n
axum<\/td>\nDefault. Tower-flavored middleware, tonic gRPC, the broader tokio ecosystem<\/td>\nYou want batteries-included routing-by-macro<\/td>\n<\/tr>\n
actix-web<\/td>\nCPU-bound handlers, the actor model genuinely fits, you have existing actix middleware<\/td>\nYour team already lives in plain tokio and finds actor lifetimes confusing<\/td>\n<\/tr>\n
Rocket<\/td>\nSmall services, side projects, teaching Rust web dev<\/td>\nStreaming, gRPC, or any need for the wider tower ecosystem<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

That’s most of the post in three rows. Keep reading if you want code and the reasoning behind each pick.<\/p>\n

Why axum ended up being my default<\/h2>\n

axum wins for me because it composes with the rest of the tokio world. It uses tower::Service<\/code> everywhere, which means middleware written for tonic, hyper, reqwest, or a raw tower stack drops in without a translation layer. That’s not a nice-to-have. That’s the whole pitch.<\/p>\n

Here’s a real-ish example. You want a service with tracing, timeouts, compression, and an auth middleware. In axum that looks like:<\/p>\n

use axum::{routing::get, Router, middleware};\nuse tower_http::{trace::TraceLayer, timeout::TimeoutLayer, compression::CompressionLayer};\nuse std::time::Duration;\n\n#[tokio::main]\nasync fn main() {\n    let app = Router::new()\n        .route("\/health", get(|| async { "ok" }))\n        .route("\/api\/users", get(list_users).post(create_user))\n        .layer(TraceLayer::new_for_http())\n        .layer(TimeoutLayer::new(Duration::from_secs(10)))\n        .layer(CompressionLayer::new())\n        .layer(middleware::from_fn(auth_middleware));\n\n    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();\n    axum::serve(listener, app).await.unwrap();\n}\n<\/code><\/pre>\n
The layers stack because every one of them is a tower service. Swapping in a custom rate limiter or circuit breaker is .layer(MyLayer::new())<\/code>. I’ve used that property to share a middleware stack between gRPC services (via tonic) and HTTP services with the same observability and auth code.<\/p>\n
The extractor system is the other thing I like. Handlers look like normal async functions with typed arguments, and axum figures out how to pull each one from the request:<\/p>\n
use axum::{extract::{State, Path, Json}, http::StatusCode};\n\nasync fn create_user(\n    State(db): State<Pool>,\n    Path(org_id): Path<u64>,\n    Json(payload): Json<NewUser>,\n) -> Result<Json<User>, StatusCode> {\n    let user = db.insert_user(org_id, payload).await\n        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;\n    Ok(Json(user))\n}\n<\/code><\/pre>\n
No procedural macros, no opaque trait objects. The compiler tells you when a handler signature is wrong. I’ve had a junior engineer land axum PRs on day three of their Rust career, which I cannot say honestly about actix.<\/p>\n
actix-web: the workhorse that still earns its keep<\/h2>\n
I ran actix-web in production for about eighteen months before axum got stable enough for me. It’s still faster than axum on a lot of small-JSON benchmarks, and the actor model is genuinely useful when you have stateful work that needs to be serialized across requests, like a single-writer queue or a per-tenant rate limiter that needs strict ordering.<\/p>\n
A minimal actix-web handler is recognizable if you’ve used axum:<\/p>\n
use actix_web::{web, App, HttpServer, HttpResponse};\n\nasync fn create_user(\n    db: web::Data<Pool>,\n    path: web::Path<u64>,\n    payload: web::Json<NewUser>,\n) -> actix_web::Result<HttpResponse> {\n    let user = db.insert_user(path.into_inner(), payload.into_inner()).await\n        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;\n    Ok(HttpResponse::Ok().json(user))\n}\n\n#[actix_web::main]\nasync fn main() -> std::io::Result<()> {\n    HttpServer::new(|| {\n        App::new()\n            .app_data(web::Data::new(pool()))\n            .route("\/api\/users\/{org_id}", web::post().to(create_user))\n    })\n    .bind("0.0.0.0:3000")?\n    .run()\n    .await\n}\n<\/code><\/pre>\n
What bites you with actix-web is the runtime story. actix-web spins up its own tokio runtime variant by default, and mixing it with crates that assume a standard multi-threaded tokio takes more care than it should. I once spent an afternoon chasing a “runtime mismatch” panic that turned out to be actix’s current-thread runtime stepping on a Postgres pool that expected multi-threaded tokio. That kind of bug is hard because you don’t even know which layer to suspect first.<\/p>\n
The other thing: actix’s actor model is a separate mental model on top of async\/await. Teams that already know tokio find axum easier to pick up. Teams coming from an actor background (Akka, Erlang, that crowd) will find actix natural, sometimes more natural than axum.<\/p>\n
Rocket: the ergonomics king with one big trade-off<\/h2>\n
Rocket is the framework I recommend when someone is learning Rust web dev and I don’t want them to bounce off the language. It is macro-heavy on purpose, and the developer experience is closer to Flask or Django than anything else in the Rust ecosystem:<\/p>\n
#[macro_use] extern crate rocket;\n\nuse rocket::serde::{Deserialize, json::Json};\n\n#[derive(Deserialize)]\n#[serde(crate = "rocket::serde")]\nstruct NewUser { name: String, email: String }\n\n#[post("\/users\/<org_id>", data = "<payload>")]\nasync fn create_user(org_id: u64, payload: Json<NewUser>) -> Json<User> {\n    \/\/ ... call into a service layer here ...\n}\n\n#[launch]\nfn rocket() -> _ {\n    rocket::build().mount("\/api", routes![create_user])\n}\n<\/code><\/pre>\n
Clean, right? That’s the whole appeal. The catch is the ecosystem: Rocket doesn’t compose with tower, and its middleware story (called “fairings”) is its own thing. If the library you need is tower-flavored, you’ll fight it. For a side project where I control all the moving parts, Rocket is a nice place to live. For anything I expect to grow past five engineers, I don’t pick it.<\/p>\n
Middleware and extractors: where the daily pain lives<\/h2>\n
Benchmarks aren’t where these frameworks really differ. I don’t care if axum handles 180k req\/s while actix handles 220k when my Postgres is doing 800 req\/s on a good day. What matters is what happens the tenth time I add a cross-cutting concern.<\/p>\n
In axum, middleware is tower. If you can write a Service<\/code>, you can plug it into axum, hyper, or tonic. There’s a real learning curve to tower itself, but you only pay it once. The tower documentation<\/a> is dense but worth it, and what you learn there transfers to everything else in that ecosystem.<\/p>\n
In actix-web, middleware is its own trait hierarchy with Transform<\/code> and Service<\/code> impls that aren’t the same Service<\/code> as tower’s. The actix-web middleware guide<\/a> is solid, but the concepts don’t port. If you also write tonic services or wrap reqwest in a tower stack, you’re maintaining two parallel mental models.<\/p>\n
In Rocket, middleware is fairings, which are simpler but less powerful. There’s no streaming middleware story and no per-route layering the way you’d write it in axum.<\/p>\n
For a service that will pick up new cross-cutting concerns over time (auth, rate limiting, metrics, tracing, request IDs, tenant isolation), axum’s tower story is the one that keeps paying dividends.<\/p>\n
Tooling and the things benchmarks won’t tell you<\/h2>\n
Three things I wish someone had told me before my first Rust web service:<\/p>\n
First, tracing is not optional. Whichever framework you pick, wire up tracing<\/code> plus tracing-subscriber<\/code> plus an OpenTelemetry exporter on day one. axum’s tower-http::TraceLayer<\/code> makes it almost trivial. actix has actix-web-opentelemetry<\/code>. Rocket has ad-hoc community integrations. Budget a day for this. You’ll save a week the first time prod misbehaves.<\/p>\n
Second, error types compound. Every handler can return its own error, and once you have twenty of them you’ll wish you’d built a unified application error from the start. The pattern I keep reaching for is the one I wrote about in Go-style error handling patterns that actually help<\/a>: tag errors with context, return them as values, and centralize the conversion to HTTP responses in one place. The advice translates surprisingly cleanly to Rust.<\/p>\n
Third, check whether your database driver is runtime-aware. sqlx<\/code> is happy on tokio. Some Postgres clients assume async-std. A handful of older Redis crates pin specific runtime versions. I’ve been burned by every one of these and the symptoms always look like “my service hangs during startup” with no useful log line.<\/p>\n
If you want to compare notes on what I’ve shipped in Rust and what stack I picked for each project, I keep that on my work page<\/a>. Happy to swap stories if your constraints look different.<\/p>\n
What I’d actually run this week<\/h2>\n
If you’re starting a fresh Rust web service in April 2026, my honest recommendation is to start with axum, use tower-http<\/code> for middleware, sqlx<\/code> for your database, and tracing<\/code> plus an OpenTelemetry exporter for observability. You can read the axum docs<\/a> end-to-end in an afternoon and have a working service the same day. That stack composes, compiles, and scales further than most teams ever need.<\/p>\n
If you need to squeeze every last request out of a single box, benchmark actix-web against axum on your actual workload. Don’t trust TechEmpower numbers in isolation. The performance gap is smaller in 2026 than it was two years ago, and middleware composition costs more than raw routing in any service worth measuring.<\/p>\n
If you’re teaching someone Rust web dev from scratch, start them on Rocket and migrate them to axum once they understand the extractor pattern. The conceptual jump is small and Rocket gives them dopamine hits earlier in the learning curve.<\/p>\n
One concrete thing to do this week: spin up a new repo, add tokio<\/code>, axum<\/code>, tower-http<\/code>, and tracing-subscriber<\/code>, and ship a single \/health<\/code> endpoint that returns ok<\/code>. Then bolt on tracing. Then add a database. In that order. The framework you picked matters less than the fact that you got past the empty Cargo.toml<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
I picked axum for a new Rust service last month. Here’s what I learned comparing axum, actix-web, and Rocket in 2026, with code and when I’d switch.<\/p>\n","protected":false},"author":2,"featured_media":134,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"I picked axum for a new Rust service last month. Here's what I learned comparing axum, actix-web, and Rocket in 2026, with code and when I'd switch.","rank_math_focus_keyword":"rust web framework","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[45],"tags":[118,117,49,119,64,120,121],"class_list":["post-135","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","tag-actix-web","tag-axum","tag-backend","tag-rocket","tag-rust","tag-rust-web-development","tag-web-frameworks"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/135","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=135"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/135\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/134"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=135"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=135"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=135"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}