Überblick
Ottili Coder und Ottili Cloud sind nativ Teil von Ottili ONE: sie teilen ein Login, einen Unternehmenskontext (company_id) und einen Audit-Trail. Das bedeutet: ein von Coder gebauter, validierter Service kann prinzipiell auf dieselbe verwaltete Cloud-Infrastruktur zugreifen wie der Rest deiner Plattform — ohne separate Cloud-Credentials und ohne neuen Identitäts- oder Berechtigungs-Silo.
Dieser Artikel beschreibt die Deployment-Integration zwischen Ottili Coder und Ottili Cloud*: wie Ergebnisse heute ausgeliefert werden, was Cloud-Runs leisten und welchen Status die direkte Deployment-Übergabe hat. Kurz gesagt: Coder liefert heute repository-zuerst*; die direkte Übergabe eines bestandenen Runs an verwaltete Ottili Cloud-Infrastruktur ist geplant (PLANNED)* und aktuell noch nicht verkabelt.
Status im Überblick
| Fähigkeit | Reifestatus | Was heute gilt |
|---|---|---|
| Lokale Runs | Verfügbar (AVAILABLE) | Ergebnisse bleiben in deiner lokalen Umgebung bzw. deinem Repository. |
| Cloud-Runs (Ottili Cloud) | Beta (BETA) | Dieselbe Task-Queue läuft in Ottili Cloud; Ergebnisse kehren in dein Repository zurück. |
| Direkte Cloud-Deployment-Übergabe (Coder → Cloud) | Geplant (PLANNED) | Noch kein öffentliches Ziel; nicht als verfügbar dargestellt. |
Wie Ottili ONE Reifestatus öffentlich kenntlich macht, beschreibt der Artikel [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels). Den Produktlebenszyklus und das Beta-Modell erklärt [Produktlebenszyklus und Feature-Status](/docs/product-lifecycle-and-feature-status).
Wie die Integration heute funktioniert: repository-zuerst
Jeder Coder-Run endet mit überprüfbaren Artefakten in deinem Git-Workflow — unabhängig davon, ob er lokal oder in der Cloud lief:
1. Coder erzeugt einen oder mehrere Branches* mit den Änderungen der Agenten.
2. Jede Aufgabe durchläuft Validierungs-Schleifen* (Tests, Typen, Security-Gates), bevor sie als erledigt gilt.
3. Coder öffnet einen Pull Request* in deinem Repository — er merged nichts eigenmächtig.
4. Du reviewst, belieferst und mergst über deine bestehende CI/CD- und Deployment-Pipeline*.
Coder ersetzt deine Pipeline nicht. Er bereitet validierte, reviewbare Ergebnisse vor und überlässt die Freigabe und Auslieferung deinen etablierten Prozessen. So bleiben deine Release-Gates, Approvals und Rollbacks bei dir. Den Ablauf beschreibt der Artikel [Bereitstellungen mit Ottili Coder](/docs/coder-deployments) und die lokale/Cloud-Hybrid-Ausführung [Lokale, Cloud- und Hybrid-Runs](/docs/coder-local-cloud-hybrid-runs).
Cloud-Runs (Beta)
Mit Cloud-Runs* führst du dieselbe Task-Queue in Ottili Cloud* aus, damit lokale Rechner nicht blockiert werden. Der Reifestatus ist Beta (BETA)* — nie als verfügbar (AVAILABLE) dargestellt. Wichtig: auch Cloud-Runs geben ihre Ergebnisse an dein Repository zurück; sie deployen nichts eigenständig in Produktion. Die Compute-Kapazität, auf der Cloud-Runs laufen, gehört zur verwalteten Ottili Cloud (siehe [Cloud-Compute](/docs/cloud-compute) und [Instanzen und Lebenszyklus](/docs/instances-and-lifecycle)).
Geplante direkte Deployment-Übergabe
Die direkte Übergabe eines bestandenen Coder-Runs an verwaltete Ottili Cloud-Infrastruktur ist geplant (PLANNED)*. Sie ist kein öffentliches Ziel und wird nicht als verfügbar beworben. Wenn sie verfügbar wird, ist das Integrationsmodell klar:
- Dieselbe Identität*: der Run läuft im selben Unternehmenskontext (
company_id); keine separaten Cloud-Credentials. - Verwaltete Ziele*: das Deployment landet auf verwalteter Ottili Cloud-Infrastruktur — Instanzen, Container und Serverless, sobald diese Kapazitäten allgemein verfügbar sind (heute Early Access bzw. geplant, siehe [Ottili Cloud](/docs/ottili-cloud)).
- Freigabe zuerst*: das Deployment ist approval-first; jede Aktion wird über Ottili Core* und Ottili Console* erzwungen und über Ottili Core Audit* protokolliert.
- Security im Task-System*: Ottili Security Check* prüft Abhängigkeits- und Secret-Risiken in dasselbe Aufgabensystem wie der übrige Run.
Bis die direkte Übergabe verfügbar ist, gehen Deployments über dein Repository und deine eigene Pipeline. Wir beschreiben geplantes Deployment bewusst nicht so, als würde es heute bereits ausliefern. Sobald die direkte Cloud-Auslieferung verfügbar wird, wird dieser Guide aktualisiert und der Feature-Status auf der Produkt- und Statusseite gezeigt.
Sicherheit und Unternehmenskontext
Jeder Coder-Lauf ist unternehmensgebunden: er läuft innerhalb genau eines Unternehmens (company_id) und wird über Ottili Core Audit* protokolliert. Ottili Security Check* prüft Abhängigkeits- und Secret-Risiken in dasselbe Aufgabensystem. Kritische Aktionen werden über Ottili Console* und Ottili Core* erzwungen. Die Coder-seitigen Security-Gates sind in [Sicherheitsprüfungen in Coder](/docs/coder-security) erklärt; den gemeinsamen Kontokontext beschreibt [Unternehmen und Team](/docs/company-and-team).
Wie es in die Plattform passt
Ottili Cloud und Ottili Coder sind nativ Teil von Ottili ONE. Beide teilen ein Login, einen Unternehmenskontext und einen Audit-Trail mit Ottili HQ, Ottili AI, Ottili LD3 und dem Rest der Plattform. Dieselbe Unternehmensgrenze und Identität versorgen alle Oberflächen aus deinem Unternehmen heraus. Wie sich Plattform-Ebene und Produkt-Ebene voneinander abgrenzen, beschreibt [Plattform-Ebene und Produkt-Ebene](/docs/platform-layer-and-product-layer).
Wohin als Nächstes
- Richte deinen [Account](/docs/cloud-accounts) und deine [Projekte](/docs/cloud-projects) in Ottili Cloud ein.
- Verstehe [Regionen](/docs/cloud-regions), [Compute](/docs/cloud-compute) und [Netzwerk](/docs/cloud-networking).
- Sieh dir [Storage](/docs/cloud-storage) und [Sicherheit](/docs/cloud-security) in Ottili Cloud an.
- Lies [Bereitstellungen mit Ottili Coder](/docs/coder-deployments) und [Lokale, Cloud- und Hybrid-Runs](/docs/coder-local-cloud-hybrid-runs).
War dieser Artikel hilfreich?