Wasmtime frente a Wasmer para producción Edge Functions

WebAssembly ha designado durante mucho tiempo un formato de tiempo de ejecución para el navegador. Durante varios años, también se ha utilizado para ejecutar código sandbox en el lado del servidor o en el borde: un código de bytes compilado una vez, portátil en cualquier máquina host, aislado de forma predeterminada sin un contenedor o máquina virtual completa. Wasmtime y Wasmer llevan esta extensión fuera del navegador, ambas escritas en Rust, ambas capaces de ejecutar el mismo archivo .wasm.

Wasmtime es un proyecto alojado por Bytecode Alliance, la organización que gestiona varios componentes del ecosistema del servidor WebAssembly, incluido el compilador Cranelift. Wasmer es desarrollado por Wasmer Inc., una empresa que publica el tiempo de ejecución como código abierto y comercializa servicios complementarios a su alrededor (implementación de borde, herramientas). Dos modelos de gobernanza diferentes, sin juicio sobre la calidad del código producido por uno u otro.

El resto de este artículo compara cuatro campos verificables, licencias y gobernanza, compiladores disponibles, estándar WASI y modelo de componentes, modelo de seguridad, luego explica, con código de soporte, por qué el núcleo Rust de Aurabase ejecuta Wasmtime en su motor Edge Functions.

Wasmtime se publica bajo la licencia Apache-2.0 con excepción LLVM, una licencia permisiva común en el ecosistema de compiladores. Su gobernanza sigue el modelo Bytecode Alliance: varias organizaciones contribuyen al proyecto, ninguna es propietaria por sí sola.

Wasmer se publica bajo la licencia del MIT, aún más permisiva en papel, pero su dirección técnica sigue concentrada en un único editor, Wasmer Inc. Esto no es un defecto en sí mismo: muchos proyectos de código abierto exitosos siguen este modelo. Es simplemente un perfil de riesgo diferente si su organización valora la gobernanza distribuida entre múltiples entidades.

Wasmtime compila en producción a través de Cranelift, un generador de código también de Bytecode Alliance. La caja también documenta un compilador adicional, Winch, diseñado para reducir el tiempo de compilación en comparación con Cranelift en casos sensibles al inicio. El Cargo.toml deaura-functions solo activa la característica cranelift: es este compilador, y solo él, el que procesa cada módulo WASM cargado en producción.

Wasmer toma el camino opuesto: tres backends intercambiables. Singlepass se compila en una sola pasada, casi instantáneamente, a costa de un código de máquina menos optimizado. Cranelift ofrece un compromiso equilibrado. LLVM apunta al mejor rendimiento de ejecución posible, con el tiempo de compilación más largo de los tres. Un único tiempo de ejecución, tres perfiles de compromiso elegidos durante la configuración.

WASI, la interfaz del sistema WebAssembly, estandariza el acceso a archivos, relojes y a la red desde un módulo WASM, sin depender del navegador. Su versión más reciente, WASI Preview 2, se basa en el modelo de componentes: un mecanismo para componer módulos escritos en diferentes idiomas, con interfaces escritas compartidas en lugar de un formato binario específico para cada tiempo de ejecución. Tanto Wasmtime como Wasmer están trabajando para implementar este estándar, cada uno a su propio ritmo.

Wasmer documenta adicionalmente WASIX, una extensión que tiene como objetivo cubrir primitivas POSIX que el estándar oficial WASI aún no cubre, como subprocesos o sockets de red más completos. Este no es un estándar respaldado por el grupo de trabajo WebAssembly, sino una extensión específica del ecosistema Wasmer.

Ambos tiempos de ejecución aíslan cada módulo en su propia memoria lineal, sin acceso directo al sistema host fuera de las funciones importadas explícitamente. Esta es la base del modelo de seguridad WebAssembly, común a ambos proyectos.

Wasmtime también expone una API de metraje de ejecución nativa, fuel: cada instrucción consume un presupuesto fijado de antemano y la ejecución se detiene correctamente una vez que se agota este presupuesto. Una segunda API, la interrupción epoch, le permite imponer un tiempo de espera sin bloquear el motor mientras espera. Wasmer documenta su propia mecánica de medición y límites de memoria por instancia; Este artículo no los ha verificado en un repositorio de terceros, por lo que no los desglosa figura por figura.

Esto es exactamente lo que permite el servicio aura-functions de Aurabase, que se detalla en la siguiente sección con el código fuente real.

El servicio aura-functions declara wasmtime como una dependencia de producción, sin comentarios de desactivación ni configuración de dependencia de desarrollo. No hay ningún archivo en el repositorio, ni el archivo Cargo.toml ni .rs, menciona Wasmer.

# Tiempo de ejecución WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

El código de inicialización activa explícitamente el combustible y la interrupción por época, luego limita la memoria mediante invocación con StoreLimits:

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

// por invocación:
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);

Los tres límites son configurables por variable de entorno, con valores predeterminados marcados en config/mod.rs: WASM_MAX_MEMORY_MB en 64, WASM_TIMEOUT_SECS en 10, WASM_MAX_FUEL en mil millones de unidades. El tiempo de espera se activa en segundo plano: un tokio::spawn espera la duración configurada y luego incrementa la época del motor, sin bloquear la ejecución actual mientras espera.

La ABI expuesta a los módulos invitados sigue siendo intencionalmente mínima: cuatro funciones de host, aura.log, aura.get_input, aura.set_output y aura.get_env, registradas a través de linker.func_wrap. No es el Modelo de Componentes, ni WASI Preview 2: es un contrato interno, más limitado, diseñado para un solo uso, que ejecuta una función de borde HTTP y recupera su respuesta JSON.

Este modo wasm es una elección por función, no una alternancia global. La descripción general de la arquitectura Aurabase detalla la otra ruta, el modo predeterminado deno, que ejecuta JavaScript/TypeScript en un servicio separado. Ambos coexisten en el mismo servicio aura-functions.

Fuentes: Cargo.toml y wasm/mod.rs del repositorio de Aurabase, verificados directamente el 24 de agosto de 2026. Características generales de Wasmtime y Wasmer extraídas de la documentación pública de cada proyecto; En esta tabla no se publican cifras de referencia de terceros.

Inicia un nuevo tiempo de ejecución perimetral, sin dependencias existentes. Wasmtime, respaldado por una base de múltiples proveedores, reduce el riesgo de depender de un solo editor para el futuro del proyecto.

Tiene arranques en frío muy frecuentes y de corta duración. El backend Singlepass de Wasmer responde directamente a esta necesidad, compilación casi instantánea, a costa de un código de máquina menos optimizado.

Necesita primitivas POSIX más allá del estándar WASI actual. WASIX, la extensión de Wasmer, cubre roscas y enchufes extendidos que WASI Preview 2 por sí solo aún no cubre.

Quiere una API nativa de metraje y tiempo de espera, sin middleware de terceros. Wasmtime expone fuel y epoch directamente en la caja, exactamente lo que aura-functions permite en Aurabase.