Em 9 de junho de 2026, o projeto Nucleus apareceu no Show HN com 29 pontos e 7 comentários em poucas horas. O que chamou atenção foi a proposta: runtime de container Nix-native, endurecido por padrão, que sobe um sandbox em 12 ms. Em um mercado onde o Docker leva cerca de 500 ms só para o handshake de cold start e o Podman depende de daemonização ou rootless gymnastics, isso é uma categoria nova. Cai num buraco específico: isolar AI coding agents em produção, sem pagar o overhead de VM, sem entregar permissões demais, sem amarrar a imagem num Dockerfile que vai envelhecer.
Resposta direta
Nucleus é um runtime de container minimalista em Rust, construído em cima de primitivas do kernel Linux (cgroups, namespaces, pivot_root, capabilities, seccomp, Landlock), desenhado para dois públicos: AI coding agents que precisam de sandbox efêmero de inicialização rápida, e serviços NixOS de produção que precisam de rootfs reproduzível, política declarativa e isolamento auditável. O cold start medido no benchmark oficial é de 12 ms contra ~500 ms do Docker. Em pgbench com PostgreSQL 18, Nucleus entrega TPS equivalente a bare metal (105.965 vs 100.222). Não é substituto de Docker — é uma camada que troca imagem por rootfs Nix.
O que é e por que importa agora
O projeto foi publicado pelo usuário sig-id no GitHub com licença MIT/Apache-2.0 e está no crates.io como nucleus-container. Tem três modos: agent mode (default, sandbox descartável), strict agent mode (fail-closed, sem rootfs de produção) e production mode (isolamento estrito com NixOS, health checks, sd_notify, journald). A escolha dos três modos mostra que o autor entende o problema real de 2026: o mesmo runtime precisa servir dois cenários opostos.
Por que isso importa agora:
- Coding agents em produção pararam de ser opcional. Em 2026, o Claude Code, GitHub Copilot CLI, OpenCode, Hermes Agent e Cursor CLI editam código de produção abertamente. Eles precisam rodar isolados, e o overhead de subir um container Docker para cada invocação de agente (500 ms + camadas de imagem) é caro demais para um loop iterativo. 12 ms muda o cálculo.
- Docker virou sinônimo de superfície de ataque. Camadas de imagem herdadas, registry trust assumptions, e a dependência de
dockerdcomo root abriram uma série de CVEs nos últimos dois anos. O Nucleus não tem daemon, é um único binário que faz fork/exec direto, e o rootfs é gerado pelo Nix store (cada caminho tem hash e é imutável). - NixOS saiu do nicho. Em 2026, a base de usuários corporativos de NixOS está crescendo porque a reprodutibilidade parou de ser nice-to-have e virou requisito de compliance. Para esses times, "runtime de container que entende Nix" é o caminho natural.
O ponto que quase ninguém cita: o Nucleus tem deny-by-default no egress de rede. Em vez de o default ser "container fala com a internet toda" (Docker default), o padrão é "container não fala com nada, a não ser que a regra diga". Isso é material de compliance de cara — sem você ter que configurar AppArmor, SELinux, ou network policies separadas.
Como funciona (sem jargão)
1. Rootfs em vez de imagem. Em agent mode, tmpfs populado com o contexto do agente. Em production mode, closure do Nix store: cada caminho tem hash, é imutável, pode ser atestado. Sem layer, sem registry, sem docker pull.
2. Isolamento via primitivas do kernel. O Nucleus aplica cgroups, namespaces, pivot_root, capabilities mínimas, seccomp (allowlist) e Landlock. Container Linux clássico com cada primitiva ativa por padrão.
3. Política externa, com hash. Regras de seccomp (JSON), capabilities (TOML) e Landlock (TOML) ficam em arquivos externos com SHA-256 pinned. Muda o arquivo, comita no repo, o runtime recarrega. Tem seccomp generate que roda em tracing, registra os syscalls reais do serviço e gera o allowlist mínimo automaticamente. É o oposto do AppArmor complain-mode que ninguém audita.
4. gVisor opcional. Para serviços network-bound, o Nucleus gera OCI bundle para runsc. Você escolhe entre kernel nativo (rápido) e emulação de syscall (mais lento, mais seguro) por serviço, no TOML.
5. Compose single-host. nucleus compose lê um TOML com DAG de dependência e reconcilia via systemd transient units. Single-host, 5 a 50 serviços, onde K8s é overkill.
A ideia de fundo: cada componente já existe no Linux há anos. O Nucleus junta todos com defaults seguros, sem daemon, com geração automática de política. É o que o ufw fez para iptables em 2005.
Comparativo rápido: antes vs agora
| Capacidade | Docker | Nucleus |
|---|---|---|
| Cold start | ~500 ms | 12 ms |
| Rootfs | Imagem em camadas (registry) | tmpfs (agente) ou closure Nix (produção) |
| Daemon | dockerd rodando como root | Binário único, fork/exec direto |
| Política de rede | Allow-all outbound | Deny-by-default, allow por CIDR/domain |
| Filesystem ACL | AppArmor/SELinux profiles | Landlock LSM por serviço, irreversível |
| gVisor | Add-on opcional | Runtime integrado de primeira classe |
| Reprodutibilidade | Image digest | Nix closure, rootfs attestation |
| Imagens / registry | Sim | Não |
A diferença não é "Docker é ruim". É "Docker é generalista, Nucleus é especializado". Para 90% dos casos, Docker continua sendo a escolha certa. Para os 10% onde o overhead de 500 ms importa (AI agents, microsserviços em loop curto, edge) ou onde reprodutibilidade bit-a-bit é mandatória (financeiro, farmacêutico, infra crítica), Nucleus ocupa um slot que estava vazio.
O que isso muda para o seu negócio
Se o seu time está rodando AI agents em produção:
1. Loop iterativo do agente fica viável. Subir sandbox em 12 ms significa que o agente pode pedir um ambiente novo a cada 5 minutos sem custo perceptível. Antes, com Docker, levava 1-2 segundos por iteração. Multiplica por 50 iterações por dia e são 50-100 segundos de overhead. É fricção cognitiva: o dev para de confiar no ciclo.
2. Compliance de rede fica de graça. O deny-by-default no egress resolve uma classe inteira de tickets. Para varejo que processa dados de cliente (LGPD) ou saúde (dados clínicos), é argumento concreto para o CISO.
3. Reprodutibilidade vira propriedade de primeira classe. Em production mode, o rootfs é uma closure Nix com hash. Para SBOM ou SLSA L3, é a diferença entre gerar relatório manualmente e exportar do Nix.
No segundo semestre de 2026, Nucleus ou um equivalente vira default em alguma distro focada em IA. Quem não estiver olhando vai descobrir quando o time de segurança pedir explicação de por que o cluster de agentes está com egress aberto.
Referência natural Agendai
Na Agendai a gente usa runtime hardened por padrão em todo deploy de agente para varejo. Não usamos Nucleus (a maioria dos clientes roda em Kubernetes), mas o padrão que ele materializa (deny-by-default no egress, política externa com hash, sem daemon, reprodutibilidade de rootfs) é o que replicamos com NetworkPolicy do K8s, seccomp em PodSecurity Standards, e OPA Gatekeeper. O pacote típico leva 2 semanas: semana 1 levanta o que cada agente pode tocar, escreve a política inicial em modo simulação, e roda 5 dias coletando log. Semana 2 liga o enforcement, ajusta false-positive, e integra com o pipeline de revisão. Primeira semana é de graça, sem fidelidade. Mais em agendai.cc.
Perguntas frequentes
O que é o Nucleus, em uma frase? Runtime de container Nix-native e endurecido, escrito em Rust, com cold start de 12 ms e isolamento baseado em primitivas do kernel Linux (cgroups, namespaces, seccomp, Landlock). Publicado em 9 de junho de 2026 no Show HN com 29 pontos.
Como o Nucleus consegue cold start de 12 ms?
Não tem daemon (dockerd), é um único binário que faz fork/exec direto. O rootfs é tmpfs pré-populado em agent mode, sem pull de imagem nem setup de camadas. O overhead é só o namespace setup do kernel, da ordem de milissegundos.
Quanto custa usar Nucleus em produção? O software é free (MIT/Apache-2.0). O custo é humano: escrever a política inicial em TOML, revisar log de tentativas bloqueadas, ajustar regras. Para 1-3 serviços cabe em 2-4 dias de um sênior. Para cluster maior, escala linear com a quantidade de serviços e a complexidade de rede.
Quais os riscos de usar o Nucleus?
Os principais em 2026: (1) projeto novo, base de usuários pequena, auditoria de CVEs mais lenta que em runtime estabelecido; (2) suporte a Windows e macOS como host é limitado (roda em Linux/NixOS, em outros SOs só via VM); (3) integração com Kubernetes ainda é manual, sem nucleus-operator oficial. Para produção crítica, vale esperar 2-3 meses de amadurecimento.
Nucleus substitui Docker? Não, o README é explícito. Para o caso geral (dev local, imagens compartilhadas, deploy em cloud, Docker Compose), Docker continua sendo a escolha certa. Nucleus ocupa o slot de "runtime hardened para AI agents e serviços NixOS", uma camada complementar, não substituta. Os dois podem coexistir no mesmo cluster.