Wasmtime vs Wasmer para produção Edge Functions

O WebAssembly há muito designa um formato de tempo de execução para o navegador. Por vários anos, ele também tem sido usado para executar código em sandbox no lado do servidor ou na borda: um bytecode compilado uma vez, portátil em qualquer máquina host, isolado por padrão sem contêiner ou máquina virtual completa. Wasmtime e Wasmer carregam esta extensão para fora do navegador, ambos escritos em Rust, ambos capazes de executar o mesmo arquivo .wasm.

Wasmtime é um projeto hospedado pela Bytecode Alliance, organização que gerencia diversos componentes do ecossistema de servidores WebAssembly, incluindo o compilador Cranelift. Wasmer é desenvolvido pela Wasmer Inc., uma empresa que publica o tempo de execução como código aberto enquanto comercializa serviços complementares em torno dele (implantação de borda, ferramentas). Dois modelos de governação diferentes, sem julgamento sobre a qualidade do código produzido por um ou outro.

O restante deste artigo compara quatro campos verificáveis, licenciamento e governança, compiladores disponíveis, padrão WASI e modelo de componente, modelo de segurança e, em seguida, explica, com código de suporte, por que Rust core do Aurabase executa Wasmtime em seu mecanismo Edge Functions.

Wasmtime é lançado sob a licença Apache-2.0 com exceção LLVM, uma licença permissiva comum no ecossistema de compiladores. Sua governança segue o modelo da Bytecode Alliance: diversas organizações contribuem para o projeto, nenhuma é dona sozinha.

Wasmer é publicado sob a licença do MIT, ainda mais permissiva no papel, mas sua direção técnica permanece concentrada em um único editor, Wasmer Inc. Isso não é uma falha em si: muitos projetos de código aberto bem-sucedidos seguem esse modelo. É simplesmente um perfil de risco diferente se a sua organização valoriza a governança distribuída entre múltiplas entidades.

Wasmtime compila em produção via Cranelift, um gerador de código também da Bytecode Alliance. A caixa também documenta um compilador adicional, Winch, projetado para reduzir o tempo de compilação em comparação com o Cranelift em casos sensíveis à inicialização. O Cargo.toml deaura-functions apenas ativa o recurso cranelift: é este compilador, e somente ele, que processa cada módulo WASM carregado em produção.

Wasmer segue o caminho oposto: três back-ends intercambiáveis. Singlepass compila em uma única passagem, quase instantaneamente, ao custo de um código de máquina menos otimizado. Cranelift oferece um compromisso equilibrado. O LLVM visa o melhor rendimento de execução possível, com o maior tempo de compilação dos três. Um único tempo de execução, três perfis de compromisso escolhidos durante a configuração.

WASI, WebAssembly System Interface, padroniza o acesso a arquivos, relógios e à rede a partir de um módulo WASM, sem depender do navegador. Sua versão mais recente, WASI Preview 2, é baseada no Modelo de Componentes: um mecanismo para compor módulos escritos em diferentes linguagens, com interfaces digitadas compartilhadas em vez de um formato binário específico para cada tempo de execução. Tanto Wasmtime quanto Wasmer estão trabalhando na implementação deste padrão, cada um em seu próprio ritmo.

Wasmer documenta adicionalmente o WASIX, uma extensão que visa cobrir primitivas POSIX que o padrão WASI oficial ainda não cobre, como threads ou soquetes de rede mais abrangentes. Este não é um padrão suportado pelo grupo de trabalho WebAssembly, mas uma extensão específica do ecossistema Wasmer.

Ambos os tempos de execução isolam cada módulo em sua própria memória linear, sem acesso direto ao sistema host fora das funções importadas explicitamente. Esta é a base do modelo de segurança WebAssembly, comum aos dois projetos.

Wasmtime também expõe uma API de filmagem de execução nativa, fuel: cada instrução consome um orçamento fixado antecipadamente e a execução é interrompida corretamente quando esse orçamento se esgota. Uma segunda API, a interrupção epoch, permite impor um tempo limite sem bloquear o mecanismo enquanto espera. Wasmer documenta sua própria mecânica de medição e limites de memória por instância; Este artigo não os verificou em um repositório de terceiros, portanto não os divide figura por figura.

Isso é exatamente o que o serviço aura-functions do Aurabase permite, detalhado na próxima seção com o código-fonte real.

O serviço aura-functions declara wasmtime como uma dependência de produção, sem comentários de desativação ou configuração de dependência de desenvolvimento. Nenhum arquivo no repositório, nem Cargo.toml nem .rs, menciona Wasmer.

# Tempo de execução WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

O código de inicialização ativa explicitamente o combustível e a interrupção por época e, em seguida, limita a memória por invocação com StoreLimits:

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

// por invocação:
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);

Todos os três limites são configuráveis por variável de ambiente, com valores padrão verificados em config/mod.rs: WASM_MAX_MEMORY_MB em 64, WASM_TIMEOUT_SECS em 10, WASM_MAX_FUEL em um bilhão de unidades. O timeout é acionado em segundo plano: um tokio::spawn aguarda a duração configurada e depois incrementa a época do mecanismo, sem bloquear a execução atual enquanto espera.

A ABI exposta aos módulos convidados permanece intencionalmente mínima: quatro funções de host, aura.log, aura.get_input, aura.set_output e aura.get_env, registradas via linker.func_wrap. Não é o Component Model, nem o WASI Preview 2: é um contrato interno, mais restrito, projetado para uso único, executando uma função de borda HTTP e recuperando sua resposta JSON.

Este modo wasm é uma escolha por função, não uma alternância global. A visão geral da arquitetura Aurabase detalha o outro caminho, o modo padrão deno, que executa JavaScript/TypeScript em um serviço separado. Ambos coexistem no mesmo serviço aura-functions.

Fontes: Cargo.toml e wasm/mod.rs do repositório Aurabase, verificadas diretamente em 24 de agosto de 2026. Características gerais do Wasmtime e do Wasmer retiradas da documentação pública de cada projeto; nenhum valor de referência de terceiros é republicado nesta tabela.

Você inicia um novo tempo de execução de borda, sem dependências existentes. Wasmtime, apoiado por uma base de vários fornecedores, reduz o risco de depender de um único editor para o futuro do projeto.

Você tem partidas a frio muito frequentes e de curta duração. O backend Singlepass do Wasmer responde diretamente a essa necessidade, compilação quase instantânea, ao custo de código de máquina menos otimizado.

Você precisa de primitivos POSIX além do padrão WASI atual. WASIX, a extensão Wasmer, cobre threads e soquetes estendidos que o WASI Preview 2 sozinho ainda não cobre.

Você deseja uma API nativa de filmagem e tempo limite, sem middleware de terceiros. Wasmtime expõe fuel e epoch diretamente na caixa, exatamente o que aura-functions permite no Aurabase.