VSHN an der TalosCon 2026: Warum wir noch einmal von vorne angefangen haben

Am 15. und 16. Oktober kamen im Hotel Okura in Amsterdam über 400 Menschen, die mit Talos Linux arbeiten, zur TalosCon 2026 zusammen. An zwei Tagen standen mehr als 30 Speaker auf der Bühne, mit Live-Demos, Geschichten aus der Praxis und vielen Ideen, die man zu Hause ausprobieren kann – oder gleich in Produktion.

Grosse News von Sidero Labs

Sidero Labs nutzte die Bühne für eine ganze Reihe von Ankündigungen. Die Opening Keynote enthielt ein klares Bekenntnis: Talos Linux, inklusive Talos Hypervisor und seiner Kubernetes- und Container-Funktionalität, bleibt frei und Open Source unter der MPL 2.0. Ausserdem stellte das Team Talos 1.14 vor, das bisher grösste Talos-Release, und zeigte Talos Hypervisor zum ersten Mal öffentlich in einer Live-Demo: Virtuelle Maschinen laufen dabei direkt auf Talos, ohne Kubernetes auf dem Host. Alle Details gibt’s im offiziellen TalosCon-Recap von Sidero Labs.

Eine Konferenz rund um ihre Community

Talos bleibt seiner Community treu, und ein grosser Teil der TalosCon drehte sich um Use Cases aus der Praxis, Open-Source-Tooling und Homelab-Setups. Eines der Tools, das seinen Auftritt auf der Bühne bekam, war TOPF, ein Tool zur Migration und Verwaltung von Talos-Linux-Clustern. TOPF wird von PostFinance entwickelt und als Open Source bereitgestellt – und auch wir bei VSHN setzen es ein.

Eine Geschichte hörte ich unter den Teilnehmenden immer wieder: Talos landete oft in Produktion, weil ein Engineer zuerst im eigenen Homelab gute Erfahrungen damit gemacht hatte. Ehrlich gesagt ist Talos genau so auch bei uns auf den Radar gekommen.

VSHN auf der Main Stage

Mein Kollege Marco De Luca und ich durften den Abschluss-Talk auf der Main Stage halten: “How to Convince Your Board to Drop Everything and Start All Over”. Wir haben erzählt, wie wir bei VSHN eine neue, Talos-basierte Managed Platform aufgebaut haben – und was es brauchte, um alle davon zu überzeugen. Das vollständige Slide Deck ist am Ende dieses Beitrags eingebettet.

OpenShift hat uns bis hierher gebracht

Die Geschichte beginnt mit VSHN Managed OpenShift, auf dem heute ein grosser Teil unserer Kundenplattformen läuft. OpenShift war die richtige Entscheidung, und für viele Kunden ist es das nach wie vor: Security- und RBAC-Defaults, denen Kunden von Anfang an vertrauen, eine Support-Beziehung, auf die sich regulierte Kunden in einem Audit berufen können, und Compliance-Zertifizierungen, die bereits auf die Plattform abgebildet sind.

Das hat aber auch seinen Preis: Lizenzkosten pro Node, unabhängig davon, wie der Node genutzt wird, Upgrade-Fenster, die eher in Wochen als in Stunden gemessen werden, und viel Ballast, den Kunden ausserhalb regulierter Branchen nie verlangt haben.

Eine souveräne Cloud mit Servala

Parallel dazu haben wir begonnen, zusammen mit einem Ökosystem aus Spezialisten eine souveräne Cloud aufzubauen: Servala. Das Ziel ist Unabhängigkeit bei der Infrastruktur, ohne alles von Grund auf neu zu erfinden – Kunden erhalten Souveränität by default, und Provider binden sich über gemeinsame, interoperable APIs an.

Der Aufbau bedeutete eine Reihe von Wetten, und jede hatte ihren eigenen Haken. Gateway API funktionierte gut mit Shared Gateways und Port-Zuweisung pro Instanz, aber der Load Balancer jeder Cloud verhält sich ein bisschen anders. OpenTofu erledigte seinen Job mit einem eigenen Talos-Modul pro Cloud Provider, das sich in vielen Umgebungen wiederverwenden lässt – hört aber bei der VM auf und weiss nichts über Talos selbst. Upgrades übernimmt Tuppr, das sowohl Talos- als auch Kubernetes-Upgrades durchführt, allerdings mussten wir eigene Health Checks ergänzen. Der Cluster-Zugriff funktioniert ohne öffentliche Kubernetes API und ohne Bastion Host, der Zugang läuft stattdessen über das Servala Portal. Und für die Konfiguration liefert TOPF ein Config-Blueprint pro Cloud. Der Haken? Keiner – wir lieben TOPF einfach.

Oder, wie wir es im Talk gesagt haben: Talos war der einfache Teil. Der schwierige Teil war alles drumherum.

Parallel dazu: der Wunsch nach etwas Leichterem

Während Servala Gestalt annahm, tauchte immer wieder eine andere Frage auf. Kunden ausserhalb regulierter Branchen wollten etwas Leichteres, das schneller einsatzbereit ist. Sie brauchten weder das Gewicht von OpenShift noch die Souveränitätsgarantien von Servala. Regulierte Kunden brauchen Compliance, einen Audit Trail und Hochverfügbarkeit – genau dafür ist OpenShift gebaut. Alle anderen brauchen Geschwindigkeit, tiefe Kosten und Einfachheit – und genau diese Plattform fehlte bisher in unserem Katalog.

Die Antwort ist VSHN Managed Talos: derselbe Betrieb wie bei unserer OpenShift-Flotte, für Kunden, die etwas Kleineres und Leichteres brauchen.

Und die Plattform ist nur die halbe Miete. Mit dem VSHN Application Catalog (AppCat) bieten wir auch vollständig gemanagte Services wie PostgreSQL, Redis und Keycloak an. Sie lassen sich mit Kubernetes- und OpenShift-Umgebungen verbinden und über Kubernetes-Ressourcen bestellen – ideal für GitOps- und CI/CD-Workflows.

Warum Talos

Bevor die Wahl auf Talos fiel, haben wir uns die Alternativen genau angeschaut. Managed Kubernetes der Cloud Provider schied aus, weil nicht jeder Partner-Provider eines anbietet und der Betrieb jeweils subtile Unterschiede mit sich bringt. OpenShift, unsere Enterprise-Plattform, wäre für dieses Segment mehr als nötig gewesen. k3s ist eine gute Option, hätte aber bedeutet, darunter ein Betriebssystem zu verwalten. Rancher mit RKE2 brachte einen komplexen Management-Layer mit, und bei Flatcar müsste Kubernetes noch obendrauf installiert werden – und SSH bliebe.

Talos Linux erfüllte die Punkte, auf die es ankam: immutable, per API verwaltet, keine SSH-Angriffsfläche und auf jeder Cloud dieselbe Basis.

Wir haben die Entscheidung als Architecture Decision Record festgehalten, ursprünglich für Servala und dann für VSHN Managed Talos wiederverwendet: Talos Linux auf einfachen VMs bei jedem Provider betreiben und dieselben Tools und Betriebsmuster wiederverwenden. Der Trade-off: Wir betreiben mehr von der Infrastruktur selbst – und gewinnen dafür Kontrolle, Konsistenz, planbare Kosten und eine kleinere Angriffsfläche.

Lessons learned

Zum Schluss haben Marco und ich drei Dinge genannt, die wir unserem früheren Ich sagen würden. Erstens: Unterschiedliche Bedürfnisse mit unterschiedlichen Produkten bedienen – eine Plattform muss nicht für jeden Kunden passen. Zweitens: Die Entscheidung aufschreiben, auch das, wozu man Nein gesagt hat. Und drittens: Den Sprung wagen, denn man weiss es nie, bevor man es ausprobiert hat.

Es geht nicht darum, sich für die eine oder andere Distribution zu entscheiden. Es geht um den Kunden und darum, seinen sich ständig weiterentwickelnden Use Case abzudecken.

Die Aufzeichnung des Talks

Die Aufzeichnung unseres Talks ist bald auf dem YouTube-Kanal von Sidero Labs verfügbar. Bis dahin – und wenn du genauer wissen möchtest, wie wir Talos betreiben, inklusive der Architekturentscheidungen dahinter – schau auf kb.vshn.ch/talos vorbei.

Ein grosses Dankeschön an Sidero Labs und alle, die die TalosCon 2026 zu einem so inspirierenden Event gemacht haben. Bis zum nächsten Mal!