Wasmtime vs Wasmer : quel runtime WebAssembly pour des Edge Functions en production

WebAssembly a longtemps désigné un format d'exécution pour le navigateur. Depuis plusieurs années, il sert aussi à exécuter du code sandboxé côté serveur ou en périphérie : un bytecode compilé une fois, portable sur n'importe quelle machine hôte, isolé par défaut sans conteneur ni machine virtuelle complète. Wasmtime et Wasmer portent cette extension hors du navigateur, tous deux écrits en Rust, tous deux capables d'exécuter le même fichier .wasm.

Wasmtime est un projet hébergé par la Bytecode Alliance, l'organisation qui pilote plusieurs briques de l'écosystème WebAssembly serveur, dont le compilateur Cranelift. Wasmer est développé par Wasmer Inc., une société qui publie le runtime en open source tout en commercialisant des services complémentaires autour (déploiement edge, outillage). Deux modèles de gouvernance différents, pas un jugement sur la qualité du code produit par l'un ou l'autre.

Le reste de cet article compare quatre terrains vérifiables, licence et gouvernance, compilateurs disponibles, standard WASI et Component Model, modèle de sécurité, puis explique, code à l'appui, pourquoi le cœur Rust d'Aurabase exécute Wasmtime dans son moteur d'Edge Functions.

Wasmtime est publié sous licence Apache-2.0 avec exception LLVM, une licence permissive courante dans l'écosystème des compilateurs. Sa gouvernance suit le modèle de la Bytecode Alliance : plusieurs organisations contribuent au projet, aucune ne le possède seule.

Wasmer est publié sous licence MIT, plus permissive encore sur le papier, mais sa direction technique reste concentrée chez un seul éditeur, Wasmer Inc. Ce n'est pas un défaut en soi : de nombreux projets open source à succès suivent ce modèle. C'est simplement un profil de risque différent si votre organisation valorise une gouvernance répartie entre plusieurs entités.

Wasmtime compile en production via Cranelift, un générateur de code également issu de la Bytecode Alliance. Le crate documente aussi un compilateur d'appoint, Winch, pensé pour réduire le temps de compilation face à Cranelift sur les cas sensibles au démarrage. Le Cargo.toml d'aura-functions n'active que le feature cranelift : c'est ce compilateur, et lui seul, qui traite chaque module WASM chargé en production.

Wasmer prend le chemin inverse : trois backends interchangeables. Singlepass compile en une seule passe, quasi instantanément, au prix d'un code machine moins optimisé. Cranelift offre un compromis équilibré. LLVM vise le meilleur débit d'exécution possible, avec le temps de compilation le plus long des trois. Un seul runtime, trois profils de compromis choisis à la configuration.

WASI, le WebAssembly System Interface, standardise l'accès aux fichiers, aux horloges et au réseau depuis un module WASM, sans dépendre du navigateur. Sa version la plus récente, WASI Preview 2, s'appuie sur le Component Model : un mécanisme de composition de modules écrits dans des langages différents, avec des interfaces typées partagées plutôt qu'un format binaire propre à chaque runtime. Wasmtime et Wasmer travaillent tous deux à l'implémentation de ce standard, chacun à son rythme.

Wasmer documente en plus WASIX, une extension qui vise à couvrir des primitives POSIX que le standard WASI officiel ne couvre pas encore, comme les threads ou des sockets réseau plus complets. Ce n'est pas un standard porté par le groupe de travail WebAssembly, mais une extension propre à l'écosystème Wasmer.

Les deux runtimes isolent chaque module dans sa propre mémoire linéaire, sans accès direct au système hôte en dehors des fonctions explicitement importées. C'est la base du modèle de sécurité WebAssembly, commune aux deux projets.

Wasmtime expose en plus une API native de métrage d'exécution, le fuel : chaque instruction consomme un budget fixé à l'avance, et l'exécution s'arrête proprement une fois ce budget épuisé. Une seconde API, l'interruption par epoch, permet d'imposer un timeout sans bloquer le moteur pendant l'attente. Wasmer documente ses propres mécanismes de métrage et de limites mémoire par instance ; cet article ne les a pas vérifiés dans un dépôt tiers, donc ne les détaille pas chiffre par chiffre.

C'est exactement ce que le service aura-functions d'Aurabase active, détaillé dans la section suivante avec le code source réel.

Le service aura-functions déclare wasmtime comme dépendance de production, sans commentaire de désactivation ni configuration de dev-dependency. Aucun fichier du dépôt, ni Cargo.toml ni fichier .rs, ne mentionne Wasmer.

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

Le code d'initialisation active explicitement le fuel et l'interruption par epoch, puis borne la mémoire par invocation avec StoreLimits :

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;
// par invocation :
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);

Les trois limites sont configurables par variable d'environnement, avec des valeurs par défaut vérifiées dans config/mod.rs : WASM_MAX_MEMORY_MB à 64, WASM_TIMEOUT_SECS à 10, WASM_MAX_FUEL à un milliard d'unités. Le timeout se déclenche en tâche de fond : un tokio::spawn attend la durée configurée puis incrémente l'epoch du moteur, sans bloquer l'exécution en cours pendant l'attente.

L'ABI exposée aux modules invités reste volontairement minimale : quatre fonctions hôtes, aura.log, aura.get_input, aura.set_output et aura.get_env, enregistrées via linker.func_wrap. Ce n'est pas le Component Model, ni WASI Preview 2 : c'est un contrat maison, plus étroit, pensé pour un seul usage, exécuter une fonction HTTP edge et récupérer sa réponse JSON.

Ce mode wasm est un choix par fonction, pas une bascule globale. La vue d'ensemble de l'architecture Aurabase détaille l'autre chemin, le mode par défaut deno, qui exécute du JavaScript/TypeScript dans un service distinct. Les deux coexistent dans le même service aura-functions.

Sources : Cargo.toml et wasm/mod.rs du dépôt Aurabase, vérifiés directement le 24 août 2026. Caractéristiques générales Wasmtime et Wasmer issues de la documentation publique de chaque projet ; aucun chiffre de benchmark tiers n'est republié dans ce tableau.

Vous démarrez un runtime edge neuf, sans dépendance existante. Wasmtime, porté par une fondation multi-vendeur, réduit le risque de dépendre d'un seul éditeur pour l'avenir du projet.

Vous avez des cold starts très fréquents et de courte durée. Le backend Singlepass de Wasmer répond directement à ce besoin, compilation quasi instantanée, au prix d'un code machine moins optimisé.

Vous avez besoin de primitives POSIX au-delà du WASI standard actuel. WASIX, l'extension de Wasmer, couvre les threads et des sockets étendus que WASI Preview 2 seul ne couvre pas encore.

Vous voulez une API native de métrage et de timeout, sans middleware tiers. Wasmtime expose fuel et epoch directement dans le crate, exactement ce qu'active aura-functions chez Aurabase.