TryNix corre qualquer pacote Nix num separador do browser
O TryNix arranca um núcleo Linux compilado para WebAssembly e corre qualquer uma das 310 083 versões do nixpkgs num separador. O python3 leva 7,5 segundos na primeira visita.
3 min de leitura

Já é possível correr qualquer pacote de toda a história do nixpkgs sem instalar nada. Farid Zakaria publicou o TryNix a 4 de setembro de 2026. Arranca um núcleo Linux compilado para WebAssembly dentro de um separador do browser e depois corre o pacote que pedir.
"You can browse the complete history of nixpkgs, over 310,083 package versions, and run any of them in a Linux machine that boots in your tab", escreveu Zakaria.
O nixpkgs é a coleção de pacotes por trás do Nix e do NixOS. A sua propriedade definidora é que todas as versões alguma vez publicadas continuam endereçáveis, e é isso que torna possível uma afirmação destas.
Como funciona na prática
As peças são todas tecnologia existente, montada de forma pouco comum.
Um núcleo Linux compilado para WebAssembly através do QEMU-WASM fornece a máquina. O Ghostty, um emulador de terminal, fornece a interface. Um armazém Nix em memória guarda o fecho do pacote, ou seja, o pacote e tudo aquilo de que depende.
Os pacotes chegam por HTTP simples a partir de caches binárias do Nix. Essa parte tem um requisito, e Zakaria di-lo com clareza: "The only requirement is that the cache is served with access-control-allow-origin: *."
Esse cabeçalho é todo o truque. As caches do Nix já são servidores públicos de ficheiros por HTTP, por isso com cabeçalhos cross-origin permissivos um browser consegue ir buscar diretamente, sem servidor pelo meio.
O que custa arrancar
Os arranques a frio contam-se em segundos, não em minutos.
| Pacote | Primeira visita | Regresso |
|---|---|---|
| hello | 4,2 s | 1,5 s |
| ripgrep | 4,3 s | 1,7 s |
| python3 | 7,5 s | 3,5 s |
A diferença entre as colunas é a cache do browser a fazer o seu trabalho. Uma segunda execução do mesmo pacote poupa quase todo o descarregamento.
Os limites são reais
Três restrições decidem se isto serve para o seu caso.
O tamanho do fecho fica por volta de 1,5 GB, contra um teto rígido de 4 GB do lado do WebAssembly. Cadeias de ferramentas grandes e tudo o que arraste um ambiente de execução pesado não cabem.
Há uma consola série e mais nada, como nota o repositório. Sem aplicações gráficas, sem janelas, sem um browser dentro do browser.
E tudo é traduzido de x86-64 para WebAssembly em tempo de execução, o que acrescenta latência. Este é um sítio para experimentar uma ferramenta, não para a medir.
O que isto significa para programadores
O uso imediato é a reprodução. Zakaria formula-o numa frase que vale a pena roubar: "Works on my machine" is a URL now for reproduction. Um relatório de erro com uma ligação que arranca a versão exata do pacote tem outra qualidade face a um que traz apenas uma versão em texto.
Para quem mantém documentação ou um repositório de ensino, isto elimina o pior passo de qualquer tutorial. "Instale primeiro o Nix" perde leitores. Uma ligação não perde.
Verifique os cabeçalhos da sua própria cache binária se quiser que isto funcione com os seus pacotes. O cabeçalho cross-origin é o requisito, e a maioria das caches privadas não o tem definido. É uma linha a mudar e uma decisão de segurança a tomar de forma consciente, porque abre a cache a qualquer origem.
Não planeie trabalho pesado à volta disto. Entre o teto de fecho de 1,5 GB e o custo da tradução, isto é uma superfície de demonstração, não um ambiente de desenvolvimento. O ecossistema Nix teve meses difíceis. A equipa central do Nixpkgs dissolveu-se e um artigo abriu uma porta no arranque do NixOS através do strip. Um projeto que torna mais fácil mostrar a parte boa do Nix chega em boa altura.
Fontes
- Any Nix package, live in your browser - Farid Zakaria
- fzakaria/trynix - GitHub
Artigos relacionados

Asahi Linux passa a suportar oficialmente os Mac da série M3
O Asahi Linux integrou o suporte a M3, M3 Pro e M3 Max no seu instalador. Wi-Fi, USB 3 e descodificação AV1 funcionam. Suspensão, HDMI e 3D rápido não.

Kubernetes 1.37 promove o modo rootless a beta
O Kubernetes 1.37 promove o KubeletInUserNamespace a beta. O kubelet, os runtimes de contentores, os plugins CNI e o kube-proxy passam a poder correr como utilizador comum.

Babashka 1.13.220 adiciona FFI para chamar bibliotecas nativas
O Babashka 1.13.220 adiciona uma FFI construída sobre a API Panama do Java: um script Clojure passa a chamar uma biblioteca nativa sem escrever um pod nem Java.