trynix.dev: ejecuta paquetes Nix en el navegador

Una VM Linux en tu pestaña con cualquier paquete Nix de la historia

Farid Zakaria, ingeniero conocido por su trabajo en el ecosistema Nix, presentó esta semana trynix.dev, un servicio que arranca una máquina virtual Linux dentro del navegador y la carga con cualquier versión histórica de un paquete de nixpkgs. El usuario solo tiene que entrar a la web, buscar el software y obtener una terminal con el binario listo en el PATH.

La cifra que resume el alcance: 310.083 versiones de paquetes indexadas, según anuncia el propio autor. Eso incluye desde un hello de 2005 hasta un python 3.6.2 de 2017, ejecutables sin instalar nada en el equipo. Zakaria lo describe como el «magnum opus» de años de trabajo en piezas anteriores como nixpkgs-multiverse, grail y omniflake (esta última llegó a combinar más de dieciséis mil flakes desde un solo input).

Lo llamativo no es solo la compatibilidad histórica: el sitio funciona sin servidor propio. Todo el procesamiento ocurre en la pestaña del usuario; los binarios se descargan desde cachés públicos que ya servían contenido estático. La única diferencia es que esos cachés llevan años devolviendo un encabezado access-control-allow-origin: *, la pieza que faltaba para que un navegador pudiera tratarlos como cliente legítimo de Nix.

La pila técnica que hace posible un Nix en el navegador

El truco combina tres ingredientes que llevan años madurando por separado.

Primero, un kernel x86_64 compilado a WebAssembly. Gracias al puerto de QEMU a WASM, es posible arrancar un kernel Linux real dentro de la pestaña. El navegador se convierte en una CPU virtual capaz de ejecutar binarios ELF estándar.

Segundo, un store de Nix en memoria. Cada binario de Nix almacena sus dependencias por ruta absoluta (incluidos loader y libc), así que dos versiones distintas del mismo programa pueden coexistir sin colisionar. trynix aprovecha esa propiedad para mostrar, por ejemplo, dos líneas de tiempo de hello corriendo a la vez en la misma VM.

Tercero, instantáneas de la máquina ya arrancadas. Como bootear un kernel emulado es lento, Zakaria publica un snapshot pre-iniciado: la VM se pausa antes de montar el store y se reanuda al primer clic. El navegador ya trae el motor y la imagen en caché; lo único que viaja en cada visita es la closure del paquete elegido.

El límite operativo está en la memoria de la pestaña: aproximadamente 1,5 GiB por cierre como tope duro actual, frente al techo de 4 GiB de WebAssembly por ser un espacio de direcciones de 32 bits. Zakaria reconoce que la emulación añade latencia: la primera ejecución de un binario se traduce de x86_64 a WASM y tarda; las siguientes son notablemente más rápidas porque la traducción queda en memoria.

Por qué la decisión de CORS fue providencial

Hay un detalle histórico que el propio autor subraya. Cinco años antes del lanzamiento, Zakaria había solicitado en el issue #156 del proyecto Nix que cache.nixos.org empezara a servir el encabezado access-control-allow-origin: * para poder consultarlo desde una API OpenAPI. Aquella petición, que entonces parecía menor, es exactamente lo que hoy permite que trynix funcione con la caché oficial sin pedir permiso a nadie.

El mismo principio se extiende a Cachix y, según el post, a GitHub Pages, que funciona como caché binaria de Nix «gratis» porque ya sirve contenido estático con CORS abierto. Eso cierra el círculo: cualquier equipo puede publicar un store path propio y entregarlo a un usuario o a un reviewer con un único enlace.

Casos de uso que ya no son truco de salón

Zakaria lista cinco aplicaciones concretas que van más allá del «miren qué cool»:

• Revisión de pull requests sin clonar. Si el CI ya empuja artefactos a Cachix, un bot puede colgar un enlace que arranca exactamente los binarios de esa PR. El revisor prueba el software en su navegador, sin compilar, sin fiarse de un pantallazo.
• Artefactos de agentes. Un agente de IA genera un store path; otro agente o una persona lo arranca en una pestaña y corre pruebas contra él.
• Bug reports que cargan su propio entorno. «Funciona en mi máquina» deja de ser una frase: es una URL reproducible.
• Documentación ejecutable. Un tutorial puede enlazar a una terminal con la versión exacta de la herramienta en el PATH, sin paso de instalación previo.
• Arqueología de software. Ejecutar la Python de 2017 o el hello de 2005 para comparar comportamiento entre eras.

Lo que une a los cinco es la misma idea: un entorno reproducible al que solo se accede haciendo clic.

¿Qué significa esto para tu startup?

Para un founder técnico, la noticia no es el juguete en sí, sino el patrón que valida. Tres acciones concretas que podés evaluar esta semana:

• Auditoría de tus pipelines de CI. Si ya usás Nix y Cachix, un simple job que publique la closure de cada PR te habilita a entregar builds compartibles a clientes y partners sin licencias de demo ni instaladores. Es el camino más corto entre «lo construimos» y «probalo ya».
• Reproducibilidad como producto. En LATAM, donde las máquinas de los clientes van desde Chromebooks hasta servers ARM, el viejo «en mi máquina funciona» cuesta horas de soporte. Empezar a versionar builds con Nix ahora es una inversión barata que paga cuando escalás.
• Sandbox para agentes internos. Antes de darle a un agente de IA acceso a tu infra real, podés montarle un entorno trynix-like donde cada acción queda contenida en una pestaña. Es una capa gratuita de contención para herramientas que aun no confías del todo.

El límite real sigue siendo el técnico: closures de hasta ~1,5 GiB y solo interfaz serie (sin GUI). Para una demo interna o un bug report puntual es más que suficiente; para flujos gráficos complejos, todavía no.

El contexto más amplio: Nix como columna vertebral del desarrollo reproducible

trynix llega en un momento en que Nix ya no es solo una curiosidad para hackers de sistemas. Como repasó Geeky Gadgets en un perfil reciente sobre Nix Darwin, el gestor de paquetes se posiciona como una alternativa declarativa a Homebrew y otras herramientas: archivos flake que garantizan que dos máquinas con la misma configuración terminen idénticas, y un modelo de versiones por ruta hash que impide las clásicas roturas de dependencias. La promesa original — entornos idénticos en cualquier lugar — es exactamente lo que trynix lleva ahora al navegador, eliminando incluso el requisito de tener Nix instalado.

La tendencia general es clara: cada vez más empresas trasladan la «infraestructura reproducible» desde la máquina del desarrollador hasta superficies donde el usuario final no necesita saber qué hay debajo. GitHub Codespaces, Gitpod y StackBlitz ya juegan en esa liga con editores completos. trynix entra en una esquina más específica pero útil: terminales con binarios reales servidos desde cachés abiertos, listas para compartirse como una URL.

Conclusión

trynix no es tanto un producto como una demostración pública de lo que ya era posible y estaba esperando a que alguien conectara los cables: kernel en WASM, store de Nix por ruta hash y cachés que ya servían CORS. Para founders, lo accionable no es adoptarlo mañana — es reconocer que el patrón «link reproducible = entorno ejecutable» ya está disponible, y empezar a diseñar flujos de QA, demos y soporte que lo aprovechen.

El código está en github.com/fzakaria/trynix y el sitio público es trynix.dev.

Fuentes

• Any Nix package, live in your browser — Farid Zakaria
• From One Config, Nix Builds Your macOS Tools — Geeky Gadgets