Montag, 9 Uhr. Ein Entwickler braucht einen Testserver. Er öffnet das Ticketsystem, trägt Hostname, Betriebssystem und Kostenstelle ein und wartet. Einen Tag, manchmal drei. Irgendwann landet die VM in seiner Inbox, konfiguriert nach dem Stand von vor zwei Wochen, weil niemand das Template seitdem angefasst hat.

Der Reflex, dieses Problem mit vorhandenen Werkzeugen zu lösen, ist verständlich. Eine Pipeline in Azure DevOps oder GitHub Actions ist schnell geschrieben. Doch CI/CD-Tools sind für etwas anderes gebaut: Code bauen, testen, deployen. Sie folgen einem Commit, laufen durch und sind fertig. Langlebige Workflows, Retry-Logik und State-Management sind nicht ihr Revier.

Genau diese Lücke füllt Kestra. Das Tool wird seit 2021 von Kestra Technologies entwickelt und ist seit Februar 2022 – im Kern als Open-Source-Projekt unter der Apache-2.0-Lizenz – öffentlich verfügbar. Kommerzielle Enterprise-Funktionen ergänzen den OSS-Kern. Kestra versteht sich als universeller Orchestrator: für Ops-Automatisierung, Data Pipelines, Event-driven Workflows und zunehmend auch für KI-Agenten und -Workflows; alles deklarativ in YAML, alles versionierbar in Git. Dieser Artikel zeigt anhand eines konkreten Beispiels, wie das in der Praxis aussieht: Ein Entwickler oder eine Entwicklerin fordert per Formular eine Hetzner-VM an, Kestra provisioniert sie vollautomatisch per Terraform. Der gesamte Code für Terraform, das Kestra-Setup sowie die Kestra Flows sind im GitHub-Repository des Autors zu finden.

Orchestrierung ist nicht dasselbe wie Automatisierung

Wer zum ersten Mal von Kestra hört, denkt unweigerlich, es handele sich um ein weiteres Tool, das Shell-Skripte in ein hübsches UI verpackt. Das trifft es nicht. Der Unterschied liegt im Konzept: Ein Shell-Skript oder eine CI/CD-Pipeline sind sequenziell: auf Schritt A folgt B, dann C, und am Ende ist der Status entweder fertig oder fehlgeschlagen. Was dazwischen passiert, interessiert das Tool nicht. Kestra hingegen orchestriert: Es kennt den Zustand jedes einzelnen Schritts, kann auf externe Ereignisse warten, Fehler gezielt behandeln, Schritte parallelisieren und einen Workflow nach Stunden oder Tagen an exakt der Stelle fortsetzen, an der er unterbrochen wurde.

Das ist keine rein akademische Unterscheidung. In der Praxis bedeutet es, dass Kestra Workflows abbilden kann, die mit klassischen Pipeline-Tools nicht darstellbar sind: ein Provisionierungs-Job, der wartet, bis ein externes System bereit ist, eine Daten-Pipeline, die bei einem HTTP-Fehler drei Minuten pausiert und es dann erneut versucht, ein Deployment, das erst nach einer manuellen Freigabe weiterläuft. Was andere Tools „Pipeline“ nennen, ist in Kestra ein Flow.

Das Entwicklungsteam hinter dem Projekt positioniert Kestra bewusst für ein breites Einsatzspektrum. Im Vordergrund stehen dabei:

• Ops Automation: Infrastruktur bereitstellen, Cluster provisionieren, wiederkehrende Betriebsaufgaben automatisieren.
• Data Pipelines: Kestra tritt hier in direkten Wettbewerb mit Apache Airflow und Prefect
• Event-driven Workflows: Flows, die auf Webhooks, Queue-Nachrichten oder Dateiänderungen reagieren.
• KI-Workflows: Kestra orchestriert KI-Agenten genauso wie klassische Ops-Tasks.

Die vier Grundbausteine

Kestra kennt vier Konzepte, die Entwickler zunächst verinnerlichen sollten, um den Gesamtansatz des Tools leichter zu verstehen.

Ein Flow ist die oberste Einheit, vergleichbar mit einer Pipeline-Definition, aber mit deutlich mehr Ausdruckskraft. Jeder Flow hat eine ID, einen Namespace zur Strukturierung und eine Liste von Tasks. Er lebt als YAML-Datei in Git und lässt sich darüber versionieren und deployen.

Tasks sind die einzelnen Schritte innerhalb eines Flows. Kestra bringt eine umfassende Bibliothek an eingebauten Task-Typen mit: HTTP-Requests, Dateioperationen, Shell-Kommandos, Container-Ausführung, Schleifen, Bedingungen und Parallelisierung. Tasks können Outputs produzieren, die nachfolgende Tasks als Inputs verwenden. Dadurch entsteht ein nachvollziehbarer Datenfluss zwischen den einzelnen Schritten des Flows.

Trigger definieren, wann ein Flow startet. Zur Auswahl stehen Zeitpläne (Cron), Webhooks, andere Flows als Auslöser oder manuelle Ausführung über das UI. Der manuelle Trigger ist dabei nicht zu unterschätzen: Er öffnet im Kestra-UI automatisch ein Eingabeformular für alle deklarierten Inputs.

Plug-ins erweitern Kestra um externe Integrationen. Das offizielle Plug-in-Ökosystem umfasst unter anderem Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt und Airbyte. Plug-ins sind versionierte JARs, die Kestra beim Start lädt, ohne separates Dependency-Management oder pip install.

Das folgende Listing zeigt einen minimalen Flow:

id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"

Dieser Flow zeigt das Wesentliche: Der Namespace demo strukturiert Flows im UI ähnlich wie Ordner. Der Input message erscheint bei der manuellen Ausführung als Textfeld. Der Task referenziert den Input per Pebble-Template-Syntax {{ inputs.message }}. Dieselbe Syntax funktioniert überall im Flow für Secrets, für Outputs vorheriger Tasks sowie für Metadaten der Execution.

Kein Ersatz, sondern Ergänzung

Die Frage kommt verlässlich: Haben wir nicht schon Azure DevOps? Brauchen wir das wirklich? Die Antwort ist ja und nein. Azure DevOps oder GitHub Actions bleiben für das, was sie können, ungeschlagen: Code kompilieren, Tests ausführen, Container bauen, Artefakte deployen. Wer diese Aufgaben ersetzen will, hat das falsche Problem, denn Kestra setzt an einer anderen Stelle an.

CI/CD bleibt die richtige Schicht für alles, was aus dem Repository kommt: bauen, testen, ausliefern. Viele Betriebsprozesse beginnen jedoch mit einer Anfrage statt mit einem Commit: Eine Umgebung soll entstehen, ein Change muss geprüft, eine Ressource freigegeben oder ein externer Dienst eingebunden werden. Genau dort ergänzt Kestra die vorhandene CI/CD-Landschaft.

Ein konkretes Beispiel: Ein Entwickler will einen Kubernetes-Cluster provisionieren. In einer Azure-DevOps-Pipeline lässt sich das technisch abbilden, mit terraform apply als Skript-Task. Was fehlt, ist alles drumherum: Es gibt kein strukturiertes Eingabeformular für Entwickler und keine saubere Retry-Logik, wenn der Cloud-Provider einmal nicht antwortet. Es gibt auch kein Log, das zeigt, wer wann welche Ressource angefordert hat. Vor allem aber behandelt eine Pipeline Terraform im Stil von „fire and forget“: Skript starten, durchlaufen lassen, auf ein Ergebnis hoffen – was dazwischen passiert, ist nicht greifbar. Kestra kapselt dagegen jede Execution vollständig mit ihren Parametern: State, Logs und Retry-Verhalten sind eindeutig einer konkreten Execution zugeordnet und im UI nachvollziehbar. Schlägt ein Schritt fehl, weiß Kestra, an welcher Stelle, mit welchen Eingaben und in welchem Zustand, und kann gezielt darauf reagieren, statt blind von vorne zu beginnen.

Vergleich mit Airflow und Prefect: Der Blickwinkel ist entscheidend

Welche Alternativen zu Kestra infrage kommen, hängt vom Blickwinkel ab, der sich etwa zwischen Data Engineering und Platform Engineering erheblich unterscheidet. Wer aus dem Data-Engineering-Umfeld kommt, denkt meist zuerst an Apache Airflow, heute ein Top-Level-Projekt der Apache Software Foundation, oder an Prefect, das vom gleichnamigen Unternehmen entwickelt wird. Airflow ist der etablierte Standard für DAG-basierte Daten-Pipelines mit Abhängigkeiten, Scheduling und Retry-Logik. Prefect ist eine modernere Alternative, die mit geringerem Betriebsaufwand und einer schlankeren API punktet. Kestra besetzt denselben Raum, ist aber weniger Python-zentrisch: Flows sind in YAML definiert, Tasks sind Plug-in-Aufrufe, Python-Wissen ist nicht erforderlich. Das macht Kestra vor allem für gemischte Teams zugänglicher.

Im Platform Engineering kommen hingegen ganz andere Werkzeuge zum Einsatz. Verbreitet sind unter anderem Argo Workflows als Kubernetes-nativer Orchestrator, die Ansible Automation Platform für Betriebsaufgaben und Configuration Management oder Terraform Cloud für Infrastructure-as-Code-Workflows. All diese Tools lösen echte Probleme, aber jedes ist fest in seinem Paradigma verankert. Terraform Cloud macht Terraform, Argo macht Kubernetes-Workflows, die Ansible Automation Platform macht Ansible. Kestra gibt sich hier bewusst universeller: Ein Flow kann einen Terraform-Container starten, danach ein PowerShell-Skript ausführen, eine HTTP-API aufrufen und das Ergebnis in Slack melden – in einem einzigen YAML-Flow, ohne dass das Tool Rücksicht auf die darunter liegenden Technologien nehmen müsste.

Aus Entwicklersicht bleiben Azure DevOps und GitHub Actions erste Wahl für die CI/CD-Schicht. Airflow oder Prefect können in datengetriebenen Umgebungen weiter ihren Dienst tun. Kestra ergänzt aber dort, wo keines dieser Tools zu Hause ist: als Orchestrierungsschicht, die heterogene Toollandschaften zusammenhält, gleichzeitig aber auch als Ersatz für einzelne Tools dienen kann.

Lokal testen, im Cluster betreiben

Kestra lässt sich lokal per Docker Compose starten. Die vollständige docker-compose.yml liegt im begleitenden GitHub-Repository. Der Befehl docker compose up -d genügt, danach ist das UI unter sofort erreichbar:

Für den produktiven Betrieb auf Kubernetes gibt es ein offizielles Helm-Chart. Die Komponenten (Server, Scheduler, Executor und Worker) laufen als separate Deployments und lassen sich unabhängig skalieren. Worker übernehmen die eigentliche Task-Ausführung und sind der primäre Skalierungshebel: Mehr parallele Executions bedeuten mehr Worker-Replicas, der Rest der Infrastruktur bleibt stabil. Wer Kestra-Ressourcen (Flows, Namespaces, Secrets, User und Rollen) ebenfalls als Code verwalten will, greift zum offiziellen Terraform-Provider: Er bildet die gesamte Kestra-Konfiguration als Terraform-Ressourcen ab und lässt sich nahtlos in bestehende Infrastructure-as-Code-Pipelines integrieren.

Seit Herbst 2024 kooperieren AMD und Intel in der x86 Ecosystem Advisory Group, auch um sich gegen Konkurrenten wie ARM und RISC-V zu stärken. Nun ist die gemeinsam erarbeitete Spezifikation für neue x86-Prozessorbefehle erschienen, die die Verarbeitung von KI-Algorithmen beschleunigen sollen: Die AI Compute Extensions, kurz „ACE“.

Bei ACE geht es vor allem um Matrix-Multiplikationen mit KI-Datenformaten für das Inferencing mit quantisierten Gewichten.

Konkurrent ARM hat bereits Scalable Matrix Extensions (SME2) spezifiziert, die auf die Scalable Vector Extensions (SVE2) aufbauen. SME-Rechenwerke lassen sich auf unterschiedliche Art in ARM-SoCs integieren. Apple baut SME2 seit dem M4 ein, Qualcomm ab dem Snapdragon X2.

Eng mit AVX verknüpft

Die AI Compute Extensions (ACE) Specification steht in Version 1.15 auf der Website der x86 Ecosystem Advisory Group zum Download bereit. Die Spezifikation beschreibt nur die Befehle, nicht die konkrete Implementierung.

Kommende ACE-Rechenwerke sind eng mit den Advanced Vector Extensions (AVX) gekoppelt und nutzen beispielsweise dieselben Register. Konkret nennt die Spezifikation AVX10. Sie erwähnt zudem die bisher nur von Intel in aktuellen Xeon-Serverprozessoren eingebauten Advanced Matrix Extensions (AMX).

Prozessoren mit ACE-v1-Rechenwerken müssen auch einen bestimmten Teil des Befehlsumfangs von AVX10.2 beherrschen.

Viele KI-Datenformate

ACE v1 beschreibt 11 Datenformate, einige in unterschiedlichen Darstellungen. Mit Daten in diesen Formaten müssen ACE-Rechenwerke nicht nur rechnen können, sondern die Spezifikation legt auch eine Fülle von Formatumwandlungen fest.

NPU-Konkurrenz

Seit 2023 sind x86-Prozessoren mit zusätzlich eingebauter Neural Processing Unit (NPU) im Handel. Die verarbeiten bestimmte Datenformate besonders schnell und effizient, sind aber wenig flexibel und belegen relativ viel Chip-Fläche.

Microsoft macht seit 2024 eine NPU mit einer Leistung von mindestens 40 Billionen INT8-Operationen pro Sekunde (40 Tops) zur Voraussetzung für das Marketing-Label Copilot+. Mittlerweile weicht Microsoft diese Vorgabe auf und ermöglicht auch GPUs. Mit kommenden ACE-tauglichen Prozessoren dürften weitere Änderungen nötig werden.

Nach bisherigen Informationen dürften ACE-v1-kompatible x86-Prozessoren frühestens 2028 erscheinen. Denn bisher haben weder AMD für Zen 6 noch Intel für Nova Lake ACE erwähnt. AMD nennt erst für Zen 7 eine neue „Matrix Engine“, vermutlich ACE-kompatibel.

Hören Sie dazu auch:

(ciw)

Die Eclipse Foundation hat Open VSX in Version 1.0 veröffentlicht. Damit erreicht die Registry für Visual Studio Code Extensions einen stabilen Stand.

Open VSX ist eine Plattform zum Veröffentlichen und Herunterladen von Extensions und Werkzeugen, die kompatibel zu der VS-Code-Extensions-API sind. Einige Entwicklungsumgebungen und Tools können die Extensions integrieren, und manche Entwicklungsumgebungen bauen auf Forks von Visual Studio Code auf.

Das Projekt besteht aus einer Serveranwendung mit einer Datenbank für die Extensions sowie einer Webanwendung und einem Kommandozeilenwerkzeug zum Hoch- und Herunterladen der Erweiterungen.

Deutsche Wurzeln mit Open-Source-Basis

Das deutsche Start-up-Unternehmen TypeFox hatte Open VSX ursprünglich entwickelt und 2021 an die Eclipse Foundation übergeben. Mike Milinkovich, Geschäftsführer der Eclipse Foundation, wollte die Plattform als offene Alternative zum Visual Studio Marketplace betreiben, zumal dieser in den Nutzungsbedingen den Einsatz der Extensions auf Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server sowie nachfolgende Microsoft-Produkte beschränkt.

Die Eclipse Foundation entwickelt Open VSX als Open-Source-Projekt über ein GitHub-Repository. Seit Juni 2023 kümmert sich eine eigene Arbeitsgruppe um den Fortbestand. Im April 2026 startete die Eclipse Foundation eine Initiative, um Bugs und Schwachstellen in Open VSX aufzuspüren.

Stabilität und Security

Version 1.0 setzt vor allem auf Stabilität und Security: Das Release bringt unter anderem einen Read-Only-Modus und TLS-geschützte Redis-Verbindungen. Außerdem spricht der Blogbeitrag zur Veröffentlichung von Open VSX 1.0 von zusätzlichen Maßnahmen für eine verbesserte Sicherheit.

Plattformen, die Erweiterungen für Entwicklungswerkzeuge und Programmiersprachen anbieten, sind ein beliebtes Ziel für Supply-Chain-Attacken. Im Oktober 2025 traf die GlassWorm-Attacke neben Microsofts Marktplatz auch Open VSX. Damals reagierte die Eclipse Foundation zügig mit zusätzlichen Schutzmaßnahmen.

Weitere Details lassen sich der Ankündigung von Open VSX 1.0.0 im Eclipse-Blog entnehmen. Die Eclipse Foundation betreibt die öffentliche Open VSX Registry und bietet zudem eine verwaltete Plattform auf Open-VSX-Basis für Unternehmen und Organisationen als Open VSX Managed Registry an.

(rme)