- Aunque sus resultados eran sólidos, la identidad del negocio empezó a tambalearse; Fly.io consiguió financiamiento adicional, puso la dirección en manos del ex CEO de Docker Scott Johnston y convirtió a Sprites en su negocio principal
- A medida que la IA permite que cualquiera cree software a medida, se vuelve difícil diferenciarse solo con una nube pública que despliega cerca de los usuarios y con comodidad centrada en desarrolladores humanos
- Sprites son computadoras para agentes que pueden crearse por cientos o miles cuando se necesitan y mantenerse durante mucho tiempo; cada una ofrece un disco persistente de 100 GB y cobro por uso que se detiene cuando está inactiva
- Los nuevos Sprites agregan Sprite Block Device, más rápido y estable, bifurcación de discos y Connectors para llamar a sistemas externos sin exponer credenciales
- Fly.io no intentará perseguir al mismo tiempo una plataforma de aplicaciones con funciones fijas diseñada por humanos y un futuro centrado en agentes; se concentrará en lo segundo, aunque Fly Machines y las funciones PaaS existentes seguirán manteniéndose
Una crisis de identidad en medio de resultados sólidos
- Theo Browne evaluó el mejor lugar para alojar aplicaciones nuevas en 2026 y habló positivamente de Fly.io, pero también dijo que, entre los proveedores que sigue, era el que menos podía asegurar que seguiría existiendo para fin de año
- En ese momento, Fly.io venía de trimestres sólidos, incluidos los mejores resultados financieros de su historia, pero seguía sin resolver el problema de identidad sobre qué construir y hacia dónde ir
- Fly.io consiguió una cantidad considerable de financiamiento adicional, lanzó una nueva versión de Sprites para concentrar las capacidades de la empresa y nombró a Scott Johnston como CEO
Cambiaron los supuestos del encaje producto-mercado existente
- Fly.io nació de dos principios
- Las aplicaciones de internet son más rápidas cuanto más cerca de los usuarios se despliegan
- En lugar de una infraestructura cloud compleja, había que ofrecer a los desarrolladores tanto la flexibilidad de AWS como la facilidad de uso de Heroku
- Ambos principios siguen siendo importantes, pero con la IA transformando el desarrollo de software ya no son tan decisivos como antes
- Integrar agentes de programación en el proceso de desarrollo existente como si fueran compiladores más inteligentes no alcanza para captar la magnitud del cambio
- Antes de que existieran las hojas de cálculo, incluso las tareas equivalentes a los documentos de Excel actuales tenían que ser programas creados por programadores; las fórmulas de las hojas de cálculo convirtieron en programadores a innumerables personas de áreas de negocio
- La IA provoca un cambio todavía mayor y avanza hacia un mundo en el que casi cualquiera pueda crear casi cualquier tipo de programa
- Las nubes públicas existentes fueron diseñadas para desplegar aplicaciones de funciones fijas, sometidas a estándares estrictos y procesos de CI/CD, para millones de personas
- En el futuro seguirán existiendo programas dirigidos a millones de usuarios, pero quizá no sean la forma común, del mismo modo que una hoja de cálculo vista por millones de lectores no lo es
- Seguir apostando por el diseño de nube pública de 2020 equivale a apostar contra la expansión del software personalizado y adaptable
- Fly.io elige un mundo en el que amigos y familiares puedan hacer directamente con una computadora lo que quieren, sin esperar a un desarrollador
Las necesidades de los agentes por encima de la experiencia de desarrollador humana
- El problema de que la infraestructura cloud sea difícil para los desarrolladores sigue existiendo, pero a medida que los agentes hacen el trabajo en su lugar, disminuye la importancia de una experiencia de desarrollo cuidadosamente diseñada para humanos
- Para agentes que funcionan mejor en entornos explícitos, los valores predeterminados muy opinados y una experiencia de desarrollo curada incluso pueden ser una desventaja
- La gente empieza a delegar en agentes en lugar de leer documentación y aprender una nueva CLI por prueba y error
- Un agente puede resolver de una sola vez la solicitud de desplegar en Fly.io un sitio creado localmente, pero también puede desplegar en AWS de una sola vez, por lo que la facilidad de uso existente ya no alcanza para diferenciarse
- Tras observar que sus clientes de mayor crecimiento eran robots, Fly.io dejó de reinterpretar su producto existente para agentes y empezó a buscar el entorno que los agentes realmente quieren
La computadora que quieren los agentes
- Los agentes de programación están diseñados básicamente para ejecutarse en la estación de trabajo de un desarrollador
- Incluso si se ejecutan en un sandbox confiable, cuando corren en una laptop física el trabajo se interrumpe en cuanto se cierra la tapa, así que los usuarios terminan moviendo los sandboxes de agentes a la nube
- Los servidores de nube pública existentes exigen compromisos demasiado grandes para el trabajo de agentes
- Deben ser más efímeros que los servidores tradicionales tipo mascota o tipo ganado
- Deben poder crearse en el momento deseado, mantenerse solo el tiempo necesario y operar con bajo costo
- Sprites son computadoras semidesechables pensadas para esas necesidades
- Se pueden crear rápidamente por cientos o miles
- Cada Sprite incluye un disco persistente de 100 GB
- Se cobra según el uso, pero la medición se detiene cuando no hacen nada, y el estado de inactividad se determina automáticamente
- Pueden alojar aplicaciones y compartirse con colegas a través de internet
- La industria se concentra en los sandboxes, pero lo que necesitan los agentes no es un sandbox, sino una computadora con persistencia y utilidad
- Se pueden crear Sprites al instante para probarlos directamente
Convertir Sprites en el centro de la empresa
- Los Sprites iniciales fueron un proyecto creado por un pequeño equipo informal dentro de Fly.io, y ni siquiera estaban alojados en el sitio web principal de Fly.io
- En adelante, computadoras para agentes (Computers for Agents) será el foco central de la empresa, y Sprites dejará de ser un proyecto a cargo de unas pocas personas
- Fly Machines y las funciones existentes de plataforma como servicio (PaaS) no se eliminarán y seguirán ofreciéndose
- Los nuevos Sprites mejoran la escalabilidad y la orquestación, e incorporan dos subsistemas importantes para completar el conjunto de funciones buscado
Sprite Block Device y bifurcación de discos
- La pila de almacenamiento existente estaba construida sobre JuiceFS y conectada con Litestream
- Sprite Block Device (SBD), una pila de almacenamiento reconstruida desde cero por Ben Johnson y Tim Newsham, es más rápida y estable que la anterior, y mantiene las funciones de checkpoint y restauración instantáneas
- Con drive forking, una extensión clave de SBD, se puede crear un Sprite de plantilla y replicarlo de forma eficiente millones de veces
Connectors para evitar la exposición de credenciales
- Connectors se basan en los tokens tokenizados desarrollados para proteger la plataforma central de Fly.io
- Están diseñados para que un Sprite envíe solicitudes autenticadas a otros sistemas sin entregar directamente al agente credenciales que puedan filtrarse
- Son más fáciles de usar que administrar cuentas y claves API manualmente
- Las capacidades de replicación de SBD y Connectors son las funciones que más pidieron los clientes, y también explican por qué muchas empresas de agentes siguieron usando Fly Machines incluso después del lanzamiento de productos dedicados para agentes
- Salvo que aparezca un cambio tecnológico más extraño que los modelos Transformer, Fly.io considera que Sprites encaja con sus clientes futuros y con buena parte de los actuales, por lo que ofrece una nueva beta
La salida del CEO fundador
- Durante sus primeros ocho años, Fly.io operó como una organización experimental en busca de encaje producto-mercado
- Probó decenas de cosas, como Postgres no administrado, una CDN global y WireGuard en modo usuario
- Construyó una organización de ingeniería de abajo hacia arriba, evitó una hoja de ruta de producto y formó un equipo totalmente remoto que trabaja en más de 12 países
- Algunos experimentos dieron resultados y otros sirvieron como aprendizaje, pero Fly.io en su etapa actual ya no necesita ese tipo de proyectos científicos
- El fundador concluyó que había agotado la mayor parte de las fortalezas que podía aportar como CEO y dejó el cargo
Scott Johnston asume como CEO
- Desde 2025, durante varios meses se discutió la posibilidad de dejar en manos de Scott Johnston la toma de decisiones de Fly.io
- Como CEO de Docker, Scott atravesó un período difícil que comenzó con una crisis de identidad entre el mercado empresarial y el de desarrolladores, y luego hizo crecer mucho el negocio
- El fundador, accionista de Fly.io y entonces CEO, consideró que para la etapa actual de la empresa el estilo operativo de Scott era más adecuado que el suyo, y junto con el directorio lo convenció
- El fundador permanecerá como asesor y miembro del directorio, participando en discusiones de diseño de producto, mientras Scott se hará cargo de la operación y ejecución del negocio
Financiamiento adicional para la nueva estrategia
- Fly.io no había anunciado nuevas rondas de inversión durante años, pero había levantado una gran cantidad de capital previamente y operaba en un punto en el que, según el plan anterior, no necesitaría más financiamiento
- Como la IA cambió el plan existente, consiguió financiamiento adicional para impulsar la nueva estrategia, pero no reveló el monto ni los términos concretos
- Scott Johnston tratará por separado los detalles de futuras rondas de financiamiento
Elegir uno de dos futuros
- Fly.io prevé que, en pocos años, los agentes determinarán cómo se construye y despliega casi todo el software
- Cree que el software será más personalizado, estará dirigido a audiencias más pequeñas y adoptará formas más flexibles y fluidas
- Este cambio genera entusiasmo y, al mismo tiempo, incomoda a quienes trabajan en la industria
- La empresa tenía dos opciones
- Seguir ampliando y mejorando una plataforma full-stack de aplicaciones con funciones fijas diseñada por humanos
- Perfeccionar un producto adecuado para un futuro cercano centrado en agentes
- Si una startup persigue ambas direcciones al mismo tiempo, le cuesta enfocarse lo suficiente en cualquiera de ellas, por lo que Fly.io eligió el producto centrado en agentes
- Sprites resolvió una decisión de prioridades postergada durante meses, y Scott Johnston asumirá el rol de convertirlo en el negocio central de Fly.io
1 comentarios
Opiniones de Hacker News
La abstracción de Sprites es hermosa, pero en 30 años de carrera como desarrollador nunca había visto un producto de infraestructura con tantos bugs.
Los datos desaparecían constantemente y quedaban en un estado zombi inaccesible; la mitad del sistema informaba que el Sprite estaba bien y la otra mitad lo consideraba muerto, así que ni siquiera se podían cargar snapshots.
Durante el almuerzo, de un día para otro, e incluso mientras trabajaba, desaparecía lo producido; me rendí a las dos semanas y tuve que revisar el historial de la terminal para copiar y rescatar el trabajo desde Sprites muertos.
Parece que más de la mitad de los Sprites que ejecuté tuvieron problemas; el concepto es excelente, así que espero que logren estabilidad.
Sin embargo, en los últimos dos meses parece haberse vuelto mucho más estable.
Hace unos años Fly.io también tenía tantos bugs que era difícil usarlo para casos reales, pero ahora ejecuto algunas cargas de producción con mucha estabilidad; pensé que Sprites seguiría el mismo camino, y de hecho parece estar haciéndolo.
En el sentido de que el CEO la ha gestionado pésimamente, quizá su renuncia sea incluso algo positivo.
Las razones también fueron bugs graves en la interfaz, pérdida de datos y un soporte pésimo.
Dicho eso, durante la prueba no usaron el dominio real de la empresa ni revelaron que eran una compañía Fortune 200, así que eso pudo haber influido en la calidad del soporte.
Como desarrollador de Elixir quería que Fly.io tuviera éxito, pero tuve que irme dos veces porque no lograron encontrar el equilibrio entre ingeniería brillante y estabilidad operativa.
Durante un tiempo, incluso cuando había incidentes globales, la página de estado mostraba todo normal; había que leer los posts del foro para enterarse de los problemas, y la empresa respondía que estaban demasiado ocupados resolviéndolos como para actualizar el estado.
Después empezaron a actualizar la página de estado, pero se repetían situaciones en las que, tras un “incidente en una región específica”, pasaban horas sin novedades.
Cuando lanzaron el soporte pago me suscribí de inmediato, pero la dirección de email que prometía respuestas rápidas casi nunca la revisaba nadie; incluso al reportar incidentes grandes, recién al día siguiente o varios días después respondían “¿qué problema están teniendo?”.
Si esto hubiera sido raro, habría quedado como un problema de atención al cliente, pero durante un tiempo tuvimos incidentes graves casi todos los meses; parecía estabilizarse por un momento y luego volvía a caerse repetidamente.
Al final devolví todos los servicios a self-hosting y, aunque es más engorroso, el uptime mejoró mucho; cuando algo falla, puedo saber directamente la causa, así que es mucho menos doloroso.
Si quieren seguir en el negocio de hosting, deben aceptar la responsabilidad e invertir presupuesto en operaciones; si no, sería mejor que abandonen el hosting y se conviertan en otro HashiCorp.
Que toda la empresa se concentre en Sprites parece como si Fly.io hubiera elegido suicidarse.
Los sandboxes de IA ya tienen mucha competencia y prácticamente se volvieron un commodity; es probable que el nuevo CEO se enfoque en ingresos sacrificando una visión creativa.
Espero estar equivocado.
Los contenedores son desechables y las tareas se pueden volver a ejecutar con facilidad, así que la preservación de datos importa menos; incluso se puede hacer que el agente levante el entorno directamente en bare metal.
Como los agentes pasan la mayor parte del tiempo esperando GPUs, si se aplica deduplicación de memoria entre workloads similares se pueden ejecutar cientos con poco hardware.
AWS ya es una nube para agentes, y con agentes e infraestructura como código (IaC), la complejidad de AWS también se reduce mucho.
Ahora el valor no está en pelear por unos pocos puntos básicos de margen de hardware en la capa de orquestación o de serving de modelos, sino en crear herramientas que ayuden a los agentes a tomar mejores decisiones.
Con los avances recientes de los LLM, no solo las personas sino también empresas y organizaciones están sufriendo una crisis de identidad, y este texto es un buen ejemplo.
Me pregunto si vale la pena seguir construyendo productos o empresas que la IA puede generar de una sola vez.
A la inversa, también tiene el efecto interesante de presionarnos a intentar cosas más grandes y ambiciosas que antes eran imposibles.
Ojalá más gente se meta en áreas como la energía limpia, donde aunque cientos de personas hagan lo mismo, generan un beneficio neto sostenido para la humanidad.
Me pregunto si con Docker realmente quieren decir que hizo crecer explosivamente el negocio, o si lo dicen en el sentido de Boeing, como cuando se le salió una puerta.
También es interesante la evaluación relacionada de Bryan Cantrill: https://news.ycombinator.com/item?id=28460504
Sprites parece más adecuado para un negocio pequeño y estable operado por unos amigos que para una startup financiada por inversión.
Si eres desarrollador, ya puedes resolverlo bastante bien con Docker o Podman.
El enorme mercado nuevo donde hasta la abuela y el abuelo crean apps lo ocuparán servicios como Lovable, y es poco probable que personas no desarrolladoras usen Sprites.
Al final solo podrán captar a una parte de los desarrolladores existentes.
Todos los días aparecen noticias de que OpenCode, Claude Code y similares son un desastre de seguridad; si el aislamiento es tan fácil, me pregunto por qué más desarrolladores no usan contenedores y por qué estos incidentes siguen ocurriendo.
Estoy evitando la programación con agentes porque no quiero abrir el entorno de mi casa a un LLM corporativo remoto solo para escribir código más rápido, pero desde el momento en que hay que analizar muchos archivos fuente a la vez, claramente estoy perdiendo.
Irse inmediatamente después de cambiar el rumbo de toda la empresa hacia Sprites se siente brusco.
Al menos hay que darle al nuevo CEO la oportunidad de jugarse la apuesta definiendo él mismo la dirección.
Dudo que valga la pena apostar el futuro de la empresa a Sprites; el juicio final le corresponde al nuevo CEO.
A largo plazo, es probable que este tipo de entornos de ejecución aislados se integren en Claude Code o Codex, o que las propias empresas de IA los ofrezcan directamente.
Git worktree resuelve un problema parecido, pero con Sprites puedes levantar una instancia rápidamente, ejecutar un servicio y luego entregárselo a un agente de coding para que mejore una funcionalidad.
Puedes ejecutar varios agentes en paralelo y elegir uno de los resultados, sin quedar limitado por la cantidad de puertos ni por la CPU local.
Si además consideramos que la falta de RAM seguirá por un tiempo, en Sprites se pueden ejecutar cientos de agentes.
Lo que Fly.io debe arreglar y en lo que debe enfocarse es la confiabilidad.
Me gustaba la forma en que la app se ejecutaba apenas levantabas un contenedor Docker, pero el servicio se interrumpió varias veces y además era muy caro.
Ahora simplemente uso un VPS.