Odoo.sh (Hostingmodell): Definition und Zweigstufen

Rechtsstand: 14.10.2026 · Aktualisiert: 14.10.2026

Gilt für: Odoo 20.0 Enterprise; Odoo.sh als Hostingmodell mit Enterprise-Abonnementcode mit Odoo.sh oder Partnerschaftscode (Partner-Testprojekt); DACH-Lokalisierungen

Kurz gesagt

Odoo.sh ist das Hostingmodell von Odoo für Projekte aus einem GitHub-Repository: Odoo S.A. betreibt die Plattform, jeder Zweig erhält eine Datenbank (Dokumentation 20.0, Stand 14. Oktober 2026). Unterschied zu Odoo Online: Odoo.sh nimmt eigene Module und Apps-Store-Module mit eigenem Python-Code über das Repository auf, auf Odoo Online lässt die Apps-Store-FAQ nur reine Datenmodule ohne Python-Dateien zu; Odoo.sh verlangt dafür einen Enterprise-Abonnementcode. Für Deutschland, Österreich und die Schweiz nennen die geöffneten Seiten keine Abweichung.

Das Wichtigste

Hostingmodell von Odoo S.A.: Zweige liegen in einem GitHub-Repository, je Zweig eine Datenbank.
Drei Stufen: Produktion, Staging und Entwicklung (Dokumentation 20.0, Stand 14. Oktober 2026).
Voraussetzung in Deutschland, Österreich und der Schweiz: Enterprise-Abonnementcode mit Odoo.sh-Hosting; Partner starten mit ihrem Partnerschaftscode eine Testversion.
Grenze zu Odoo Online: Module mit eigenem Python-Code nimmt nur Odoo.sh oder ein eigener Server auf; auf Odoo Online lässt die Apps-Store-FAQ reine Datenmodule ohne Python-Dateien zu.
Staging-Zweig: neutralisierte Kopie der Produktivdatenbank; Odoo.sh löscht die Datenbank einen Monat nach dem Anlegen, danach müssen Sie den Zweig neu bauen (Rebuild).

Odoo.sh ist das Hostingmodell der Odoo-Unternehmenssoftware, bei dem Odoo S.A. die Anwendung auf einer eigenen Cloud-Plattform aus einem GitHub-Repository betreibt; aus den Zweigen des Repositorys baut die Plattform Datenbanken, die Sie im Browser öffnen.

Wozu Odoo.sh dient

Eigenen Code pflegen Sie in Git: Ein Push in einen Zweig startet einen Build, also eine Datenbank mit einem Odoo-Server auf dieser Revision. Die Dokumentation 20.0 nennt drei Stufen:

Stufe	Zweck	Datenbank
Produktion (Production)	der Echtbetrieb; genau ein Produktionszweig je Projekt	die Produktivdatenbank; ein Push aktualisiert den Server
Staging	Test mit den Daten des Echtbetriebs ohne Eingriff in die Produktivdaten	neutralisiertes Duplikat der Produktivdatenbank; Odoo.sh löscht die Datenbank einen Monat nach dem Anlegen, danach braucht der Zweig einen Rebuild
Entwicklung (Development)	entwickeln und automatisch testen	je Push eine neue Datenbank mit Demodaten; Unit-Tests laufen; die Datenbank ist für etwa drei Tage vorgesehen

Zweige verschieben Sie per Drag and Drop zwischen den Stufen; neutralisiert heißt: geplante Aktionen aus, E-Mails im Mail-Catcher, Zahlungs- und Versanddienste im Testmodus.

Unterschied zu Odoo Online

Odoo betreibt beide Modelle; sie unterscheiden sich an der Modulgrenze. Odoo Online ist laut Dokumentation 20.0 nicht mit eigenen Modulen und nicht mit Modulen aus dem Apps Store kompatibel. Odoo.sh nimmt beide über einen Zweig im Repository auf — für Module aus dem Apps Store verlangt die Store-FAQ ein privates Repository — und verlangt dafür einen Enterprise-Abonnementcode, der Odoo.sh beinhaltet. Die Gegenausnahme steht in der Store-FAQ: Auf Odoo Online lassen sich reine Datenmodule ohne Python-Dateien nutzen; ob ein einzelnes Modul dort verträglich ist, steht im Abschnitt Availability seiner Beschreibungsseite und kann von Version zu Version wechseln. Mehr zu Fristen: Leistungsumfang und Grenzen.

Beispiel

Ein Betrieb braucht ein Modul mit eigenem Python-Code: Er legt ein Projekt an, pusht das Modul in einen Entwicklungszweig, lässt die Tests laufen und zieht den Zweig auf Staging. Wer nur Standard-Apps nutzt, braucht das nicht (Hosting-Optionen).

Grundlage

Quellen sind die Odoo-Dokumentation 20.0 und die Odoo Apps FAQ, gelesen am 14. Oktober 2026. Den Hosting-Standort wählen Sie beim Bereitstellen; die Stufen hängen am Projekt, und die geöffneten Seiten nennen für Deutschland, Österreich und die Schweiz keine Abweichung.

Nicht zu verwechseln mit

Odoo Online: von Odoo gehostet, aber ohne Module mit eigenem Python-Code; reine Datenmodule ohne Python-Dateien lässt die Apps-Store-FAQ zu.
On-Premise: eigener Server, ebenfalls mit eigenen Modulen, aber eigener Wartung (Aufwand auf eigenem Server).
Odoo Enterprise: die lizenzpflichtige Edition; Odoo.sh ist die Hostingform dazu.
Testprojekt: ein Projekt zum Ausprobieren; darin setzt Odoo.sh Produktions- und Staging-Zweig nach 30 Tagen zurück (Staging-Branches).

Häufige Fragen

Kann ich Odoo.sh auch ohne eigenes Modul nutzen?

Ja. Das Formular Plattform bereitstellen verlangt nach der Dokumentation 20.0 vier Angaben: das GitHub-Repository, die Odoo-Hauptversion, einen Odoo-Enterprise-Abonnementcode mit Odoo.sh und den Hosting-Standort. Eigene Module sind ein Zusatz: Wer Community- oder eigene Module nutzt, legt sie in einen Zweig des Repositorys. Wer ausschließlich Apps ohne eigenen Code braucht, kann nach der Dokumentation auch Odoo Online wählen; dort sind eigene Module und Apps-Store-Module mit Python-Code ausgeschlossen, reine Datenmodule ohne Python-Dateien lässt die Apps-Store-FAQ zu.

Kann ich auf Odoo.sh mehrere Produktionszweige haben?

Nein. Die Dokumentation nennt genau einen Produktionszweig je Projekt; ziehen Sie einen Entwicklungszweig unter Produktion, erscheint eine Warnung, dass nur ein Produktionszweig möglich ist. Ein Staging-Zweig lässt sich unter Entwicklung verschieben, aber nicht unter Produktion. Den Produktionszweig können Sie nur unter Entwicklung ziehen; unter Staging ist mit ihm nur eine Zusammenführung möglich.

Bleiben Einstellungen erhalten, die ich in der Staging-Datenbank anklicke?

Nein. Beim Zusammenführen eines Staging-Zweigs in die Produktion übernimmt Odoo.sh nur den Quellcode; Änderungen in der Staging-Datenbank wandern nicht mit. Die Dokumentation rät, solche Einstellungen als XML-Datendatei im Zweig abzulegen oder von Hand in die Produktion zu übertragen.

Was passiert, wenn ein Push in den Produktionszweig fehlschlägt?

Odoo.sh springt automatisch zurück: Startet der Server mit der neuen Revision nicht oder bricht ein Modul-Update ab, verwendet die Plattform wieder die vorherige erfolgreiche Revision und rollt die Datenbank auf ihren vorherigen Stand. Das Protokoll der fehlgeschlagenen Aktualisierung steht im Zweig bereit.