Konzepte in fünf Minuten

SupaCloud ist ein self-hostbarer Orchestrator für KI-Coding-Agents: Du verbindest deine Repositories, und SupaCloud startet Agenten dagegen – in Containern, auf Maschinen, die du kontrollierst. Mehr als eine Hülle um eine Coding-CLI ist es deshalb, weil jeder Teil davon ein erstklassiges, einsehbares Objekt ist: die Arbeit, jeder einzelne Versuch dieser Arbeit, wer sie ausführen durfte, wie weit er ohne Rückfrage gehen durfte und was sie gekostet hat.

Die übrigen Seiten dieses Abschnitts sind zu jedem dieser Objekte präzise. Diese Seite liefert das Vokabular, das sie voraussetzen: rund zehn Begriffe, je ein kurzer Absatz, jeder mit dem Verweis auf die Seite, die in die Tiefe geht.

Organisation und Workspace

Es gibt zwei ineinander liegende Mandanten. Eine Organisation ist der oberste: Sie besitzt Abrechnung, Sitze, Single Sign-on und Einladungen, und jeder Nutzer gehört zu genau einer (bei der Anmeldung wird automatisch eine persönliche für dich angelegt). Darunter liegt der Workspace, der Container, in dem alles Übrige lebt: Projekte, Tasks, Runs, Workflows, Zeitpläne, Secrets und Verbindungen. Die Mitgliedschaft ist nutzerbezogen, und dein aktiver Workspace sagt dem Server, in welcher Organisation du handelst – einen Organisationswechsler gibt es nicht, und die meisten arbeiten in einem Workspace und denken selten an die Ebene darüber. Workspaces und Organisationen zeigt die vollständige Hierarchie und wie Berechtigungen darin aufgelöst werden.

Projekt

Ein Projekt ist die Arbeit an genau einem Repository innerhalb eines Workspaces. Es bindet das Git-Repository, das ein Agent klont, und optional eine Issue-Quelle – die Issues des Git-Forge selbst, Linear oder Notion –, sodass ein Projekt reines Repository, reiner Tracker oder beides sein kann, und es trägt die Zugangsdaten, die Automatisierungs-Einstellungen und die Merge-Richtlinie, die dort gelten. Jeder Agent-Run läuft gegen ein Projekt – darum lässt sich ein Task im Nachhinein nicht zwischen Projekten verschieben.

Task und Run

Diese Unterscheidung lernst du am besten zuerst, weil große Teile der Oberfläche von ihr geprägt sind. Ein Task ist die dauerhafte Definition eines Stücks agentischer Arbeit – Projekt, Prompt, Agent, Profil, Modell, verknüpftes Issue. Ein Run ist eine einzelne Ausführung: ein Container, der startet, arbeitet und endet, mit eigenem Status, eigenen Kosten und eigenem append-only-Ereignisprotokoll. Ein Neustart überschreibt daher nichts, sondern legt einen neuen Run mit der nächsten Versuchsnummer und leerem Ereignisprotokoll an – deshalb übersteht die Historie eines Tasks beliebig viele Versuche. Runs und Tasks behandelt die Run-Arten, das Neustart-Verhalten und die Sichten, durch die du einen Run betrachten kannst.

Agent und Agent-Profil

Ein Agent ist der Coding-Prozess, den SupaCloud für einen Run startet. Mehrere werden unterstützt – Claude Code, Codex, opencode und weitere –, und aus deiner Sicht verhalten sie sich gleich: Sie arbeiten im Container und greifen über Tools nach SupaCloud zurück. Ein Agent-Profil ist das gespeicherte Wer: welches Modell, welche Tool-Stufen der Agent nutzen darf, welche Pre- und Post-Flight-Checks er bestehen muss und in welchem Ausführungsmodus er läuft. Ein Profil an einen Task, eine Automatisierung oder einen ganzen Workspace zu binden, sagt „arbeite so“ einmal statt bei jedem Start – und ein Task ohne Profil erhält bewusst eine schmale, nur lesende Oberfläche statt eines großzügigen Standards.

Workflow

Nicht jede Arbeit passt in einen Prompt. Ein Workflow ist ein deklarativer Graph aus Knoten – Agent-Schritte, Code, Datenbankabfragen, Connectors, verzweigende Gates, menschliche Haltepunkte –, den du in einem visuellen Builder zeichnest und der als Run ausgeführt wird. Es ist dasselbe Run-Modell: Jeder Knoten wird zu einem untergeordneten Run des Workflow-Runs, und du klickst vom ganzen Graph bis in das Ereignisprotokoll eines einzelnen Agenten hinab. Workflows sind der Ort für mehrstufige Arbeit mit Bedingungen, Wiederholungen und einem Menschen in der Mitte. Deinen ersten Workflow erstellen führt einen von der leeren Leinwand bis zum fertigen Run.

Automatisierungen

Eine Automatisierung verwandelt ein Ereignis in Arbeit, ohne dass du etwas startest. Jedes Projekt hat genau einen Automatisierungs-Abschnitt, und dessen Autodev-Modus entscheidet, was mit eingehenden Issues geschieht: Aus importiert sie, dispatcht aber nichts, Einfach setzt jedes neue Issue in Eingangsreihenfolge direkt in einen Pull-Request um, und Backlog sammelt, klassifiziert und priorisiert sie zuerst. Eine getrennte PR-Review-Spur läuft unabhängig von diesem Modus auf Pull-Request-Webhooks. Issues werden in jedem Modus importiert – der Modus steuert allein, ob sie dispatcht werden. Automatisierungen erklärt die Modi, den Klassifizierer und die gemeinsamen Überwachungs-Steuerungen.

Autonomie und Freigaben

Die Autonomiestufe ist eine einzige Zahl von 0 bis 100 – gesetzt pro Workspace, Projekt oder Agent-Profil –, und sie entscheidet, wie weit ein Agent allein gehen darf: ob Arbeit überhaupt unbeaufsichtigt dispatcht wird, wie schnell der Agent für eine Rückfrage stehen bleibt, und wie weit eine Änderung höchstens kommen darf (einen Pull-Request öffnen und warten, nach grüner CI mergen oder direkt mergen). Sie rastet in fünf benannten Stufen von Manuell bis Entfesselt ein, und zwei harte Obergrenzen – dein Tarif sowie eine vorsichtige Begrenzung, solange ein Workspace im Onboarding ist – können sie ausschließlich senken. Wo ein Agent tatsächlich stehen bleibt, bekommst du eine Freigabe: genau eine offene Entscheidung – ein gefährlicher Tool-Aufruf, eine offene Frage, ein Screenshot zum Abnehmen –, die diesen Run blockiert, bis du antwortest. Die Policy eines Runs wird beim Start eingefroren – den Schieberegler später zu bewegen verändert nie Arbeit, die bereits läuft. Autonomie und die Delivery-Engine beschreibt die Stufen und die Auflösungsreihenfolge; Agenten-Aktionen freigeben oder ablehnen zeigt, wie das Antworten aussieht.

Tool-Stufen

Die Autonomie entscheidet, wie weit ein Agent geht; die Tool-Stufen entscheiden, was er überhaupt anfassen darf. Alles, was ein Agent gegenüber SupaCloud tut, läuft über eine Tool-Oberfläche, die in Stufen geteilt ist – eine immer aktive Baseline, lesende Lageübersicht, operative Auslöser, Scaffolding und Deployment –, und die Allowlist eines Agent-Profils benennt die Stufen, die diese Sitzung erhält. Das gefährliche Ende ist fail-closed: Ohne ausdrückliche Freigabe bekommt ein Agent Lesezugriff und nichts weiter, und eine App zu deployen oder eine Migration anzuwenden braucht zusätzlich einen Owner oder Admin als Akteur sowie eine signierte zweistufige Bestätigung, die keine Autonomie-Einstellung wegwischen kann. Berechtigungen und MCP-Tool-Stufen listet die Stufen, ihre Ratenlimits und wie Edition und Tarif damit zusammenwirken.

Runner

Ein Runner ist die Maschine, die den Container eines Runs physisch ausführt. Standardmäßig ist das der SupaCloud-Server selbst, und das genügt den meisten Installationen vollkommen – ein einzelner Host führt problemlos viele Agenten gleichzeitig aus. Schaltest du die Flotte ein, holen separate Worker-Maschinen dieselbe Arbeit ab: Sie verbinden sich nach außen zum Server und fragen nach Jobs, sodass ein Runner keine eingehenden Ports braucht und keine Kopie deiner Datenbank hält. In beiden Fällen landen Ereignisse, Kosten und Logs an derselben Stelle, ein Run sieht also gleich aus, wo auch immer er lief. Die Runner-Flotte erklärt, wann sich dieser Tausch lohnt.

Marketplace

Nicht alles muss selbst gebaut werden. Der Marketplace ist ein Katalog installierbarer Bausteine: Workflows, Scripts, gesandboxte Connectors, die dem Builder einen neuen Knotentyp hinzufügen, Apps sowie Bundles, die mehrere davon zusammen tragen – eine Installation bringt so ein ganzes Produkt statt zweier Listings und einer README. Elemente können kostenlos oder kostenpflichtig sein, und was das automatisierte Review-Gate bestanden hat, trägt ein Verifiziert-Abzeichen. Beim Installieren wird ein Element an deine eigenen Zugangsdaten gebunden – der Netzzugriff eines Connectors reicht nur an die Verbindungen, die du bei der Installation zuordnest. Einen Marketplace-Connector installieren führt eine Installation von Anfang bis Ende durch.

Die Oberflächen

Die Web-UI ist nicht der einzige Zugang. Dasselbe Steuer-Vokabular – starten, folgen, eingreifen, abbrechen, freigeben – steht im Web-Terminal unter /cli, in einem verknüpften Telegram-Chat und in Discord zur Verfügung, und ein Befehlswort bedeutet auf allen drei dasselbe, weil sie einen einzigen Befehlskatalog lesen. Das zahlt sich im Alltag aus: Du startest einen Run am Schreibtisch, verfolgst ihn aus dem Zug in Telegram und beantwortest seine Freigabe am Handy. Innerhalb der Web-UI falten sich verwandte Oberflächen in einige Hub-Routen statt in eine lange Seitenleiste – Navigation und Hubs erklärt diese Form, und Befehle des Web-Terminals ist der vollständige Befehlssatz.