5 puntos por GN⁺ 2026-01-11 | 1 comentarios | Compartir por WhatsApp
  • Fly.io presentó recientemente Sprites, un concepto de computadora en la nube persistente que reemplaza a los sandboxes efímeros tradicionales
  • Puede crearse en 1 a 2 segundos y ofrece transición automática a inactividad, restauración desde checkpoints y 100 GB de almacenamiento duradero
  • Señala que el modelo tradicional de contenedores sin estado es ineficiente para agentes de IA (por ejemplo, Claude), y enfatiza la necesidad de un entorno persistente
  • Como caso real, presenta la experiencia de Claude construyendo y operando durante largo tiempo una app en Go basada en SQLite (MDM) sobre un Sprite
  • Conclusión del artículo: “La era de los sandboxes terminó, y llegó la era de las computadoras desechables

Sprites: computadoras en la nube persistentes - https://sprites.dev/

  • Fly.io afirma que el modelo de sandbox de solo lectura ya quedó obsoleto y presentó ‘Sprite’ como reemplazo
    • Con el comando sprite create se genera un root shell de Linux en menos de 1 segundo
    • Los Sprites tienen 100 GB de almacenamiento duradero y pueden entrar en ahorro de energía automáticamente cuando están inactivos para luego restaurarse
  • Con sprite-env checkpoints create se puede crear al instante un checkpoint de todo el sistema
    • Con sprite checkpoint restore v1 se restaura en 1 segundo, permitiendo versionado a nivel de sistema como en Git
  • Características principales
    • Crear cientos de instancias fácilmente
    • Detención automática de cobro (Idle metering) para reducir costos
    • Conectividad de red Anycast para ofrecer URL HTTPS
    • Persistencia total, manteniéndose hasta que se elimine explícitamente

Claude y los límites de los contenedores sin estado

  • Hoy, la mayoría de los entornos cloud están centrados en contenedores stateless
    • Los datos se guardan solo en bases de datos externas, buscando simplicidad y escalabilidad
  • Pero los agentes de IA como Claude no encajan bien en esta estructura
    • Muestran comportamientos de intentar rodear o escapar del contenedor, y quieren acceso a la “computadora” completa
  • Se plantea que una “computadora” debe tener durabilidad y un entorno que no desaparezca después del trabajo
    • Los sandboxes actuales carecen de ambas cosas

La simplicidad gana (Simple Wins)

  • En un entorno persistente ya no hace falta reconstruir el entorno de desarrollo (node_modules, etc.)
    • La industria está invirtiendo decenas de millones de dólares en tecnologías de snapshots para resolver esto
  • Existen casos donde se arma infraestructura real para que el agente acceda a recursos externos como S3, Redis, RDS
    • Eso es un parche temporal para esquivar la falta de persistencia del sandbox
  • Sprites elimina esa complejidad y ofrece un entorno donde los archivos que escribes permanecen tal cual
  • Como ejemplo, en el proyecto Phoenix.new, un agente basado en Fly Machine observa directamente los logs de la app y corrige errores

Galaxy Brain Win: fusión entre desarrollo y operación

  • El autor construyó junto con Claude una app en Go basada en SQLite (MDM) sobre Sprite
    • La URL Anycast se usó como URL de inscripción de MDM
    • Claude incluso configuró automáticamente el certificado APNS
  • Esta app lleva más de un mes funcionando de forma estable sobre Sprite
    • Se materializa la idea de “dev is prod, prod is dev”
  • Sostiene que la mayoría de las apps no necesitan tráfico masivo, y que son más importantes las apps persistentes personalizadas para cada usuario
    • Una estructura en la que el usuario puede pedir funciones directamente y verlas reflejadas de inmediato

El fin del sandbox y la era de las computadoras desechables

  • Fly.io lleva mucho tiempo desarrollando una plataforma de micro-VM con escalado horizontal, pero el modelo de sandbox llegó a su límite
  • Sprites es similar a Fly Machines, pero con un nuevo stack de almacenamiento y una nueva estructura de orquestación, y sin necesidad de Dockerfile
  • Se plantea la pregunta clave:
    > “Si puedes ejecutar un agente, ¿no preferirías una instancia de EC2 invocable al instante en lugar de un sandbox de solo lectura?”
  • Conclusión: “La era de los sandboxes terminó, y llegó la era de las computadoras desechables.”

1 comentarios

 
GN⁺ 2026-01-11
Comentarios de Hacker News
  • Al principio me gustó mucho, pero igual que en otras experiencias que he tenido con la Fly API, esta vez también se sintió medio rota
    Si ejecutas tal cual el comando de ejemplo de la documentación de https://sprites.dev/api, responde {"error":"name is required"}
    Pero si usas el cuerpo completo de la solicitud de la documentación de Create Sprite, funciona bien
    En un workflow personal quizá podría tolerar este tipo de asperezas, pero en CI/CD que afecta a todo el equipo me lo pensaría
    Me gustaría pedirle al equipo de Fly que los ejemplos de la documentación se validen sí o sí con automatización de pruebas

    • Probablemente sea porque no incluye el header Content-Type
    • Estaría bien poder reportar este tipo de problemas en un issue tracker público. No tiene que ser GitHub, pero sí hace falta un espacio donde los usuarios puedan discutirlo públicamente
  • https://sprites.dev/ está realmente interesante
    Resuelve de una sola vez dos problemas que me gustan

    1. Sandbox de entorno de desarrollo — un entorno de VM barato y persistente donde se pueden ejecutar con seguridad Claude Code o Codex CLI
    2. Sandbox API — permite ejecutar código no confiable en un entorno aislado con una simple llamada a una API JSON
      También tiene función de snapshots, así que es fácil volver al estado anterior después de ejecutar algo
      Escribí más detalles en mi blog → post de simonwillison.net
  • Filosóficamente me gusta Fly y he sido cliente desde los primeros días
    Pero el trabajo relacionado con su CLI todavía me da miedo. Aunque lo use solo una vez cada pocas semanas, las actualizaciones automáticas entran demasiado seguido y me cortan el flujo
    Me preocupa que Sprite CLI repita el mismo problema

    • Yo también dejé Fly por la misma razón y me pasé a Digital Ocean. Eso de “just works” fallaba demasiado seguido
  • ¡Esto está realmente interesante!
    En la empresa usamos un servidor de desarrollo persistente con Claude conectado por SSH, y es molesto cuando desaparece el repo de git o el entorno
    Sprite parece servir para guardar datos con algo como SQLite y crear una app sencilla accesible por URL
    Si la estructura hace que desaparezca automáticamente después de poco tiempo, suena perfecto para software personal simple
    Sería todavía mejor si tuviera una función para ver la URL pasando por autenticación de cuenta de Fly, como en los entornos preview de Vercel

  • Se ve bien, pero otros productos de Fly no han sido precisamente ejemplares en términos de estabilidad o nivel de acabado
    Hay bastante downtime de API y errores transitorios, y los problemas de facturación también tardan en resolverse
    Por ejemplo, instancias eliminadas siguen apareciendo como en uso, y la tarifa por hora se calcula al doble de lo real
    Han lanzado nuevos productos de IA como Phoenix.new y Sprites, pero parece que se están enfocando más en productos nuevos que en mejorar la calidad de los ya existentes

    • Si uno mira solo confiabilidad y soporte, no creo que haya motivo para usar esto
  • Llevo tiempo queriendo este tipo de sandbox para desarrollo: un entorno que no salga caro aunque olvides apagarlo
    Pero sí tuve algunos problemas

    1. Error manpath: can't set the locale — probablemente la configuración de locale local se transmitió tal cual
    2. $SHELL estaba configurado como /opt/homebrew/bin/fish. Me dio un poco de inquietud que las variables de entorno locales se estuvieran enviando al remoto sin permiso
  • Esto está muy bueno. Es justo el tipo de entorno de ejecución de sandbox con DX y API que estaba esperando
    Me gustaría poder personalizar la imagen base o la VM para incluir solo los binarios que necesito y no herramientas innecesarias
    O que existiera una función para clonar sprites a partir de checkpoints. Por ahora no veo una opción así

    • Estaría bien tener algo como un deploy de Docker, donde pueda subir una imagen base de sprite como yo quiera y seguir trabajando encima de ella
  • Me la he pasado muy bien trabajando en Sprites estos últimos meses
    Pronto vamos a publicar como open source parte del lado de Elixir
    También hay un video demo de 5 minutos → demo en YouTube

    • Lo interesante es que Claude controla Sprites por sí mismo. Cuando levantas el servidor, se registra automáticamente como un servicio local, y si hay cambios grandes crea checkpoints por su cuenta
      Los sprites que no se usan casi no cuestan nada. Cada vez que hace falta trabajo nuevo, simplemente creas uno nuevo
      Se siente curioso tener un entorno que puedes ejecutar en cualquier momento sin tener que decidir nada antes
  • Como el dominio es fly.io, al principio pensé que sería una solución local
    Aunque no fuera self-hosted, esperaba algo como un wrapper de VM local sobre Docker o bubblewrap

    • Para ese caso, vale la pena revisar el proyecto LXC/Incushttps://linuxcontainers.org/incus/
      Si ejecutas IncusOS basado en ZFS en hardware local, se vuelve un entorno de sandbox muy potente
  • Quizá se me pasó en la documentación, pero me pregunto si se puede hacer fork/clone de un sprite o restaurar un checkpoint como un sprite nuevo
    Por ejemplo, me gustaría usarlo para levantar varios a partir de un solo sprite como plantilla, o para que Claude Code explore varias soluciones y luego quedarse con una y limpiar el resto

    • Esa función llegará pronto. La próxima semana voy a explicar el porqué y cómo funciona en un post de “how this works”
      Queríamos incluirla en el lanzamiento, pero se decidió juntar un poco más de datos de uso real primero