Microsandbox - máquina virtual que parece e funciona como um contêiner

• microsandbox oferece execução segura de código de usuários não confiáveis e de IA com isolamento no nível de máquina virtual
• Supera limitações de VMs e contêineres tradicionais com inicialização ultrarrápida (menos de 200 ms), compatibilidade com contêineres OCI e self-hosting
• Maximiza a eficiência de integração para desenvolvedores e ferramentas de IA com SDKs para várias linguagens de programação e ferramentas de CLI
• É adequado para uma ampla variedade de casos de uso em IA e desenvolvimento, como execução de código, ambientes de desenvolvimento, análise de dados, automação web e hospedagem de apps
• Todo o trabalho pode ser gerenciado por projeto, com suporte a instalação global no sistema, manutenção de sessão e ambientes de execução isolados

---

• O microsandbox é uma plataforma open source self-hosted projetada para a execução segura de código de usuário não confiável ou código de IA (por exemplo, agentes de IA, código enviado por usuários e código experimental)
• A execução local tradicional tem desvantagens como vulnerabilidades de segurança; contêineres têm isolamento incompleto por compartilharem o kernel; VMs tradicionais têm boot lento; e a nuvem carece de flexibilidade
• O microsandbox oferece isolamento real de processos baseado em microVMs (máquinas virtuais ultraleves), ao mesmo tempo em que entrega a mesma velocidade de inicialização e experiência amigável para desenvolvedores dos contêineres
• Ele se diferencia por inicializar em menos de 200 ms após a configuração inicial do ambiente, compatibilidade com imagens de contêiner (OCI), integração de IA baseada em MCP e controle sobre o uso da própria infraestrutura

Resumo dos principais recursos

• Bulletproof Security: com base em microVMs, oferece segurança no nível de máquina virtual que bloqueia na origem vulnerabilidades de contêineres, como escape de kernel
• Instant Startup: o tempo de boot inicial é inferior a 200 ms, permitindo início de execução de código extremamente mais rápido do que VMs tradicionais
• Self-Hosting & Full Control: pode ser implantado e operado diretamente em servidores locais ou próprios, sem dependência de nuvem
• Compatibilidade com OCI: pode executar imagens de contêiner padrão diretamente, mantendo compatibilidade com fluxos de trabalho existentes de Docker e contêineres
• AI-Ready (suporte a MCP): pode ser integrado e expandido naturalmente com IAs baseadas em MCP, como Claude e Agno

Fluxo rápido de desenvolvimento e execução

1. Iniciar o servidor

• É possível iniciar o servidor do microsandbox e configurar o ambiente de desenvolvimento com comandos simples
• O servidor também atua como servidor MCP, podendo ser chamado diretamente por ferramentas de IA como Claude

2. Instalar o SDK

• O SDK do microsandbox está disponível para linguagens principais como Python, JavaScript e Rust
• Com suporte adicional a várias outras linguagens (expansibilidade de SDK), amplia as possibilidades de integração entre desenvolvedores e IA

3. Executar código com segurança

• É possível escolher e executar separadamente ambientes sandbox para várias linguagens, como Python, JavaScript e Rust
• Cada sandbox é um ambiente de execução independente, garantindo a segurança do sistema mesmo ao executar código externo
• Exemplos com SDK facilitam a implementação de processos assíncronos e automatizados de execução segura de código

Gerenciamento de ambiente baseado em projeto

• O Sandboxfile (arquivo de configuração) é criado e gerenciado por projeto, em um fluxo semelhante ao de gerenciadores de pacotes amigáveis para desenvolvedores
• É possível adicionar múltiplos ambientes sandbox ao projeto (por exemplo, linguagens ou configurações diferentes) e gerenciá-los por versão e ambiente
• Ao executar sandboxes do projeto, arquivos e alterações de instalação são preservados automaticamente no diretório local (./menv)
• Há uma opção de ativação de sandbox temporário (com exclusão completa de todo o histórico e estado ao encerrar a sessão, mantendo o isolamento)

Instalação global de sandboxes no sistema

• Ambientes ou apps usados com frequência podem ser instalados e registrados como executáveis separados
• No terminal, é possível entrar diretamente no ambiente sandbox com um único comando, mesmo sem o caminho do projeto
• É possível nomear cada sandbox e operar várias configurações diferentes, com o estado da sessão também sendo mantido

Principais casos de uso

Execução de código de IA e ambiente de desenvolvimento

• Quando a IA automatiza de fato build, execução e depuração de código-fonte, o microsandbox fornece rapidamente um ambiente de desenvolvimento isolado e reproduzível
• É adequado para automação de código, como criação de webapps, correção de bugs e prototipagem

Análise de dados

• Bibliotecas importantes de ciência de dados, como NumPy, Pandas e TensorFlow, podem ser usadas com segurança dentro do sandbox
• É ideal para fluxos de análise que exigem proteção de dados pessoais ou sensíveis

Agentes de navegação web

• A IA pode realizar com segurança tarefas automatizadas como navegação em sites, envio de formulários, login e coleta de dados
• É útil para casos como coleta de conteúdo, comparação de preços e testes automatizados

Hospedagem instantânea de apps

• Ferramentas, demos, calculadoras e visualizações criadas por usuários podem ser compartilhadas imediatamente como serviços
• Cada app roda em um espaço isolado separado, com suporte à criação e encerramento rápidos de ambientes temporários

Estrutura do sistema

• O usuário chama o SDK do microsandbox a partir de sua própria lógica de negócio
• Solicita ao processo de servidor (microsandbox server) a entrega e execução de código não confiável
• Dentro do servidor, cada solicitação de execução é processada em uma microVM separada, isolada das demais
• Cada microVM pode configurar ambientes independentes de Python/Node

Política open source

• Distribuído como open source sob a Apache License 2.0

[GN⁺]

Comentários do Hacker News

• Gostaria de ver uma classificação oficial de segurança de contêineres
  1. fazer a curadoria de uma lista de todas as vulnerabilidades conhecidas de contêineres
  2. executar cada vulnerabilidade em vários ambientes de segurança, como baseados em permissões, jail, Docker, emuladores etc.
  3. seria interessante atribuir uma pontuação com base em qual porcentagem de todos os exploits foi bloqueada
     Desse jeito, contêineres simples baseados só em permission ou jail ficariam perto de 0%, Docker acima de 50% e o Microsandbox talvez perto de 100%
     Isso talvez ajudasse a responder aquela curiosidade instintiva do tipo “por que não usar simplesmente jail?”
     Também seria divertido “provar” qual contêiner chega a 100% colocando contêineres honeypot na web aberta e pagando recompensa em dinheiro ou cripto para quem conseguir hackeá-los
     Com vulnerabilidades recentes como Rowhammer e Spectre, talvez seja preciso redefinir a própria segurança da computação convencional e em nuvem
     No fim, a motivação é obter insights sobre como desenvolver contêineres 100% seguros sem emulação perfeita e como tornar seguros os serviços básicos do SO
• Em ambientes multi-tenant, o problema não são “vulnerabilidades de contêiner”, mas sim a estrutura fundamental de compartilhar o kernel
  Se existir uma vulnerabilidade de LPE (Local Privilege Escalation) no kernel, isso leva diretamente a escape de contêiner
  Normalmente isso não aparece rotulado como escape de contêiner, mas na indústria, se há LPE no kernel, entende-se naturalmente que a segurança de contêineres foi quebrada
• Contra contêineres maliciosos, é impossível construir um ambiente totalmente seguro usando runtimes de contêiner baseados no kernel Linux
  A alternativa mais visível é restringir fortemente o uso de syscalls (API) dentro do sandbox, mas nesse caso o contêiner deixa de ser uma plataforma de uso geral e surge o incômodo de ter que ajustar tudo de novo para cada caso
  Por isso há quem considere a virtualização necessária
  A menos que apareça um SO seguro em memória e robusto, esse é o único caminho, e mesmo que esse SO apareça, ainda não está claro se ele será mais rápido do que rodar uma MicroVM sobre Linux como host
• Seria bom se também mostrassem as configurações da máquina
  No Docker ou no systemd, o nível de segurança muda muito dependendo das várias opções de configuração
  Acho que precisamos de um grande conjunto de dados experimental mostrando quais configurações levam a quais níveis de risco/segurança
• Na prática, contêineres já são operados como honeypots com recompensa em dinheiro/cripto
  No mundo real, os próprios ambientes de produção já são alvo de ataques de inúmeros hackers
  Esse tipo de modelo de incentivo pode ser divertido, mas o valor real como alvo de invasão e o incentivo financeiro provavelmente seriam muito menores do que no ambiente real
• Tenho curiosidade sobre por que VMs tradicionais demoram para iniciar
  Por exemplo, no Windows, ao executar uma VM, é preciso esperar vários segundos até qualquer coisa começar a rodar
  Quando digo “não executa nada”, quero dizer antes mesmo de qualquer programa de usuário, antes de a primeira instrução do firmware sequer começar
  Há até um intervalo longo de espera antes de limpar o arquivo de disco virtual ou mesmo antes de a janela da VM aparecer
  Queria entender o motivo
  • Inicializar um kernel Linux em menos de 1 segundo é totalmente possível com otimização
    Mas com um kernel padrão, há muitas operações que consomem tempo, como timeout ou polling
    Em sistemas UEFI/CSM, preparar o hardware virtual e inicializar o ambiente do sistema também leva um bom tempo
    Suspeita-se que o WSL2 use um kernel especial para remover overhead desnecessário
    Inicialização de vários serviços do SO, preparação do sistema de arquivos, preparação de cache e configuração de rede também influenciam
    No modo tradicional, bootloader → initramfs → SO principal são todos carregados separadamente
    Para reduzir o tempo de boot ao extremo, usa-se uma abordagem como a do Amazon Firecracker, que carrega diretamente na memória uma imagem de VM já pré-inicializada
    Introdução ao Firecracker MicroVM
    No Windows, a velocidade de boot também varia conforme o hipervisor usado, como o HyperV
    O UEFI do HyperV é bem lento, e muitas distribuições Linux não oferecem kernels mínimos otimizados
  • Seria preciso mais informação sobre qual software de VM está sendo usado
    No caso do VirtualBox, o fenômeno perguntado aparece de forma bem clara, e versões antigas não tinham esse atraso
    Talvez não seja uma limitação essencial de “VM tradicional”, mas um problema daquele software específico
  • Não precisa ser necessariamente assim
    Em geral, VMs ficam lentas porque emulam até elementos desnecessários
    Se for possível criar um hipervisor focado em velocidade de boot e ignorar compatibilidade legada, dá para inicializar em 125 ms, como o Firecracker
  • No Linux, a principal causa de lentidão na alocação de memória para VMs é quando vários GB são alocados em páginas de 4 KB
    Se a alocação for feita em unidades de 1 GB, isso pode ficar dramaticamente mais rápido
    O Windows provavelmente tem algo parecido
  • Pode ser um problema do VirtualBox
    A pessoa relata experiência de acesso em 10 segundos via XRDP a um Ubuntu 22 GUI no Hyper-V e em menos de 3 segundos via SSH a um Ubuntu 22 Server
• Aponta a ironia de uma instrução de instalação do tipo “passe um script de instalação remoto direto para o Bash” em um cenário em que é preciso executar código não confiável
  Ainda assim, a ideia básica em si parece extremamente interessante
  • No começo eu nem tinha entendido do que se tratava, mas também é possível baixar o script de instalação separadamente e verificá-lo manualmente
    Em breve deve haver um método oficial de distribuição
• Agradece por compartilhar o projeto e revela ser o criador do microsandbox
  O objetivo foi tornar tão fácil criar microVMs quanto contêineres Docker
  Se houver dúvidas, perguntas são bem-vindas a qualquer momento
  • Estou usando bem agora pela biblioteca Python, mas quero manter o sandbox vivo ao longo de várias chamadas divididas
    Às vezes recebo erros como “Sandbox is not started. Call start() first”
    O padrão da documentação é “async with”, mas no meu caso eu gostaria de instanciar uma vez por classe e continuar reutilizando em vários métodos
    Queria saber se existe alguma abordagem recomendada ou best practice para isso
  • Estou montando uma rede de testes de software distribuído/descentralizado (Valet Network), e o microsandbox parece que vai ser muito útil
    Tenho curiosidade sobre como a rede funciona
    Por exemplo, dá para restringir a microVM para que ela só consiga acessar IPs públicos?
    Ou seja, dá para impedir que a microVM acesse IPs de rede local?
  • Projeto realmente muito legal, parabéns ao appcypher
    Fiquei curioso se a funcionalidade embutida de MicroVM expõe uma interface de runtime OCI
    Queria saber se também pode ser usado no Docker/Podman em vez de runc/crun
  • Dei uma passada rápida no readme e fiquei com algumas perguntas que eu queria ver melhor explicadas
    Como ele consegue ser tão rápido?
    Quais são os trade-offs em relação a uma VM tradicional?
    Existe alguma possibilidade de comprometer o isolamento da VM?
    Dá para abrir GUI?
    A ideia é ser o novo Vagrant?
    Como funcionam entrada e saída de dados?
  • Parece muito limpo
    Se entendi direito, dá para subir até backends em tempo real como se fossem servidores com isso?
    A lista de linguagens suportadas impressiona lista de linguagens suportadas pelo microsandbox
    Seria bom se o guia de contribuição fosse mais detalhado guia de contribuição
• Surpresa com a quantidade de opções de VM ultraleves, quase descartáveis, que surgiram nos últimos anos
  No passado, a experiência era de VMs lentas e pesadas, o que era bem sofrido
  Gostaria de comparar com o Orbstack no macOS, especialmente com a função “Linux machines”
  Fiquei curioso se o Orb reutiliza apenas uma VM
  • Site do Orbstack
  • Documentação do Orbstack Linux machines
• Parabéns
  Inicializar VM em milissegundos é uma melhoria muito importante
  Mas também é possível implementar algo parecido com CloudHypervisor e Firecracker
  Onde os contêineres ganham das VMs é no desempenho em runtime
  O que deixa VMs lentas é a emulação de dispositivos de E/S
  Especialmente em workloads de agentes de IA, esse overhead provavelmente será percebido no nível da aplicação
  Queria saber como pretendem resolver as questões de desempenho
  • Observação correta
    O Microsandbox usa libkrun, e o libkrun usa virtio-mmio para block, vsock e virtio-fs a fim de reduzir overhead de desempenho
    O Firecracker é essencialmente parecido, e o projeto E2B usa Firecracker para lidar com workloads de IA agentic
    No momento, além de questões de sistema de arquivos, não há grandes planos de melhoria de desempenho
• Pelo meu gosto pessoal, a tecnologia de contêineres parece expandir o SO em excesso
  Basta executar o comando mount para entender
  Tudo aquilo que deveria ficar escondido acaba aparecendo, e isso reduz a utilidade dos comandos simples de antes
  Um problema ainda mais sério é que o usuário pode mexer diretamente nas estruturas internas de dados
  É como se estivesse dando ao usuário permissões de peek e poke em tudo
  A ideia de contêiner em si é boa, mas, sem um redesenho do kernel, o modelo atual é só um remendo
  • Não entendi muito bem o comentário
    Você pode explicar por que executar mount dentro do contêiner seria tão grave?
    Os mounts do host ficam realmente expostos ao contêiner?
    Eu achava que isso normalmente só era possível quando algo como um volume é ligado explicitamente ao contêiner
• Parece muito interessante, deu vontade de testar na hora
  Também me diverti bastante com CodeSandbox SDK, E2B etc., então fiquei curioso sobre as diferenças entre eles e sobre a direção futura do projeto
  Também queria saber se usam Firecracker internamente
  • O Microsandbox não oferece uma solução em nuvem
    A proposta é self-hosted
    Ele facilita rodar sandboxes baseados em microVM localmente (Linux, macOS, Windows em breve), como o E2B, e depois migrar isso para produção com facilidade
    Em vez de Firecracker, usa libkrun
  • A minha maior curiosidade era justamente se usava Firecracker, então esse era o principal ponto
    Tenho curiosidade sobre questões de manutenção de soluções microVM e sobre se auditorias de segurança continuarão sendo feitas com regularidade
    Como a configuração de Firecracker e de imagens OCI é difícil, já acho ótimo surgir uma alternativa
    Kata container também é difícil de lidar
• Sempre me interesso quando aparece esse tipo de projeto
  A maior vantagem dos contêineres é poder rodá-los rapidamente sem precisar especificar recursos concretos como tamanho de disco ou número de núcleos de CPU
  Também dá para comparar o estado com a image e o diff para ver que mudanças um programa fez no sistema enquanto rodava
  Seria ótimo ter sandboxing mais seguro com VMs minúsculas que mantivessem esse nível de praticidade
  Às vezes também uso bwrap, mas não é uma ferramenta adequada para linha de comando
  • Recursos (capacidade de disco, CPU etc.) podem ser declarados uma vez em um arquivo YAML
    Também é possível usar templates ou geração remota/automática
• Fugindo um pouco do assunto, estou trabalhando em um projeto em que realmente preciso executar código JavaScript não confiável
  O microsandbox me dá esperança de conseguir isolar esse tipo de código com segurança
  Até o atraso de boot de 200 ms pode ser resolvido com um pool de sandboxes ao vivo
  Como há compatibilidade com OCI, dá para fornecer até o ambiente completo de sandbox
  Gostaria de saber se esse é mesmo um bom caso de uso e se não existe alguma alternativa melhor
  • Vale considerar também runsc/gVisor
    O engine runsc pode ser executado até dentro de Docker/Docker Desktop
    Porém, no gVisor, o desempenho em paralelismo de rede e afins fica em torno de 1/3 do Docker
  • Esse é exatamente um caso de uso ideal para o microsandbox
    Como não encontrei alternativa melhor, acabei criando o microsandbox