- Trotz starker Geschäftszahlen geriet Fly.ios geschäftliche Identität ins Wanken. Das Unternehmen nahm zusätzliche Mittel auf, übergab die Führung an den ehemaligen Docker-CEO Scott Johnston und macht Sprites zum Kerngeschäft
- Da KI es praktisch jedem ermöglicht, maßgeschneiderte Software zu erstellen, reichen eine Public Cloud mit Deployment nahe am Nutzer und Komfort für menschliche Entwickler allein kaum noch zur Differenzierung aus
- Sprites sind Computer für Agents, die bei Bedarf zu Hunderten oder Tausenden erstellt und lange betrieben werden können. Jeder bietet 100 GB persistenten Speicher und nutzungsbasierte Abrechnung, die im Leerlauf stoppt
- Die neuen Sprites erhalten mit dem Sprite Block Device schnellere und zuverlässigere Storage-Funktionen, Disk-Forking sowie Connectors, die externe Systeme aufrufen, ohne Zugangsdaten offenzulegen
- Fly.io verfolgt nicht gleichzeitig eine von Menschen entworfene Plattform für Anwendungen mit festem Funktionsumfang und eine agentenzentrierte Zukunft, sondern konzentriert sich auf Letztere. Fly Machines und bestehende PaaS-Funktionen bleiben jedoch erhalten
Identitätskrise trotz starker Geschäftszahlen
- Theo Browne bewertete Fly.io in seiner Einschätzung zu den besten Orten zum Hosten neuer Anwendungen im Jahr 2026 positiv, sagte aber auch, dass er sich bei keinem der von ihm beobachteten Anbieter weniger sicher sei, ob er bis Jahresende noch bestehen werde
- Zu diesem Zeitpunkt verzeichnete Fly.io weiterhin starke Quartalsergebnisse, darunter die besten Finanzzahlen in der Unternehmensgeschichte. Die Identitätsfrage, was das Unternehmen bauen und wohin es gehen sollte, war jedoch ungelöst
- Fly.io nahm erhebliche zusätzliche Mittel auf, veröffentlichte eine neue Version von Sprites, bündelt darauf die Kräfte des Unternehmens und ernannte Scott Johnston zum CEO
Die Annahmen hinter dem bisherigen Product-Market-Fit haben sich geändert
- Fly.io ging von zwei Prinzipien aus
- Internetanwendungen werden schneller, je näher sie an den Nutzern bereitgestellt werden
- Statt komplexer Cloud-Infrastruktur sollten Entwickler zugleich die Flexibilität von AWS und die Benutzerfreundlichkeit von Heroku erhalten
- Beide Prinzipien bleiben wichtig, sind aber nicht mehr so ausschlaggebend wie früher, weil KI die Softwareentwicklung verändert
- Coding-Agents lediglich wie intelligentere Compiler in den bestehenden Entwicklungsprozess zu integrieren, erfasst das Ausmaß der Veränderung nur unzureichend
- Vor dem Aufkommen von Tabellenkalkulationen mussten Aufgaben, die heute einem Excel-Dokument entsprechen, noch Programme sein, die von Programmierern erstellt wurden. Formeln in Tabellenkalkulationen machten jedoch unzählige Fachanwender zu Programmierern
- KI löst einen noch größeren Wandel aus und bewegt sich in Richtung einer Welt, in der fast jeder fast jede Art von Programm erstellen kann
- Herkömmliche Public Clouds wurden dafür entworfen, Anwendungen mit festem Funktionsumfang, strengen Standards und CI/CD-Prozessen an Millionen von Menschen auszuliefern
- Auch künftig wird es Programme für Millionen von Nutzern geben, aber sie sind möglicherweise nicht die typische Form – so wie eine Tabelle, die von Millionen gelesen wird, nicht die typische Tabelle ist
- Weiter auf ein Public-Cloud-Design im Stil von 2020 zu setzen, entspricht einer Wette gegen die Verbreitung von personalisierter und adaptiver Software
- Fly.io entscheidet sich für eine Welt, in der Freunde und Familie nicht auf Entwickler warten müssen, sondern mit Computern selbst erledigen können, was sie möchten
Die Anforderungen von Agents statt menschlicher Developer Experience
- Das Problem, dass Cloud-Infrastruktur für Entwickler schwierig ist, besteht weiterhin. Da Agents jedoch Arbeit übernehmen, verliert eine sorgfältig gestaltete Developer Experience für Menschen an Bedeutung
- Für Agents, die in expliziten Umgebungen besser funktionieren, können stark meinungsbehaftete Defaults und kuratierte Developer Experience sogar nachteilig sein
- Menschen beginnen, Agents einzusetzen, statt Dokumentation zu lesen und eine neue CLI durch Versuch und Irrtum zu erlernen
- Ein Agent kann die Bitte, eine lokal erstellte Website auf Fly.io bereitzustellen, in einem Schritt erledigen – er kann aber auch ein Deployment auf AWS in einem Schritt erledigen, wodurch reine Benutzerfreundlichkeit als Differenzierungsmerkmal schwieriger wird
- Nachdem Fly.io beobachtet hatte, dass seine am schnellsten wachsenden Kunden Roboter sind, begann das Unternehmen nicht einfach, bestehende Produkte für Agents neu zu deuten, sondern suchte nach der Umgebung, die Agents tatsächlich wollen
Der Computer, den Agents wollen
- Coding-Agents sind grundsätzlich dafür gebaut, auf der Workstation eines Entwicklers zu laufen
- Selbst wenn eine Sandbox vertrauenswürdig ist: Läuft sie auf einem physischen Laptop, stoppt die Arbeit, sobald der Deckel geschlossen wird. Daher verlagern Nutzer Agent-Sandboxes letztlich in die Cloud
- Herkömmliche Public-Cloud-Server verlangen für Agent-Aufgaben zu große Festlegungen
- Sie müssen kurzlebiger sein als traditionelle Pet-Server oder Cattle-Server
- Sie müssen bei Bedarf erstellt, nur so lange wie nötig betrieben und kostengünstig genutzt werden können
- Sprites sind halb-wegwerfbare Computer, die auf diese Anforderungen zugeschnitten sind
- Hunderte oder Tausende lassen sich schnell erstellen
- Jeder Sprite erhält 100 GB persistenten Speicher
- Die Abrechnung erfolgt nach Nutzung, stoppt aber, wenn nichts passiert; Leerlauf wird selbstständig erkannt
- Sie können Anwendungen hosten und über das Internet mit Kollegen geteilt werden
- Die Branche konzentriert sich auf Sandboxes, doch was Agents brauchen, ist keine Sandbox, sondern ein Computer mit Persistenz und praktischem Nutzen
- Man kann Sprites sofort erstellen und selbst nutzen
Sprites werden zum Zentrum des Unternehmens
- Die ersten Sprites waren ein Projekt eines kleinen informellen Teams innerhalb von Fly.io und wurden nicht einmal auf der Hauptwebsite von Fly.io gehostet
- Künftig werden Computer für Agents (Computers for Agents) zum zentralen Fokus des Unternehmens, und Sprites sind nicht mehr nur ein Projekt weniger Mitarbeitender
- Fly Machines und bestehende Platform-as-a-Service-Funktionen (PaaS) werden nicht eingestellt, sondern weiter angeboten
- Die neuen Sprites verbessern Skalierung und Orchestrierung und führen zwei wichtige Subsysteme ein, um die angestrebte Funktionspalette zu vervollständigen
Sprite Block Device und Disk-Forking
- Der bisherige Storage-Stack basierte auf JuiceFS und war mit Litestream verbunden
- Das von Ben Johnson und Tim Newsham von Grund auf neu aufgebaute Sprite Block Device (SBD) ist schneller und zuverlässiger als zuvor und behält zugleich Funktionen für sofortige Checkpoints und Wiederherstellung bei
- Mit Drive-Forking, einer zentralen Erweiterung von SBD, lässt sich ein einzelner Template-Sprite erstellen und anschließend effizient millionenfach replizieren
Connectors verhindern die Offenlegung von Zugangsdaten
- Connectors basieren auf tokenisierten Tokens, die zum Schutz der Kernplattform von Fly.io entwickelt wurden
- Sie sind so konzipiert, dass ein Sprite authentifizierte Anfragen an andere Systeme senden kann, ohne dem Agent direkt Zugangsdaten bereitzustellen, die abfließen könnten
- Sie sind bequemer zu nutzen als die manuelle Verwaltung von Accounts und API-Keys
- Die Replikationsfunktionen von SBD und Connectors gehören zu den am häufigsten von Kunden gewünschten Funktionen und sind auch ein Grund dafür, dass viele Agent-Unternehmen Fly Machines weiter nutzten, selbst nachdem dedizierte Agent-Produkte erschienen waren
- Sofern keine technologischen Veränderungen auftreten, die noch ungewohnter sind als Transformer-Modelle, geht Fly.io davon aus, dass Sprites gut zu künftigen Kunden und zu einem beträchtlichen Teil der bestehenden Kunden passen, und bietet eine neue Beta an
Rücktritt des Gründer-CEOs
- In den ersten acht Jahren seit der Gründung wurde Fly.io als experimentelle Organisation auf der Suche nach Product-Market-Fit betrieben
- Das Unternehmen probierte Dutzende Dinge aus, darunter nicht gemanagtes Postgres, ein globales CDN und User-Mode-WireGuard
- Es baute eine Bottom-up-Engineering-Organisation auf, vermied Produkt-Roadmaps und stellte ein vollständig remote arbeitendes Team in mehr als zwölf Ländern zusammen
- Einige Experimente waren erfolgreich, andere wurden zu Lerngelegenheiten. In der aktuellen Phase von Fly.io sind solche wissenschaftlichen Projekte jedoch nicht mehr nötig
- Der Gründer kam zu dem Schluss, dass er die meisten Stärken, die er als CEO einbringen konnte, ausgeschöpft hatte, und trat zurück
Scott Johnston wird CEO
- Seit 2025 wurde über mehrere Monate hinweg besprochen, Scott Johnston die Entscheidungen bei Fly.io zu übertragen
- Scott führte Docker als CEO durch eine schwierige Phase, die aus einer Identitätskrise zwischen Enterprise-Markt und Developer-Markt entstand, und ließ das Geschäft anschließend stark wachsen
- Der Gründer, Aktionär und damalige CEO von Fly.io, kam zu dem Schluss, dass Scotts Arbeitsweise besser zur aktuellen Unternehmensphase passt als seine eigene, und überzeugte ihn gemeinsam mit dem Board
- Der Gründer bleibt als Berater und Board-Mitglied beteiligt und nimmt an Produktdesign-Diskussionen teil, während Scott Betrieb und Umsetzung des Geschäfts übernimmt
Zusätzliche Mittel für die neue Strategie
- Fly.io hat seit Jahren keine neue Finanzierungsrunde angekündigt, arbeitete aber nach einer früheren großen Finanzierung an der Schwelle, nach der bestehenden Planung keine weitere Finanzierung zu benötigen
- Da KI die bisherigen Pläne verändert hat, nahm das Unternehmen zusätzliche Mittel auf, um die neue Strategie umzusetzen; konkrete Höhe und Konditionen werden nicht offengelegt
- Scott Johnston wird die künftige Finanzierung gesondert behandeln
Entscheidung für eine von zwei Zukünften
- Fly.io geht davon aus, dass Agents innerhalb weniger Jahre bestimmen werden, wie fast jede Software gebaut und bereitgestellt wird
- Software werde persönlicher, Zielgruppen würden kleiner, und Formen würden flexibler und fließender
- Diese Veränderung weckt Erwartungen, macht aber zugleich viele Menschen in der Branche unruhig
- Das Unternehmen hatte zwei Optionen
- Die von Menschen entworfene Full-Stack-Plattform für Anwendungen mit festem Funktionsumfang weiter ausbauen und verbessern
- Ein Produkt präzise fertigstellen, das zur nahen agentenzentrierten Zukunft passt
- Wenn ein Startup beide Richtungen gleichzeitig verfolgt, kann es sich auf keine ausreichend konzentrieren. Deshalb entschied sich Fly.io für ein agentenzentriertes Produkt
- Sprites lösten die seit Monaten aufgeschobene Priorisierungsentscheidung, und Scott Johnston übernimmt die Aufgabe, sie zum Kerngeschäft von Fly.io zu machen
1 Kommentare
Hacker-News-Kommentare
Die Abstraktion von Sprites ist schön, aber in 30 Jahren Entwicklungserfahrung habe ich noch nie ein Infrastrukturprodukt mit so vielen Bugs erlebt
Daten verschwanden ständig und gerieten in einen Zombie-Zustand ohne Verbindungsmöglichkeit; die Hälfte des Systems meldete, der Sprite sei in Ordnung, die andere hielt ihn für tot, sodass nicht einmal Snapshots geladen werden konnten
Über Mittag oder über Nacht, sogar während der Arbeit, verschwanden Ergebnisse, sodass ich nach zwei Wochen aufgegeben habe und im Terminal-Verlauf wühlen musste, um meine Arbeit aus einem toten Sprite herauszukopieren und zu retten
Bei mehr als der Hälfte der gestarteten Sprites scheinen Probleme aufgetreten zu sein; das Konzept ist großartig, also hoffe ich, dass sie Stabilität in den Griff bekommen
In den letzten etwa zwei Monaten scheint es aber deutlich stabiler geworden zu sein
Auch Fly.io selbst war vor ein paar Jahren so fehlerhaft, dass es sich kaum produktiv nutzen ließ, aber heute betreibe ich einige Produktions-Workloads dort sehr stabil; deshalb dachte ich, dass Sprites denselben Weg gehen würden, und genau das scheint nun zu passieren
Da der CEO das Unternehmen miserabel geführt hat, wäre ein Rücktritt vielleicht sogar besser
Der Grund waren schwere Interface-Bugs, Datenverlust und miserabler Support
Allerdings wurde in der Testphase nicht die echte Unternehmensdomain verwendet und auch nicht offengelegt, dass es sich um ein Fortune-200-Unternehmen handelte, was die Support-Qualität beeinflusst haben könnte
Als Elixir-Entwickler habe ich gehofft, dass Fly.io Erfolg hat, musste aber zweimal weggehen, weil sie kein Gleichgewicht zwischen beeindruckendem Engineering und betrieblicher Stabilität fanden
Eine Zeit lang gab es globale Ausfälle, während auf der Statusseite überall alles als normal angezeigt wurde; von den Ausfällen erfuhr man nur über Forenbeiträge, und das Unternehmen antwortete, man sei mit der Behebung zu beschäftigt gewesen, um den Status zu aktualisieren
Später begannen sie zwar, die Statusseite zu aktualisieren, aber nach „Ausfall in einer bestimmten Region“ kam stundenlang wieder keine weitere Information
Sobald bezahlter Support verfügbar war, habe ich ihn sofort gebucht, aber die E-Mail-Adresse mit versprochener schneller Antwort wurde meist von niemandem überwacht, und selbst wenn man einen großen Ausfall meldete, kam erst am nächsten Tag oder Tage später die Antwort: „Welches Problem liegt vor?“
Wäre das selten passiert, wäre es nur ein Kundensupportproblem gewesen, aber zeitweise gab es fast jeden Monat schwere Ausfälle, dann wirkte es kurz stabiler und brach anschließend wiederholt erneut zusammen
Am Ende habe ich alle Dienste wieder auf Self-Hosting zurückgeführt; das ist zwar umständlicher, aber die Verfügbarkeit ist deutlich besser, und wenn es einen Ausfall gibt, kann ich die Ursache selbst erkennen, was viel weniger schmerzhaft ist
Wenn man das Hosting-Geschäft weiterführen will, muss man Verantwortung übernehmen und in den Betrieb investieren; wenn nicht, sollte man das Hosting lieber aufgeben und stattdessen ein weiteres HashiCorp werden
Das ganze Unternehmen auf Sprites auszurichten, wirkt, als hätte Fly.io Selbstmord gewählt
AI-Sandboxes sind bereits stark umkämpft und praktisch zu einer Commodity geworden, und der neue CEO dürfte eher auf Umsatz als auf eine kreative Vision setzen
Hoffentlich ist das eine Fehleinschätzung
Container sind wegwerfbar und Jobs lassen sich leicht erneut ausführen, daher ist Datenerhalt weniger wichtig, und man könnte Agenten die Umgebung auch direkt auf Bare Metal starten lassen
Agenten warten meist auf GPUs; wendet man auf ähnliche Workloads Memory Deduplication an, kann man Hunderte davon mit wenig Hardware ausführen
AWS ist bereits die Cloud für Agenten, und mit Agenten und Infrastructure as Code (IaC) wird auch die Komplexität von AWS stark reduziert
Der Wert liegt jetzt nicht mehr darin, sich um Orchestrierung oder ein paar Basispunkte Hardware-Marge in der Model-Serving-Schicht zu streiten, sondern darin, Tools zu bauen, die Agenten helfen, bessere Entscheidungen zu treffen
Durch die jüngsten Fortschritte bei LLMs erleben nicht nur Einzelpersonen, sondern auch Unternehmen und Organisationen eine Identitätskrise, und dieser Text ist ein gutes Beispiel dafür
Es ist fraglich, ob es sich noch lohnt, weiter Produkte oder Firmen aufzubauen, die AI auf einmal erzeugen kann
Umgekehrt gibt es auch den interessanten Effekt, dass sie dazu drängt, größere und ambitioniertere Dinge anzugehen, die zuvor unmöglich waren
Hoffentlich wenden sich mehr Menschen Bereichen wie sauberer Energie zu, in denen selbst Hunderte, die dasselbe tun, der Menschheit dauerhaft einen Nettogewinn bringen
Ich frage mich, ob gemeint ist, dass Docker das Geschäft wirklich explosiv wachsen ließ, oder eher im Sinne von Boeing, wo die Tür herausflog
Auch Bryan Cantrills Einschätzung dazu ist interessant: https://news.ycombinator.com/item?id=28460504
Sprites wirken eher passend für ein kleines, stabiles Geschäft, das von ein paar Freunden betrieben wird, als für ein VC-finanziertes Startup
Als Entwickler kann man das bereits mit Docker oder Podman gut genug lösen
Den riesigen neuen Markt, in dem sogar Oma und Opa Apps bauen, werden Dienste wie Lovable besetzen, und es ist unwahrscheinlich, dass Nicht-Entwickler Sprites verwenden
Am Ende kann man also nur einen Teil der bestehenden Entwickler gewinnen
Täglich hört man, dass OpenCode oder Claude Code und Ähnliches ein Sicherheitsdesaster seien; wenn Isolation so einfach wäre, fragt man sich, warum nicht mehr Entwickler Container verwenden und warum solche Vorfälle weiter passieren
Ich meide Agent Coding, weil ich meine häusliche Umgebung nicht für ein Remote-Unternehmens-LLM öffnen will, nur um schneller Code zu schreiben, aber sobald mehrere Quelldateien gleichzeitig analysiert werden müssen, bin ich klar im Nachteil
Direkt nach der Umstellung der gesamten Firmenausrichtung auf Sprites zu gehen, wirkt ziemlich hart
Man sollte dem neuen CEO zumindest die Chance geben, die Richtung selbst festzulegen und es darauf ankommen zu lassen
Ob man die Zukunft des Unternehmens wirklich auf Sprites setzen sollte, ist fraglich; die endgültige Entscheidung liegt beim neuen CEO
Langfristig werden solche isolierten Ausführungsumgebungen wahrscheinlich in Claude Code oder Codex integriert oder direkt von AI-Unternehmen angeboten
Git worktree löst ein ähnliches Problem, aber mit Sprites kann man schnell eine Instanz hochfahren, einen Dienst starten und ihn dann einem Coding-Agenten übergeben, damit dieser die Funktionalität verbessert
Man kann mehrere Agenten parallel laufen lassen und anschließend eines der Ergebnisse auswählen, ohne durch Portanzahl oder lokale CPU beschränkt zu sein
Wenn man zudem bedenkt, dass RAM-Knappheit wohl noch eine Weile bleibt, kann man auf Sprites Hunderte von Agenten ausführen
Was Fly.io reparieren und worauf es sich konzentrieren muss, ist Zuverlässigkeit
Mir gefiel, dass beim Starten eines Docker-Containers die App sofort lief, aber der Dienst hatte mehrere Ausfälle und war außerdem sehr teuer
Inzwischen nutze ich einfach einen VPS