Wasmtime vs. Wasmer für die Produktion Edge Functions

WebAssembly ist seit langem ein Laufzeitformat für den Browser. Seit einigen Jahren wird es auch verwendet, um Sandbox-Code auf der Serverseite oder am Edge auszuführen: ein einmal kompilierter Bytecode, portierbar auf jede Host-Maschine, standardmäßig isoliert ohne Container oder vollständige virtuelle Maschine. Wasmtime und Wasmer führen diese Erweiterung aus dem Browser aus, beide sind in Rust geschrieben und können beide dieselbe .wasm-Datei ausführen.

Wasmtime ist ein Projekt der Bytecode Alliance, der Organisation, die mehrere Komponenten des WebAssembly-Server-Ökosystems verwaltet, einschließlich des Cranelift-Compilers. Wasmer wird von Wasmer Inc. entwickelt, einem Unternehmen, das die Laufzeitumgebung als Open Source veröffentlicht und gleichzeitig ergänzende Dienstleistungen rund um sie vermarktet (Edge-Bereitstellung, Tooling). Zwei unterschiedliche Governance-Modelle, keine Beurteilung der Qualität des von dem einen oder anderen erstellten Codes.

Der Rest dieses Artikels vergleicht vier überprüfbare Felder, Lizenzierung und Governance, verfügbare Compiler, WASI-Standard und Komponentenmodell, Sicherheitsmodell, und erklärt dann mit unterstützendem Code, warum Aurabases Rust-Kern Wasmtime in seiner Edge Functions-Engineausführt.

Wasmtime wird unter der Apache-2.0-Lizenz mit LLVM-Ausnahme veröffentlicht, einer im Compiler-Ökosystem üblichen freizügigen Lizenz. Seine Governance folgt dem Modell der Bytecode Alliance: Mehrere Organisationen tragen zum Projekt bei, keine ist alleinige Eigentümerin.

Wasmer wird unter der MIT-Lizenz veröffentlicht, die auf dem Papier noch freizügiger ist, aber die technische Leitung bleibt bei einem einzigen Herausgeber, Wasmer Inc., konzentriert. Das ist an sich kein Fehler: Viele erfolgreiche Open-Source-Projekte folgen diesem Modell. Es handelt sich einfach um ein anderes Risikoprofil, wenn Ihr Unternehmen Wert auf eine verteilte Governance über mehrere Einheiten legt.

Wasmtime kompiliert in der Produktion über Cranelift, einen Codegenerator ebenfalls von der Bytecode Alliance. Die Kiste dokumentiert auch einen zusätzlichen Compiler, Winch, der die Kompilierungszeit im Vergleich zu Cranelift in Fällen, die beim Start empfindlich sind, verkürzen soll. Der Cargo.toml derAura-Funktionen aktiviert nur die cranelift-Funktion: Es ist dieser Compiler und er allein, der jedes in der Produktion geladene WASM-Modul verarbeitet.

Wasmer geht den umgekehrten Weg: drei austauschbare Backends. Singlepass kompiliert fast augenblicklich in einem einzigen Durchgang, allerdings auf Kosten weniger optimierten Maschinencodes. Cranelift bietet einen ausgewogenen Kompromiss. LLVM strebt den bestmöglichen Ausführungsdurchsatz mit der längsten Kompilierungszeit der drei an. Eine einzige Laufzeit, drei während der Konfiguration ausgewählte Kompromissprofile.

WASI, das WebAssembly System Interface, standardisiert den Zugriff auf Dateien, Uhren und das Netzwerk von einem WASM-Modul aus, unabhängig vom Browser. Die neueste Version, WASI Preview 2, basiert auf dem Komponentenmodell: einem Mechanismus zum Erstellen von in verschiedenen Sprachen geschriebenen Modulen mit gemeinsam genutzten typisierten Schnittstellen anstelle eines für jede Laufzeit spezifischen Binärformats. Sowohl Wasmtime als auch Wasmer arbeiten in ihrem eigenen Tempo an der Umsetzung dieses Standards.

Wasmer dokumentiert außerdem WASIX, eine Erweiterung, die darauf abzielt, POSIX-Primitive abzudecken, die der offizielle WASI-Standard noch nicht abdeckt, wie zum Beispiel Threads oder umfassendere Netzwerk-Sockets. Hierbei handelt es sich nicht um einen von der WebAssembly-Arbeitsgruppe unterstützten Standard, sondern um eine spezifische Erweiterung für das Wasmer-Ökosystem.

Beide Laufzeiten isolieren jedes Modul in seinem eigenen linearen Speicher, ohne direkten Zugriff auf das Hostsystem außerhalb explizit importierter Funktionen. Dies ist die Grundlage des WebAssembly-Sicherheitsmodells, das beiden Projekten gemeinsam ist.

Wasmtime stellt außerdem eine native Ausführungs-Footage-API zur Verfügung, fuel: Jede Anweisung verbraucht ein im Voraus festgelegtes Budget, und die Ausführung wird ordnungsgemäß gestoppt, sobald dieses Budget erschöpft ist. Mit einer zweiten API, der epoch-Unterbrechung, können Sie eine Zeitüberschreitung festlegen, ohne die Engine während des Wartens zu blockieren. Wasmer dokumentiert seine eigenen Mechanismen der Messung und der Speichergrenzen pro Instanz; In diesem Artikel wurden sie nicht in einem Drittanbieter-Repository überprüft und daher nicht nach Zahlen aufgeschlüsselt.

Genau das ermöglicht der aura-functions-Dienst von Aurabase, detailliert im nächsten Abschnitt mit dem eigentlichen Quellcode.

Der Dienst aura-functions deklariert wasmtime als Produktionsabhängigkeit, ohne Deaktivierungskommentare oder Entwicklungsabhängigkeitskonfiguration. Keine Datei im Repository, weder Cargo.toml noch .rs, erwähnt Wasmer.

# WASM-Laufzeit
wasmtime = { version = "43", features = ["async", "cranelift"] }

Der Initialisierungscode aktiviert Kraftstoff und Interrupt explizit nach Epoche und begrenzt dann den Speicher durch Aufruf mit StoreLimits:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// durch Aufruf:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

Alle drei Grenzwerte sind pro Umgebungsvariable konfigurierbar, wobei die Standardwerte in config/mod.rsüberprüft werden: WASM_MAX_MEMORY_MB bei 64, WASM_TIMEOUT_SECS bei 10, WASM_MAX_FUEL bei einer Milliarde Einheiten. Das Timeout wird im Hintergrund ausgelöst: ein tokio::spawn wartet die konfigurierte Dauer und erhöht dann die Engine-Epoche, ohne die aktuelle Ausführung während des Wartens zu blockieren.

Der für Gastmodule verfügbare ABI bleibt absichtlich minimal: vier Hostfunktionen, aura.log, aura.get_input, aura.set_output und aura.get_env, registriert über linker.func_wrap. Es handelt sich weder um das Komponentenmodell noch um WASI Preview 2: Es handelt sich um einen internen, enger gefassten Vertrag, der für den einmaligen Gebrauch konzipiert ist und eine HTTP-Edge-Funktion ausführt und seine JSON-Antwort wiederherstellt.

Dieser wasm-Modus ist eine Auswahl pro Funktion, kein globaler Wechsel. Die Aurabase-Architekturübersicht beschreibt detailliert den anderen Pfad, den Standardmodus deno, der JavaScript/TypeScript in einem separaten Dienst ausführt. Beide koexistieren im selben aura-functions-Dienst.

Quellen: Cargo.toml und wasm/mod.rs aus dem Aurabase-Repository, direkt verifiziert am 24. August 2026. Allgemeine Wasmtime- und Wasmer-Merkmale aus der öffentlichen Dokumentation jedes Projekts; In dieser Tabelle werden keine Benchmark-Zahlen Dritter erneut veröffentlicht.

Sie starten eine neue Edge-Laufzeit ohne vorhandene Abhängigkeiten. Wasmtime, unterstützt durch eine Multi-Vendor-Basis, reduziert das Risiko, für die Zukunft des Projekts von einem einzigen Herausgeber abhängig zu sein.

Sie haben sehr häufige und kurzlebige Kaltstarts. Das Singlepass-Backend von Wasmer reagiert direkt auf diesen Bedarf, nämlich eine nahezu sofortige Kompilierung, auf Kosten von weniger optimiertem Maschinencode.

Sie benötigen POSIX-Primitive, die über den aktuellen Standard-WASI hinausgehen. WASIX, die Wasmer-Erweiterung, deckt Threads und erweiterte Sockets ab, die WASI Preview 2 allein noch nicht abdeckt.

Sie möchten eine native Filmmaterial- und Timeout-API ohne Middleware von Drittanbietern. Wasmtime stellt fuel und epoch direkt in der Kiste bereit, genau das, was aura-functions bei Aurabase ermöglicht.