Axum vs Actix-web: Welches Rust-Framework in der Produktion?

Axum und Actix-web laufen beide auf Tokio, der asynchronen Referenzlaufzeit in Rust. In der README-Datei von Actix-web heißt es ganz deutlich: „Volle Tokio-Kompatibilität“ – und das offizielle Codebeispiel verwendet keinen Akteur aus dem historischen actix-Framework: Ein klassischer async fn-Handler mit der Annotation #[get(...)]ist ausreichend. Die Verwirrung „Actix-web erfordert unbedingt Schauspieler“ entspricht nicht mehr der aktuellen API.

Axum wurde in der direkten Umlaufbahn von Tokio geboren: Das Repository gehört der GitHub-Organisation tokio-rsund seine offizielle Dokumentation ist eindeutig: „Axum ist für die Zusammenarbeit mit Tokio und Hyper konzipiert. Die Unabhängigkeit von Laufzeit und Transportschicht ist zumindest vorerst kein Ziel.“

Es ist also keine Wahl zwischen zwei konkurrierenden Laufzeiten, sondern zwischen zwei Möglichkeiten, eine HTTP-API auf der gleichen asynchronen Engine aufzubauen. Dieser Vergleich deckt vier überprüfbare Bereiche ab – Middleware-Modell, deklarierte Speichersicherheit, native HTTP-Oberfläche, auf crates.io und GitHub gemessene Akzeptanz – und erklärt dann mit unterstützendem Code, warum der Rust-Kern von Aurabase sich für Axum entschieden hat.

Axum baut keine proprietären Middleware-Systeme. Es verlässt sich vollständig auf tower::Service: Zeitüberschreitungen, Nachverfolgung, Komprimierung, Autorisierung – alles kommt „kostenlos“ über das Tower-Ökosystem, heißt es in der eigenen README-Datei. Für eine Hyper- oder Tonic-Anwendung geschriebene Middleware kann ohne Anpassung unverändert in einer Axum-Anwendung wiederverwendet werden.

Actix-web geht den umgekehrten Weg: Es bettet sein eigenes Middleware-System (Logger, Session, CORS usw.), dokumentiert in seinem Benutzerhandbuch, mit seinem eigenen zugehörigen HTTP-Client (awc) ein. Es handelt sich um eine stärker integrierte Plattform – es müssen weniger Teile zusammengebaut werden, aber auch weniger direkte Wiederverwendung mit dem Rest des generischen asynchronen Rust-Ökosystems.

Das Routing folgt derselben expliziten Kompositionslogik. Axum behauptet eine „makrofreie API“ zum Deklarieren von Routen – Router::new().route(...) bleibt ein gewöhnlicher Rust-Wert – wobei Actix-web auf dedizierte Makros per HTTP-Methode (#[get(...)]) angewiesen ist, die direkt über dem Handler platziert werden. Zwei Aussagestile, kein Unterschied in der Fähigkeit.

Axum behauptet in seinem Quellcode #![forbid(unsafe_code)]: 100 % des Frameworks sind in sicherem Rust geschrieben, ohne Lücken. Actix-web macht in seiner README-Datei keine entsprechende Aussage – das bedeutet nicht, dass das Framework gefährlich ist, sondern nur, dass das Projekt keine solche Garantie öffentlich anzeigt.

Die beiden Frameworks legen eine unterschiedliche Mindestversion von Rust fest: Axum ist kompatibel ab Rust 1.80, Actix-web erfordert Rust 1.88. Ein engeres Fenster für Actix-web, das möglicherweise von Bedeutung ist, wenn Ihre Toolchain bei einer älteren Version hängen bleibt.

Actix-Web listet eine große HTTP-Oberfläche direkt in seiner Kiste auf: HTTP/1.x und HTTP/2, WebSockets, transparente Komprimierung (br, gzip, deflate, zstd), TLS über OpenSSL oder Rustls. Alles kommt zusammen, ohne dass zusätzliche Abhängigkeiten zur Auswahl stehen.

Axum bleibt bewusst minimal: Routing, Extraktoren, Fehlerbehandlung – der Rest (Komprimierung, CORS, Anforderungsbeschränkung, Ablaufverfolgung) kommt von tower-http, einer Begleitkiste aus demselben Ökosystem. Aurabase aktiviert beispielsweise nur die Funktionen cors, trace, compression-gzip, request-id, timeout und limit von tower-http – eine bewusste Auswahl, nicht das gesamte Paket.

Actix-web behauptet seine Geschwindigkeit, indem es eine genaue externe Quelle zitiert: „Eines der schnellsten verfügbaren Web-Frameworks gemäß dem TechEmpower Framework Benchmark“ (rund r21, zusammengesetzt), mit einem direkten Link zu techempower.com in seiner eigenen README-Datei. Dies ist die Art von Angebot, die Sie selbst überprüfen können.

Axum erhebt keinen vergleichbaren Anspruch. Seine README-Datei beschränkt sich auf eine bescheidenere Aussage – „Axum ist eine relativ dünne Schicht auf Hyper und fügt sehr wenig Overhead hinzu“ – mit zwei Links zu Community-Benchmarks von Drittanbietern, keine offizielle Projektzahl.

Auf crates.iohat Axum insgesamt 436.464.896 Downloads, einschließlich 109.000.226 in den letzten 90 Tagen. Actix-web sammelt insgesamt 78.074.020 Downloads, einschließlich 9.730.975 im selben aktuellen Fenster (crates.io, abgerufen am 23. August 2026). In diesem Punkt ist die Lücke deutlich: Axum erhält heute etwa elfmal mehr aktuelle Downloads als Actix-web.

Das Paradoxon: Actix-web ist das ältere der beiden, seit Oktober 2017 auf crates.io veröffentlicht, verglichen mit Juli 2021 für Axum. Auf GitHub ist der Beliebtheitsunterschied geringer – 26.931 Sterne für tokio-rs/axum gegenüber 24.793 für actix/actix-web (GitHub, abgerufen am 23. August 2026) – und Actix-web behält mehr Forks (1.880 im Vergleich zu 1.462), ein Zeichen dafür, dass eine historische Mitwirkendenbasis immer noch aktiv ist.

Actix-web ist noch lange nicht aufgegeben: Die Version 4.15.0 wurde am 21. August 2026 veröffentlicht, drei Tage vor dem Schreiben dieses Artikels. In der GitHub-Problemwarteschlange zeigt Axum 75 offene Tickets im Vergleich zu 192 für Actix-web an – ein Wartungssignal, das mit Vorsicht zu lesen ist: Eine fast vier Jahre längere Historie führt zu einer längeren Warteschlange, das ist kein Beweis für ein weniger sorgfältiges Projekt.

Der Aurabase-Root-Arbeitsbereich Cargo verfügt über elf Dienste. Zehn verlassen sich direkt auf Axum – vom API-Gateway (aura-gateway) bis zurnativen KI-Engine (aura-ai), einschließlich Authentifizierung und Speicherung. Das elfte, aura-migrator, ist ein Migrations-CLI-Tool ohne HTTP-Server: Es gibt einfach keine Auswahl. Kein Cargo.toml im Repository – noch irgendein Eintrag im Stammverzeichnis Cargo.lock – deklariert actix-web, selbst in transitiver Abhängigkeit; und keine .rs-Datei enthält die Anweisung use actix_web::.

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"] }

Diese Wahl ist nicht kosmetischer Natur: Das Aurabase-Gateway (aura-gateway) stapelt seine Middleware mit tower::ServiceBuilder und Layer Tower – TraceLayer, TimeoutLayer, RequestBodyLimitLayer – ergänzt durch interne Schichten über axum::middleware::from_fn für Anforderungskennung, Authentifizierung und Sicherheitsheader. Dies ist genau das Kompositionsmodell, das in der README-Datei von Axum hervorgehoben wird: Eine Tower-Middleware wird unabhängig vom Rest des Routers gestapelt, getestet und wiederverwendet.

Quellen: crates.io API (/api/v1/crates/axum, /api/v1/crates/actix-web) und GitHub API, abgerufen am 23. August 2026. Offizielle READMEs tokio-rs/axum und actix/actix-web für den Rest.

Sie starten ein modulares Rust-Backend mit mehreren Diensten. Axum passt perfekt – seine Tower-Komposition erleichtert die gemeinsame Nutzung von Middleware zwischen Diensten, wie es Aurabase zwischen seinen zehn HTTP-Diensten tut.

Sie verfügen über eine vorhandene und funktionierende Actix-Web-Codebasis. Es besteht keine Eile bei der Migration. Actix-web bleibt aktiv gepflegt und deckt HTTP/2, WebSockets und Komprimierung nativ ab, ohne zusätzliche Abhängigkeiten.

Sie möchten so viel HTTP-Funktionalität wie möglich in einer einzigen Kiste bereitstellen, ohne tower-http selbst zusammenzustellen. Actix-web reagiert direkt auf dieses Bedürfnis.

Sie teilen die Tower-Middleware bereits mit anderen Hyper- oder Tonic-Diensten (gRPC). Axum verwendet diese Schichten so wie sie sind – das ist das Argument, das bei Aurabase ausschlaggebend war.