Auf dem Ubuntu Summit 26.04 in London hat Canonical mit »Workshop« ein Werkzeug veröffentlicht, das Entwicklungsumgebungen aus einer einzigen YAML-Datei aufbaut, reproduzierbar, isoliert und ausdrücklich auf den Betrieb von KI-Agenten zugeschnitten. Unter der Haube arbeiten unprivilegierte LXD-Container, ZFS-Snapshots und ein Schnittstellenmodell, das verdächtig vertraut an Snap erinnert.
Wer schon einmal an einem komplexen KI- oder Machine-Learning-Projekt gearbeitet hat, kennt das Muster: Bevor die erste Zeile produktiven Codes entsteht, vergehen Stunden mit dem Einrichten von Treibern, Bibliotheken, Runtimes und Werkzeugketten. Und kaum läuft die Umgebung, bricht sie beim nächsten System-Update wieder weg, oder lässt sich auf der Maschine des Kollegen nicht eins zu eins nachbauen. Genau an diesem Reibungspunkt setzt »Workshop« an, das Canonical am 27. Mai 2026 zum Auftakt des Ubuntu Summit 26.04 vorgestellt hat. Vorgetragen hat das Projekt Dmitry Lyfar, Engineering Manager bei Canonical, der seit geraumer Zeit zusammen mit weiteren Canonical-Engineers daran arbeitet.
Bemerkenswert ist die Entstehungsgeschichte, und sie deckt sich mit der Darstellung, die Canonical-Gründer Mark Shuttleworth bereits in der Eröffnungs-Keynote des Summits gegeben hatte (siehe Teil 1 dieser Serie). Begonnen hat das Team die Arbeit, bevor agentische Werkzeuge zum Massenphänomen wurden. Workshop sei, so Shuttleworth, gar nicht für Agenten erdacht worden, sondern für eine Welt, in der proprietäre und freie Software in derselben Werkzeugkette laufen. Sein Beispiel: Wer eine spannende, aber geschlossene Bibliothek als Root auf dem eigenen Rechner ausführt, übergibt faktisch die Kontrolle an deren Hersteller und an alle Beteiligten in dessen Build-Pipeline. Dieses Szenario verlange seit Jahren nach einer sauberen Sandbox, KI-Agenten seien lediglich der jüngste Anwendungsfall. Lyfar bestätigte diese Lesart auf der Bühne: Der Ansatz habe sich eher zufällig als gute Passform für Agenten erwiesen, weil ein Container, der ein Entwicklungssystem sauber kapselt, ohnehin der naheliegende Ort ist, um einem autonom agierenden Werkzeug klare Grenzen zu setzen.
Drei Versprechen
Lyfar fasst Workshop in drei Eigenschaften zusammen: Eine Workshop-Umgebung sei composable, secure und fast, also zusammensetzbar, sicher und schnell. Technisch ist eine solche Umgebung ein LXD-Container, der zur Laufzeit aus einzelnen Bausteinen erzeugt wird. Diese Bausteine heißen SDKs, und sie sind das konzeptionelle Herzstück des gesamten Projekts.
Ein SDK ist dabei nicht zwangsläufig das, was Entwickler sonst unter dem Begriff verstehen. Bei Workshop bezeichnet ein SDK eine eigenständige, in sich abgeschlossene Komponente, die einen Teil der Entwicklungsumgebung installiert und konfiguriert. Setzt man mehrere dieser Komponenten zusammen, ergibt sich die vollständige Definition einer Arbeitsumgebung. In Lyfars Demo lief etwa ein Container mit Jupyter, ComfyUI und einem ROCm-SDK. Ein spezielles System-SDK wird in jeden Workshop-Container automatisch eingespielt; es vermittelt zwischen Host und Container und stellt die Grundverbindung her.
Zusammensetzbar: SDKs aus dem Store
Die SDKs beziehen Anwender aus dem SDK Store, dem Pendant zum Snap Store. Publisher veröffentlichen ihre SDKs dort, und über eine aus der Snap-Welt bekannte Channel-Semantik landen sie schließlich im Workshop und bauen die Umgebung von Grund auf zusammen. Zum Start stellt Canonical rund 20 Referenz-SDKs bereit. Das Spektrum reicht von Werkzeugketten wie UV, Flutter oder Go über Agenten-Umgebungen und ML/KI-Frameworks bis hin zu Spezialfällen wie Echtzeitbetriebssystemen und ROS 2 für die Robotik. Hardwarenahe SDKs von Intel, AMD und NVIDIA, darunter ROCm, CUDA und OpenVINO, lassen sich ebenso einbinden wie Agenten-Werkzeuge à la OpenCode oder Ollama.
Composable: der SDK Store. Aus einzelnen, von Publishern bereitgestellten SDKs (mit den Bestandteilen Meta, Interfaces, Hooks, Content) setzt der Workshop-Container die Umgebung zusammen. Quelle: Ubuntu Summit 26.04, Vortrag Dmitry Lyfar (Canonical), Folie 130.
Jedes SDK besteht aus vier Teilen. Die Metadaten legen Name, Basis, Architektur, Lizenz und weitere für Store und Konsumenten relevante Felder fest (auf der Demo-Folie etwa name: rocm, base: ubuntu@24.04, architecture: amd64, license: MIT). Die Interfaces drücken aus, welche Ressourcen ein SDK benötigt oder selbst bereitstellt, dazu später mehr. Die Hooks sind im Kern Skripte, die zur Laufzeit eigene Logik ausführen. Und der Content schließlich umfasst Binärdateien, systemd-Units, Dienste und Konfigurationen, die das SDK in den Container mitbringt.
Die Hooks durchlaufen beim Start eine feste Abfolge. setup-base greift, sobald das Basis-Image steht, aber noch keine Schnittstellen verbunden sind, die Gelegenheit, die Basis vorzubereiten. setup-project läuft, wenn das Projektverzeichnis unter /project eingehängt und die Interfaces verbunden sind, hier findet die projektspezifische Logik ihren Platz. Eine abschließende, leichtgewichtige Prüfung (check-health) lässt das SDK selbst entscheiden, ob seine Installation im Workshop gelungen ist. Verneint es das, rollt Workshop die Änderung automatisch zurück.
Sicher: unprivilegierte Container und das Plug-Slot-Modell
Beim Stichwort Sicherheit meint Canonical zweierlei: einen stark eingeschränkten Zugriff auf Host-Ressourcen aus dem Container heraus, und einen disziplinierten, einheitlichen Weg, diesen Zugriff bei Bedarf zu gewähren. Ein Workshop startet grundsätzlich als unprivilegierter LXD-Container, der auf Prozess-, Dateisystem- und Netzwerkebene vom Host isoliert ist, sich aber den Kernel mit ihm teilt.
Secure: vordefinierte Richtlinien für Interfaces. Ein angefordertes Desktop- oder SSH-Agent-Interface verlangt eine manuelle Bestätigung durch den Nutzer. Quelle: Ubuntu Summit 26.04, Vortrag Dmitry Lyfar (Canonical), Folie 132.
Den Zugriff auf Ressourcen regelt ein Interface-System, das Canonical nach eigener Darstellung direkt aus snapd übernommen und für das Workshop-Szenario angepasst hat. Es funktioniert nach dem aus Snaps bekannten Plug-Slot-Prinzip: Deklariert ein SDK einen Plug, will es eine Ressource konsumieren; deklariert es einen Slot, stellt es eine Ressource bereit. Benötigt etwa ein ROCm-SDK Zugriff auf die GPU, so reicht das System-SDK diese GPU als Slot an den Host weiter. Erst wenn Plug und Slot verbunden sind, steht die Ressource im Container zur Verfügung. Dasselbe Prinzip trägt für Mounts, Tunnel, Desktop, SSH-Agent, Kamera oder maßgeschneiderte Geräte. Je nach hinterlegter Richtlinie verbindet Workshop eine Schnittstelle automatisch oder verlangt eine manuelle Bestätigung durch den Nutzer, etwa bei Desktop- oder SSH-Agent-Zugriff.
Dieses Modell zeigt seine Stärke genau dort, wo agentische Werkzeuge ins Spiel kommen. Läuft ein Agent im Container und fordert eine Ressource an, entscheidet der Mensch, ob GPU, NPU, Desktop oder etwas anderes freigegeben wird. Wie real die Kapselung ist, führte ein Demo-Moment vor Augen: Per opencode run ließ Lyfar den Agenten seine eigene Umgebung beschreiben, der charakterisierte sich prompt als Linux-Container (keine VM) mit eingeschränktem Ressourcenzugriff und /project als eingehängtem Git-Verzeichnis. Anschließend trennte Lyfar mit workshop disconnect demo/rocm:gpu die GPU vom Container, woraufhin amd-smi darin nur noch leere Felder meldete. Den zugrunde liegenden Zielkonflikt formulierte Lyfar prägnant: Komfort für Entwickler dürfe nicht zugleich Bequemlichkeit für KI-Agenten bedeuten. Workshop löse diese Spannung über die strikte Durchsetzung von Zugriffskontrollen, während unprivilegierte Voreinstellungen die Fähigkeiten der Workloads von vornherein begrenzten.
Schnell: ZFS-Snapshots und Klone
Das dritte Versprechen, Geschwindigkeit, beruht maßgeblich auf ZFS-Snapshots und -Klonen. Bei jeder SDK-Installation legt Workshop einen Snapshot an. Aus einem Stapel solcher Snapshots lässt sich ein zweiter Workshop, der einen Teil davon wiederverwendet, nahezu augenblicklich aus dem bestehenden Stand wiederherstellen, statt ihn von Grund auf neu zu bauen. Das ist kein Selbstzweck: Canonical erwartet, dass ein Projekt je nach Branch oder Variante der Entwicklungsumgebung mehrere Workshops parallel nutzt. Diese sollen sich nicht nur schnell starten und auffrischen lassen, sondern auch platzsparend sein, denn manche SDKs belegen erheblichen Festplattenplatz, und genau das fängt der Snapshot-Mechanismus ab.
Fast: ZFS-Snapshots und -Klone. Ein Workshop mit CUDA entsteht als nahezu sofortiger ZFS-Klon aus den bereits vorhandenen Snapshots (base image, system-, cuda-, ollama-SDK). Quelle: Ubuntu Summit 26.04, Vortrag Dmitry Lyfar (Canonical), Folie 135.
Die Praxis: launch und refresh
So technisch das Fundament klingt, so schlank ist der Arbeitsalltag. Eine Workshop-Definition steckt in einer Datei namens workshop.yaml, die üblicherweise im Projektverzeichnis liegt. Wer das Repository klont und workshop launch ausführt, erhält die fertige Umgebung: mit installierten SDKs, verbundenen Interfaces und dem unter /project eingehängten Projektordner. Unabhängig davon, wie komplex der DevStack ist, lautet das zentrale Versprechen: ein Kommando genügt.
Die Definition selbst bleibt überschaubar. Sie beginnt mit Name und Basis, wählbar ist jede derzeit unterstützte LTS-Basis, und listet darunter die gewünschten SDKs samt Channel auf:
name: dev
base: ubuntu@24.04
sdks:
- name: opencode
- name: rocm
channel: 7.1/stable
- name: go
channel: 1.26/stableBeim Start zieht Workshop die SDKs aus dem Store, installiert sie in den Container, führt die Hooks aus, aktiviert die Interfaces und bringt die Umgebung zum Laufen. Im Beispiel oben käme ROCm aus dem Channel 7.1/stable und damit ROCm 7.1 auf Ubuntu 24.04; opencode ohne Channel-Angabe folgt dem Default. Welche konkrete Architektur, Basis und Revision hinter einem Channel steht, löst Workshop transparent auf, der Channel 24/stable eines Node-SDK etwa verweist auf die 24er-LTS-Spur, abhängig von Basis (24.04 oder 22.04) und Architektur (amd64 oder arm64) landet dann das passende Artefakt im Container.
Das zweite zentrale Kommando ist workshop refresh. Ändert sich etwas an der Definition, wird ROCm etwa von 7.1/stable auf 7.2/stable gehoben, aktualisiert Workshop den laufenden Container inkrementell, statt ihn komplett neu aufzusetzen. Dank der ZFS-Snapshots stellt es den Workshop aus dem passenden Zwischenstand wieder her, installiert die neue Version, verbindet die Interfaces neu und stellt, ein wichtiges Detail, den vom jeweiligen SDK definierten Zustand wieder her. Bei einem Agenten-SDK können das beispielsweise laufende Sitzungen oder hinterlegte Zugangsdaten sein, beim Go-SDK etwa der Modul-Cache.
Im Wesentlichen, so Lyfar, bedient man Workshops mit genau diesen beiden Kommandos: launch und refresh.
Wenn etwas schiefgeht
Reibungslos läuft das in der Realität nicht immer, und Workshop bringt für solche Fälle zwei Betriebsmodi mit. Im transaktionalen Modus versucht refresh, den laufenden Container an die geänderte Definition anzugleichen. Misslingt das, etwa weil der setup-project-Hook des ROCm-SDK beim Sprung auf 7.2 fehlschlägt, bricht Workshop ab und stellt den zuvor funktionierenden Container wieder her. Der zweite, fürs Debugging gedachte Modus startet oder aktualisiert den Workshop mit einer Wait-on-Error-Option (workshop refresh --wait-on-error --verbose dev): Tritt ein Fehler auf, hält die Ausführung genau an dieser Stelle an. Anwender können sich dann per workshop shell in den Container einklinken, das Problem untersuchen, etwa einen falschen Paketnamen oder eine fehlerhafte Skriptkonfiguration, und den Vorgang mit --continue fortsetzen oder mit --abort abbrechen. Wer schon einmal ein hängendes Rebase aufgelöst hat, kennt das Muster.
Eigene SDKs mit SDKcraft
Die SDKs stammen nicht zwingend von Canonical. Wer eine Runtime, eine Toolchain oder einen Hardware-Zugriff abbilden will, der im Store fehlt, kann ein eigenes SDK bauen, die Publisher wissen in der Regel am besten, wie sich ihre Komponente sauber in einen laufenden Container installieren lässt. Das Werkzeug dafür heißt SDKcraft und arbeitet mit einer sdkcraft.yaml, die, analog zur SDK-Anatomie, Blöcke für Meta, Interfaces, Hooks und Parts kennt. Der Workflow ähnelt dem von Snapcraft: sdkcraft init legt ein Grundgerüst an, sdkcraft test prüft es (auch in der CI/CD gegen aktuelle Workshop-Versionen und SDK-Kombinationen), sdkcraft pack bündelt alles zum SDK-Paket, und sdkcraft upload opencode_amd64.sdk --release latest/stable veröffentlicht es im gewünschten Channel des Stores.
Crafting and publishing an SDK: Aufbau der sdkcraft.yaml (Meta, Interfaces, Hooks, Parts) und der Veröffentlichungs-Workflow von init über test und pack bis upload. Quelle: Ubuntu Summit 26.04, Vortrag Dmitry Lyfar (Canonical), Folie 160.
Auf die Publikumsfrage, ob sich SDKs ebenso einfach erstellen ließen wie Snaps, antwortete Lyfar mit einem klaren Ja, die Bauteile seien öffentlich und offen zugänglich. Manche Snaps gäben sogar besonders gute SDKs ab, weil sie ohnehin in einer veränderbaren Umgebung liefen. Wer Komponenten nicht im öffentlichen Store ablegen möchte, kann lokale SDKs direkt im Projekt mitführen, das Workshop-Repository selbst demonstriert das, indem es sie in einem .workshop/tools/-Verzeichnis neben einer dort benannten Definition (dev.yaml) ablegt; die dokumentierte Standardkonvention für die Definition bleibt aber ein workshop.yaml im Projektverzeichnis. Dieser Punkt beantwortet zugleich eine im Discourse-Thread gestellte Frage des Nutzers locnnil, der wissen wollte, was sich tun lässt, wenn der Store eine benötigte Konfiguration nicht hergibt.
Über die CLI lässt sich der Store durchsuchen: sdk find findet passende SDKs, sdk info liefert Details zu einem einzelnen SDK, workshop init --sdks opencode,node erzeugt aus einem ausgewählten Satz ein Grundgerüst, und workshop launch bringt die Umgebung zum Laufen.
Einordnung: Abgrenzung zu Devcontainers und Co.
Die naheliegende Frage stellte im begleitenden Discourse-Thread der Nutzer wtclarke: Worin unterscheidet sich Workshop von Devcontainers, und wo liegen die Vorteile angesichts der erkennbaren Überschneidungen? Eine klare Antwort blieb in der Session aus, ein anderer Teilnehmer merkte im Thread an, die Antwort auf diese Frage verpasst zu haben.
Es gibt Überschneidungen mit etablierten Werkzeugen wie Dev Containers, Nix-Shells oder Docker Compose. Workshops Alleinstellungsmerkmal ist die konsequente Isolation: unprivilegierte LXD-System-Container statt auf Bequemlichkeit getrimmter Voreinstellungen. Während ein Dev Container typischerweise auf einer Docker-Runtime aufsetzt, nutzt Workshop vollwertige System-Container mit eigenem systemd, Docker lässt sich darin übrigens problemlos verschachtelt betreiben, ein entsprechendes Docker-SDK existiert bereits.
Eine breitere Einordnung lieferte bereits Shuttleworths Keynote. Dort verortete er Workshop in einem ganzen Werkzeugkasten an Isolationsschichten, aus dem man je nach Anwendungsfall wähle: Docker-Container für klassische OCI-Workloads, Snaps für Endanwender-Software mit feingranularen Berechtigungen, LXD und LXC für System-Container, klassische VMs, etwa via Multipass, dort, wo selbst eine kernel-erzwungene Containergrenze nicht genügt, sowie als jüngste Ergänzung sogenannte Micro-VMs, an denen Canonical mit NVIDIA arbeitet und die sich derzeit über snap install openshell ausprobieren lassen. Workshop ist in dieser Systematik der Baustein für agentische Entwicklungs-Arbeitsplätze und setzt bewusst auf der LXD-Ebene auf.
Auf die Frage nach der Einbindung in bestehende Workflows betonte Lyfar, Workshop wolle sich nicht zwischen Entwickler und ihre Werkzeuge drängen. Es ersetze kein make und stehe nicht im Weg, wenn man es nicht brauche. Der empfohlene Ansatz: die gesamte Umgebung deklarativ als Satz von SDKs beschreiben und sie anschließend über die IDE oder bevorzugte Werkzeuge nutzen.
Bemerkenswert ist, was Workshop ausdrücklich nicht sein will. Mehrere Fragen zielten auf einen Einsatz als Laufzeit- oder Deployment-Umgebung, schließlich erzeugt das Werkzeug isolierte, reproduzierbare und sofort verfügbare Umgebungen. Lyfar wiegelte ab: Man betrachte Workshop derzeit ausschließlich als Entwicklungsumgebung, die freundlich auf dem Desktop laufe, sich nahtlos in IDEs und andere Werkzeuge einfüge und Teil des Arbeitsablaufs werde. Einen Plan, Workshop als Deployment-Plattform zu positionieren, gebe es nicht. Die einzige Brücke in diese Richtung führt über die CI/CD: Laut Lyfar lässt sich ein für ein Projekt definierter Workshop per GitHub-Action ausführen, sodass Tests in exakt derselben Umgebung laufen wie auf dem Desktop. Die Dokumentation beschreibt darüber hinaus den umgekehrten Weg, einen selbst gehosteten GitHub-Actions-Runner innerhalb eines Workshops zu betreiben, der sich über eine GitHub-App fein granular gegenüber dem Repository autorisiert. In beiden Fällen entsteht eine Eins-zu-eins-Beziehung zwischen lokaler Entwicklung und Pipeline.
Ein gut gefüllter Fahrplan
Auf die im Saal wie im Thread gestellte Frage nach der Roadmap zeigte sich Lyfar auskunftsfreudig, eigene Folien gab es dafür nicht, die Punkte nannte er mündlich. Mehrere davon stehen demnach für kommende Releases an. Künftig sollen sich Umgebungen wahlweise auch in virtuellen Maschinen statt in Containern betreiben lassen, für noch stärkere Isolation. Ein eigenes Konzept ist geplant, über das Agenten innerhalb des Workshops auf Secrets zugreifen können, ohne dass diese ungeschützt im Klartext herumliegen. Hier lohnt eine Differenzierung: Shuttleworth hatte in der Keynote bereits beschrieben, dass sich ein Workshop-Container host-seitig mit einer kuratierten Auswahl an Schlüsseln, Datensätzen und Capabilities bestücken lässt; der von Lyfar skizzierte, strukturierte Secrets-Zugriff für Agenten ist davon zu unterscheiden und befindet sich noch in Entwicklung. Bei den IDE-Integrationen macht Visual Studio Code den Anfang: Workshop soll sich nativ als Laufzeitumgebung in VS Code einbinden lassen, sodass der Wechsel zwischen IDE und Kommandozeile entfällt.
Den größten praktischen Hebel verspricht der Remote-Anwendungsfall. Wer eine MicroCloud im Unternehmen oder im Heimnetz betreibt, soll Workshops reibungslos auf entfernten Hosts mit leistungsstarken GPUs ausführen und vom Notebook aus, über VS Code oder das Terminal, darauf zugreifen können. Damit adressiert Canonical ein verbreitetes Muster im KI-Umfeld: schwache Client-Hardware, die rechenintensive Arbeit auf eine zentrale, gut ausgestattete Maschine auslagert.
Verfügbarkeit und Fazit
Workshop ist ab sofort verfügbar und wird als classic Snap installiert. Die zum Summit veröffentlichte Fassung trägt die Versionsnummer 0.9.0. Es versteht sich damit erkennbar als früher, aber bereits nutzbarer Stand. Voraussetzung ist LXD in Version 6.8 oder neuer; meldet die Installation ein Problem mit LXD, lässt sich eine aktuelle Version per Snap nachziehen:
sudo snap install --channel=6/stable lxd
sudo snap install --classic workshopUnterstützt wird Workshop auf Ubuntu sowie weiteren Snap-fähigen Linux-Distributionen. Der Quellcode liegt auf GitHub unter canonical/workshop, die rund 20 Referenz-SDKs in einem eigenen Repository unter canonical/reference-sdks; Tutorial und SDKcraft-Anleitung finden sich in der Dokumentation unter ubuntu.com/workshop/docs.
Unterm Strich präsentiert Canonical mit Workshop ein durchdachtes Werkzeug, das ein reales Problem adressiert und dabei konsequent auf bewährte hauseigene Technik setzt: LXD für die Containerisierung, ein an snapd angelehntes Schnittstellenmodell für die Ressourcenfreigabe und einen Store nach dem Vorbild des Snap Store für die Verteilung. Die Betonung der Agenten-Tauglichkeit ist zeitgemäß und plausibel begründet, denn die strikte Trennung zwischen Entwicklerkomfort und Agenten-Berechtigungen löst einen Konflikt, den viele bestehende Werkzeuge schlicht offenlassen.
Schon der Name ist allerdings ein kleines Eigentor: »Workshop« ist als generischer Alltagsbegriff praktisch nicht suchmaschinentauglich. Daran ändert auch ein präzisierender Zusatz wenig, wer nach »Canonical Workshop« oder »Ubuntu Workshop« sucht, bekommt vor allem die zahlreichen Schulungs- und Veranstaltungs-Workshops zu sehen, die beide Marken ohnehin selbst anbieten. Für ein Projekt, das gerade erst Sichtbarkeit aufbauen muss, ist das ein vermeidbarer Reibungsverlust.
Inhaltlich schwerer wiegt die Frage, ob sich Workshop gegen die etablierte Konkurrenz durchsetzt. Die Überschneidung mit Dev Containers, Nix und Docker Compose ist beträchtlich, und Canonicals Snap- und LXD-zentrierter Ansatz dürfte, wie schon bei früheren Vorstößen, nicht in jeder Community auf ungeteilte Begeisterung stoßen. Auch die enge Bindung an das eigene Ökosystem ist Stärke und potenzielle Schwäche zugleich. Wer ohnehin im Ubuntu-Umfeld zu Hause ist und regelmäßig mit wechselnden KI-Stacks und agentischen Werkzeugen hantiert, erhält jedoch ein bemerkenswert kohärentes Werkzeug, das den Weg von der leeren Maschine zur lauffähigen Umgebung tatsächlich auf ein einziges Kommando verkürzt.
Marius Quabeck war im Rahmen des Ubuntu Summit 26.04 für das Linux-Magazin in London vor Ort. Er wurde von Canonical eingeladen; Canonical trägt die Reisekosten der eingeladenen Teilnehmer.
