trynix.dev: ejecuta cualquier paquete de Nix en tu navegador

¿Qué es trynix.dev y por qué importa?

trynix.dev, presentado por Farid Zakaria como su "magnum opus" de trabajo en Nix, lleva la reproducibilidad de paquetes a un extremo: cualquier versión histórica de cualquier paquete del repositorio nixpkgs puede arrancar en una máquina virtual x86_64 directamente desde el navegador, sin instalar nada en el equipo del usuario. El sitio indexa más de 310.083 versiones de paquetes de los últimos 13 años de nixpkgs, según describe Zakaria en su blog.

Lo llamativo no es solo que funcione, sino cómo lo hace: el navegador carga un kernel Linux compilado a WebAssembly mediante el proyecto qemu-wasm de ktock, monta sobre él un Nix store en memoria y arranca una consola serie en la que el usuario puede invocar el binario seleccionado. Toda la operación se completa en segundos y la URL del paquete es compartible: el ejemplo que cita Simon Willison es https://trynix.dev/?pkg=python3%403.6.2, que arranca un shell con Python 3.6.2 de 2017 listo para ejecutar.

Zakaria no oculta su entusiasmo. El detalle importa porque hasta ahora reproducir una build de Nix requería instalar Nix en local, conectarse a un caché y ejecutar comandos. trynix reduce el ciclo a cero instalaciones: click y usar.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La arquitectura: Nix store + QEMU en WebAssembly

En el fondo, la pila que describe Zakaria es elegante por lo simple:

Un Linux x86_64 corre dentro del navegador gracias a qemu-wasm (la versión de QEMU portada a WebAssembly). No hay servidor intermedio: todo el procesamiento ocurre en la pestaña del usuario.
El closure del paquete (todas sus dependencias transitivas) se descarga desde cualquier caché Nix que sirva la cabecera Access-Control-Allow-Origin: *. Zakaria destaca que cache.nixos.org, Cachix y GitHub Pages ya cumplen ese requisito. De hecho, una solicitud que él mismo abrió hace cinco años (issue #156 en NixOS) terminó forzando esa cabecera en el caché oficial.
Una vez en el store dentro de la VM, el paquete se ejecuta con sus dependencias aisladas por ruta absoluta (la propiedad clásica de Nix), lo que permite tener dos versiones del mismo binario conviviendo sin conflictos.

El truco de latencia es lo que hace el producto utilizable. Zakaria explica que la página pre-descarga el motor y un snapshot de la VM en segundo plano, de modo que al hacer clic la mayoría de los activos ya están en caché del navegador. La VM nunca bootea desde cero: se reanuda desde un snapshot tomada en el momento previo a montar el store.

"Sigue sin ser instantáneo. Es lo suficientemente rápido para ser usable, pero no instantáneo. La ejecución de un binario sigue siendo lenta porque corre bajo emulación. La primera vez se traduce de x86_64 a WebAssembly y eso lleva tiempo; las siguientes ejecuciones reutilizan la traducción cacheada en memoria." — Farid Zakaria

Hay un techo físico: el closure total tiene que caber en la memoria de la pestaña. Zakaria fijó un límite duro de ~1,5 GiB en el navegador, y WebAssembly en sí está limitado a 4 GiB por su espacio de direcciones de 32 bits.

Otro detalle relevante: no estás restringido al caché público. Si publicas un store-path propio en GitHub Pages o en Cachix, cualquiera puede arrancarlo en su navegador. Zakaria enlaza una demo de un GNU hello modificado que no existe en cache.nixos.org y aun así arranca en su pestaña.

trynix-preview: la GitHub Action que boota PRs en el navegador

El segundo anuncio que recoge Simon Willison es trynix-preview, una GitHub Action publicada en el marketplace de GitHub. Su descripción oficial:

GitHub action que comenta un enlace en un pull request que permite bootear el build del PR en el navegador usando trynix.dev. Sin servidores, solo navegadores.

El flujo que propone Zakaria tiene implicaciones directas para equipos de ingeniería: si tu CI ya sube artefactos a Cachix, cuando un revisor mira el PR ya tiene binarios reales compilados por el CI esperándolo. En lugar de clonar, construir y confiar en un screenshot, el revisor hace clic y prueba el software directamente. La pregunta "¿esto arregla el bug?" deja de ser un ejercicio mental.

Casos de uso que van más allá del truco vistoso

Zakaria enumera cinco aplicaciones concretas que su proyecto habilita:

Repaso de PRs con el software ejecutándose, no con descripciones del software.
Artefactos de agentes: un agente de IA produce un store-path; otro agente (o un humano) lo boota en el navegador y corre tests contra él. La reproducibilidad deja de ser un eslogan.
Bug reports que llevan su propio entorno: el clásico "en mi máquina funciona" se convierte en una URL que el maintainer puede ejecutar sin configurar nada.
Documentación ejecutable: un tutorial puede enlazar a un shell con la versión exacta de la herramienta en PATH, pinneada para siempre.
Arqueología de software: ejecutar versiones históricas de Python, hello u otra utilidad para ver cómo diferían sus comportamientos.

Cada uno de estos casos existía antes con Nix en local; trynix los mueve al navegador, lo que cambia el coste de adopción a prácticamente cero.

El contexto: WebAssembly sale del navegador

trynix no surge en el vacío. WebAssembly lleva varios años expandiéndose más allá del navegador hacia cargas de servidor y edge. La adquisición de Fermyon por Akamai, anunciada en diciembre, y el lanzamiento de proyectos como Hyperlight Wasm de Microsoft —un micro-VM hipervisor para correr componentes WebAssembly de forma aislada— son señales de que la especificación está entrando en su fase de producción, según recoge Network World.

El propio Zakaria enmarca trynix dentro de su trabajo acumulado: nixpkgs-multiverse indexó cada versión de cada paquete que nixpkgs ha publicado; grail enseñó al sistema a entender rangos de versiones; omniflake añadió más de dieciséis mil flakes desde un solo input; y nixmultiverse.com aportó el "modo rápido" que evita la evaluación de Nix y va directo al store-path. trynix es la capa final que une todo eso con un navegador.

¿Qué significa esto para tu startup?

Aunque el proyecto es de un solo desarrollador y no tiene un modelo de negocio aparente, sus implicaciones prácticas para founders técnicos son directas:

Coste de demo en vivo casi cero para tu equipo de preventa. Enlaza a una build específica en un PR o en una rama de staging y tu cliente hace clic y prueba, sin instrucciones de instalación, sin Docker, sin "te paso un binario por Slack".
Reproducibilidad literal en soporte técnico. Cuando un cliente reporte un bug, en lugar de pedirle su entorno, le pasas un enlace que arranca la misma versión de tu binario que estás depurando tú.
Documentación que se ejecuta, no que se lee. Tu README puede apuntar a shells con versiones pinneadas; el lector nunca más dirá "no me funciona como dice aquí".

Dos acciones concretas que puedes tomar esta semana:

Si ya usas Nix y Cachix en tu CI, instala trynix-preview en un repositorio de prueba y observa cómo cambia la conversación en tus code reviews.
Si quieres mostrar software histórico o versiones antiguas como argumento educativo (tutoriales, comparativas, demos), prueba a enlazar desde tu web directamente a https://trynix.dev/?pkg=paquete@version y elimina el paso de instalación para tu lector.