Odoo.sh: Leistungsumfang, Branches und Grenzen
Kurz gesagt
Odoo.sh ist die Cloud-Plattform von Odoo für Anwendungen mit eigenem Code: Module liegen in einem GitHub-Repository, daraus entstehen Datenbanken für Development, Staging und Production. Nötig ist ein Enterprise-Abonnementcode, der Odoo.sh einschließt. Builds, Neutralisierung und die automatische Sicherung der Produktionsdatenbank trägt die Plattform; Pflege des eigenen Codes und die Übertragung von Staging-Änderungen bleiben Ihre Aufgaben, und um ein eigenes Sicherungsarchiv über die Aufbewahrung der Plattform hinaus sollten Sie sich selbst kümmern.
Das Wichtigste
- Odoo.sh verlangt laut Dokumentation 20.0 einen Enterprise-Abonnementcode, der Odoo.sh einschließt, und ein GitHub-Konto.
- Drei Stufen: Production, Staging und Development; nur ein Produktionszweig je Projekt ist möglich.
- Produktionsdatenbank: automatisch 7 tägliche, 4 wöchentliche und 3 monatliche Sicherungen (Dokumentation 20.0).
- Staging- und Development-Datenbanken werden nicht automatisch gesichert.
- Laut Preisseite vom 13.10.2026 sind Odoo.sh-Hosting und die Wartung eigenen Codes nicht im Planpreis enthalten.
Odoo Online lässt laut Dokumentation 20.0 keine eigenen Module zu, ein eigener Server verlangt Betrieb und Wartung. Dazwischen liegt Odoo.sh: eine Plattform von Odoo, auf der eigener Code in einem GitHub-Repository liegt und daraus getrennte Datenbanken für Entwicklung, Test und Produktion entstehen. Der folgende Text beschreibt, was die Dokumentation 20.0 der Plattform zuschreibt und was beim Kunden bleibt; die Einordnung neben den anderen Hostingarten steht unter Hostingmodelle im Überblick.
Was Odoo.sh umfasst
Nach dem Einstiegskapitel der Dokumentation 20.0 besteht ein Projekt aus drei Teilen: dem GitHub-Repository mit dem Quellcode, dem Projekt auf der Plattform und der Datenbank. Die Dokumentation nennt das Projekt eine Platform as a Service, die sich mit GitHub verbindet und Entwicklung, Test und Auslieferung bündelt. Das Anlegeformular verlangt ein GitHub-Konto, den Abonnementcode und die Hostingregion; fehlt der Code oder schließt er Odoo.sh nicht ein, entsteht kein Projekt.
Odoo.sh erkennt im Repository automatisch die Ordner mit Odoo-Modulen, gleich ob eigene oder öffentlich verfügbare Community-Module. Fremde Repositorys binden Sie als Git-Submodul ein; für private Repositorys ist ein Deploy Key nötig. Jeder Build läuft in einem eigenen Container auf Ubuntu-Basis. Zusätzliche Python-Pakete steuern Sie über eine Datei requirements.txt im Wurzelverzeichnis des Branches. Für Fehlersuche stehen Web-Shell mit psql, Editor, Logs, Monitoring und ein Profiler bereit, der höchstens fünf Minuten aufzeichnet; der Editor ist auf Produktionsbuilds nur lesend.
Der Zugang läuft über Collaborators in drei Rollen: Admin mit vollem Zugang und den Projekteinstellungen, Tester mit Zugriff auf Staging- und Development-Datenbanken, Developer ohne Zugriff auf Produktions- und Staging-Datenbanken, Web-Shell und Serverlogs. Datenbankbenutzer sind davon getrennt. Die deutsche Preisseite vom 13. Oktober 2026 führt das Odoo.sh-Hosting als nicht im Planpreis enthalten und nennt dafür keinen Betrag; Einführungsleistungen und die Wartung eigenen Codes kosten ebenfalls zusätzlich. Eine Rechnung der drei Hostingarten steht im Kostenvergleich.
Die drei Branch-Stufen
Die Plattform ordnet jeden Branch einer von drei Stufen zu, und nur ein Zweig darf die Produktion bedienen. Development-Branches lassen sich zu Staging-Branches machen, Staging-Branches per Merge in die Produktion übernehmen. Die Tabelle fasst zusammen, welche Datenbank je Stufe entsteht.
| Stufe | Datenbank | Was die Plattform dort abschaltet oder tut | Sicherungen |
|---|---|---|---|
| Production | erste Datenbank des Projekts; ein Push spielt die neue Revision ein | startet den Server neu; aktualisiert ein Modul nur, wenn dessen Versionsnummer in __manifest__.py steigt; bei Fehlschlag Rücksprung auf Revision und Datenbankstand davor |
automatisch für die Produktionsdatenbank: 7 täglich, 4 wöchentlich, 3 monatlich (Dokumentation 20.0) |
| Staging | neutralisierte Kopie der Produktionsdatenbank | schaltet geplante Aktionen, ausgehende E-Mails und Dienste für In-App-Käufe ab; Zahlungsanbieter und Versandkonnektoren stellt die Plattform in den Testmodus; Einheitstests laufen nicht | keine automatische; manuell möglich |
| Development | neue Datenbank mit Demodaten | führt Einheitstests aus, fängt E-Mails im Mail-Catcher ab, löst geplante Aktionen nur bei Nutzung aus | keine |
Ein Staging-Branch ist ein Zweig, dessen Datenbank als neutralisierte Kopie der Produktionsdatenbank läuft: geplante Aktionen, ausgehende E-Mails und der Bankabgleich sind abgeschaltet, Zahlungsanbieter und Versandkonnektoren laufen im Testmodus, damit kein Testvorgang echte Wirkung entfaltet; E-Mails fängt der Mail-Catcher des Projekts ab (Staging-Branch).
Was automatisch läuft und wo die Grenzen liegen
Nach jedem Push baut die Plattform den Branch und meldet das Ergebnis als erfolgreich, fast erfolgreich oder fehlgeschlagen. Der Reiter History hält Commits, Autoren und Ereignisse wie Stufenwechsel, Datenbankimport und Wiederherstellung fest. Misslingt ein Build der Produktionsdatenbank, läuft sie mit der letzten erfolgreichen Revision weiter.
Geplante Aktionen behandelt Odoo.sh anders als eine eigene Installation: Sie laufen nur nach bestem Bemühen, ein genauer Ausführungszeitpunkt lässt sich nicht garantieren. Häufiger als alle fünf Minuten sind sie nicht zu erwarten, weil sich mehrere Kunden die Serverressourcen teilen. Die Dokumentation empfiehlt daher, sie in kleinen Stapeln arbeiten zu lassen, Zwischenstände nach jedem Stapel festzuschreiben und sie so zu bauen, dass ein häufigerer Lauf als erwartet keine Nebenwirkungen erzeugt.
Weitere Grenzen: Staging-Datenbanken werden nach einem Monat gelöscht, Development-Datenbanken nach etwa drei Tagen; manuelle Sicherungen bleiben drei Tage, höchstens fünf pro Tag. Vor einem Import verlangt der Vorgang den vierfachen Speicherplatz des Dumps, überschreibt die vorhandene Branch-Datenbank und trennt sie vom Abonnement. Port 25 ist dauerhaft geschlossen; ein importiertes System verschickt E-Mails über den Standardserver von Odoo.sh.
Was Ihre Aufgabe bleibt
| Aufgabe | Was die Quellen dazu sagen |
|---|---|
| Eigene Module pflegen | Quellcode und Fremdmodule liegen im Repository des Kunden; die Wartung eigenen Codes ist laut Preisseite (13.10.2026) nicht im Planpreis enthalten |
| Konfiguration übertragen | Ein Merge überträgt nur Quellcode; Änderungen in der Staging-Datenbank erreichen die Produktion nur über XML-Datendateien im Modul samt Versionserhöhung oder von Hand |
| Datenbank registrieren | Nach einem Import gilt die Datenbank als Duplikat und wird vom Abonnement getrennt; erlaubt ist eine aktive Datenbank je Abonnement |
| Sicherungen | Die Plattform sichert die Produktionsdatenbank automatisch (7 täglich, 4 wöchentlich, 3 monatlich); Herunterladen und Wiederherstellen laufen über den Reiter Backups, die drei monatlichen Stände liegen auf getrennten Servern und sind nur über den Odoo-Support erreichbar; eine eigene Ablage über diese Aufbewahrung hinaus ist eine redaktionelle Empfehlung, keine Pflicht der Plattform (Backup-Strategie) |
| DNS und E-Mail-Zustellung | Eigene Domain: Sie besitzen sie und setzen den CNAME; reine Domainnamen ohne www akzeptiert die Plattform nicht. Für SPF und DKIM müssen Sie Odoo als Versandhost freigeben |
| Zugänge | Collaborators und Rollen pflegen Sie im Projekt; Datenbankbenutzer verwalten Sie in der Datenbank |
| Upgrade prüfen | Nach Abschnitt 4.3 des Abonnementvertrags prüft und validiert der Kunde die aktualisierte Datenbank und passt Drittanbieter-Module an |
| Support-Reichweite | Nach Abschnitt 4.5 decken kostenlose Tickets Fehler und Fragen zur Nutzung der Standardfunktionen und abgedeckter Zusatzmodule (Covered Extra Modules) ab; Fragen zu Entwicklung und nicht abgedeckten Anpassungen brauchen eine eigene Vereinbarung |
| Kapazität | Zusätzliche Worker und Staging-Zweige werden nach der Dokumentation über den Account Manager oder eine Produktanfrage bestellt; überschreitet die Produktionsdatenbank den enthaltenen Speicher, passt sich der Plan an |
| Datenschutz | Nach Abschnitt 6.5 des Vertrags ist der Kunde Verantwortlicher für personenbezogene Daten in der Datenbank; Standort und Auftragsverarbeitung behandelt der Artikel Hosting und DSGVO |
Abschnitt 6.1 verlangt sichere Benutzerkonten, also starke Kennwörter ohne Weitergabe, und eine Nutzung im Rahmen der Acceptable Use Policy. Der Support deckt Fehler in Odoo und in abgedeckten Zusatzmodulen (Covered Extra Modules) ab; nicht abgedeckte Anpassungen und Entwicklungsfragen fallen nicht darunter.
Typische Fehler
- Den Development-Branch als dauerhafte Testumgebung einplanen: Die Datenbank wird nach etwa drei Tagen eingesammelt, Sicherungen gibt es dort nicht.
- Nach der Arbeit im Staging erwarten, dass die Konfiguration in der Produktion erscheint: Der Merge überträgt nur Dateien aus dem Repository.
- Ein Modul ändern, ohne die Versionsnummer im Manifest zu erhöhen: Die Plattform aktualisiert es dann nicht automatisch.
- Development direkt in die Produktion mergen: Die Dokumentation nennt das möglich, aber riskanter, weil das Staging als Prüfung gegen echte Daten fehlt.
- Supporttickets für nicht abgedeckten eigenen Code einplanen: Dafür braucht es laut Vertrag eine eigene Vereinbarung.
So gehen Sie vor
- Klären Sie Plan und Abonnementcode: Odoo.sh gehört zum Enterprise-Abonnement, Hostingkosten stehen zusätzlich (Hosting-Optionen im Überblick).
- Legen Sie Repository und Branchnamen fest, bevor das Projekt entsteht.
- Verteilen Sie die Rollen Admin, Tester und Developer und entscheiden Sie, wer Zugriff auf Produktionsdaten braucht (Benutzer und Zugriffsgruppen).
- Beschreiben Sie den Weg Merge nach Staging, Prüfung, Merge nach Production und übertragen Sie Konfigurationen als XML-Datendateien (Automatisierte Tests).
- Vereinbaren Sie, wer Sicherungen herunterlädt, wo ein eigenes Archiv liegt und wie eine Wiederherstellung geprüft wird.
- Prüfen Sie vor der Inbetriebnahme Domain, CNAME sowie SPF und DKIM.