Bevor Sie auch nur eine einzige App konfigurieren, müssen Sie festlegen, wo Ihre Odoo-19-Enterprise-Datenbank betrieben wird. Die Wahl des Hostings bestimmt, was Sie anpassen können, wer den Server kontrolliert, wie oft Sie upgraden müssen und wer für die Backups verantwortlich ist.
Odoo bietet drei Hosting-Wege: Odoo Online, Odoo.sh und On-Premise (Selbsthosting). Alle drei nutzen dieselben Enterprise-Standard-Apps, unterscheiden sich aber deutlich, sobald Sie eigenen Code, Serverzugriff oder einen bestimmten Upgrade-Rhythmus benötigen.
Ein Hinweis zu den Quellen: Dieser Leitfaden stützt sich auf die offizielle Odoo-Dokumentation für Version 19.0. Hosting-Regeln und Richtlinien können sich ändern. Prüfen Sie daher jeden für Ihr Projekt wichtigen Punkt in einer Testdatenbank und anhand Ihrer eigenen Abonnementbedingungen, bevor Sie sich festlegen.
Die drei Optionen in einer Minute
- Odoo Online: das Software-as-a-Service-Angebot von Odoo. Odoo betreibt die Server und die Plattform, und Sie arbeiten in den Standard-Apps und mit Studio.
- Odoo.sh: die offizielle Cloud-Plattform von Odoo für Hosting und Verwaltung von Odoo mit eigenem Code, verbunden mit einem GitHub-Repository und gegliedert in Entwicklungs-, Staging- und Produktions-Branches.
- On-Premise: Sie installieren und betreiben Odoo auf Ihrem eigenen Server oder auf einem gemieteten Cloud-Server und registrieren die Datenbank mit Ihrem Enterprise-Abonnementcode.
Anpassbarkeit: für die meisten Projekte das entscheidende Kriterium
Die Odoo-Dokumentation stellt klar, dass Odoo Online nicht mit eigenen Modulen und nicht mit Modulen aus dem Odoo Apps Store kompatibel ist. Auf Online konfigurieren Sie die Standard-Apps und können Anpassungen mit Studio erstellen, eigene Python-Module lassen sich jedoch nicht installieren.
Odoo.sh ist für eigenen Code ausgelegt. Sie pushen Ihre Module in einen Branch Ihres GitHub-Repositorys, und die Plattform erkennt automatisch Ordner, die Odoo-Module enthalten. Öffentlich verfügbare Community-Module lassen sich ebenfalls einbinden, zum Beispiel als Git-Submodule.
On-Premise bietet bei eigenen Modulen dieselbe Freiheit wie Odoo.sh, da Sie den Server und die geladenen Add-ons kontrollieren. Der Unterschied: Rund um den Code wird nichts für Sie verwaltet.
Eine praktische Faustregel: Gehören zu Ihren Anforderungen eigene Python-Entwicklungen oder Drittanbieter-Apps aus dem Apps Store, scheidet Odoo Online aus, und die eigentliche Entscheidung fällt zwischen Odoo.sh und On-Premise.
Kontrolle und Zugriff
Bei Odoo Online verwalten Sie die Datenbank über den Datenbankmanager von Odoo. Dort können Sie sie zu Testzwecken duplizieren, umbenennen, ein Backup herunterladen, ein verfügbares Upgrade starten, Domainnamen verwalten und die Eigentümerschaft übertragen. Server- oder Shell-Zugriff gibt es nicht.
Bei Odoo.sh bringt jeder Branch Entwicklerwerkzeuge im Browser mit: eine Web-Shell für grundlegende Linux-Befehle und psql, einen Online-Editor mit Python- und Odoo-Shell-Konsolen, SSH-Zugriff mit Ihrem eigenen Schlüssel sowie einen Mail-Catcher, der E-Mails aus Nicht-Produktions-Builds abfängt.
On-Premise bietet volle Kontrolle über Betriebssystem, PostgreSQL, Reverse Proxy und die Odoo-Konfigurationsdatei. Der Deployment-Leitfaden von Odoo versteht Sicherheit als fortlaufenden Prozess und nennt Aufgaben wie die Bereitstellung von Odoo über HTTPS hinter einem Reverse Proxy, das Setzen eines Datenbankfilters auf Servern mit mehreren Datenbanken, die Verwendung eines PostgreSQL-Benutzers ohne Superuser-Rechte und das Deaktivieren des Datenbankmanagers auf aus dem Internet erreichbaren Systemen.
Upgrade-Pflichten
Jede Hosting-Art bringt eine eigene Upgrade-Regel mit. Bei der Auswahl wird sie oft übersehen und später dringlich – legen Sie sie deshalb vom ersten Tag an auf den Tisch.
- Odoo Online: Laut der Upgrade-Dokumentation von Odoo muss eine Datenbank auf einer Hauptversion alle zwei Jahre upgegradet werden, eine Datenbank auf einer Nebenversion wenige Wochen nach Erscheinen der nächsten Version. Wird bis zum Stichtag nichts unternommen, führt Odoo das Upgrade der Datenbank automatisch durch.
- Odoo.sh: Nach den ersten drei Jahren Support für eine Version haben Sie weitere zwei Jahre Zeit, das Upgrade abzuschließen, und Sie werden benachrichtigt, wenn ein Upgrade erforderlich ist.
- On-Premise: Sie können unbegrenzt auf derselben Version bleiben. Odoo rät davon ab, denn kleinere Versionssprünge erleichtern Upgrades.
Eigene Module betreffen jede Option außer Online. Odoo stellt klar, dass eine Datenbank mit eigenen Modulen erst upgegradet werden kann, wenn diese Module für die Zielversion verfügbar sind, und dass die Herstellung der Kompatibilität in der Verantwortung des jeweiligen Modul-Maintainers liegt.
Bei Odoo Enterprise umfasst der Upgrade-Service die Standard-Apps, Studio-Anpassungen, solange Studio installiert und das Abonnement aktiv ist, sowie Entwicklungen, die durch ein Abonnement zur Wartung von Anpassungen abgedeckt sind. Nicht abgedeckt sind eigene oder Drittanbieter-Module ohne einen solchen Vertrag, die Bereinigung vorhandener Daten und Schulungen.
Der empfohlene Ablauf ist auf jeder Plattform gleich: eine upgegradete Testdatenbank anfordern, eigene Module aktualisieren, gründlich testen, Probleme an Odoo melden und dann das Produktions-Upgrade planen, während dessen die Datenbank nicht verfügbar ist.
Backups und Testkopien
Odoo Online: Laut Dokumentation werden im Rahmen des Odoo Cloud Hosting SLA täglich Backups erstellt. Zusätzlich können Sie im Datenbankmanager ein Backup als ZIP herunterladen; ist die Datenbank dafür zu groß, stellt der Odoo-Support einen anderen Weg bereit.
Odoo.sh: Die Produktionsdatenbank wird jeden Tag automatisch gesichert, und jedes Backup enthält den Datenbank-Dump, den Filestore, Logs und Sessions. Die Dokumentation nennt sieben tägliche, vier wöchentliche und drei monatliche Backups; dedizierte Backup-Server halten zusätzliche monatliche Kopien vor. Außerdem können Sie manuelle Backups von Produktions- und Staging-Builds erstellen.
Staging- und Entwicklungs-Builds auf Odoo.sh werden nicht automatisch gesichert. Staging-Datenbanken sind neutralisierte Duplikate der Produktion, die nach einiger Zeit entfernt werden, und Entwicklungsdatenbanken sind kurzlebig und basieren auf Demodaten – bewahren Sie echte Arbeit daher nie ausschließlich dort auf.
On-Premise: Backups liegen vollständig in Ihrer Verantwortung. Planen Sie Backups sowohl der PostgreSQL-Datenbank als auch des Filestores, lagern Sie Kopien außerhalb des Servers und testen Sie Wiederherstellungen regelmäßig.
Unabhängig von der gewählten Option sind Upgrade-Testdatenbanken und Staging-Datenbanken auf Odoo.sh neutralisiert: Geplante Aktionen sind deaktiviert, ausgehende E-Mails werden abgefangen oder ersetzt, und Zahlungs- und Versandkonnektoren laufen im Testmodus. Das schützt die Produktion, doch Integrationen müssen bewusst wieder aktiviert werden, wenn Sie sie testen möchten.
Kostentreiber vergleichen – ohne Preisliste
Preise hängen von Ihrem Vertrag ab und ändern sich mit der Zeit. Vergleichen Sie daher, was die Kosten treibt, statt Listenpreise.
- Abonnementumfang: Odoo.sh erfordert einen Enterprise-Abonnementcode, der Odoo.sh-Hosting einschließt, während On-Premise ein auf Ihrem eigenen Server registriertes Enterprise-Abonnement nutzt, mit einer verknüpften Datenbank pro Abonnement.
- Benutzer: Eine On-Premise-Datenbank muss innerhalb der Benutzeranzahl ihres Abonnements bleiben; eine Überschreitung löst eine Warnung und eine begrenzte Frist zur Korrektur aus, bevor die Datenbank abläuft.
- Infrastruktur: Auf Odoo.sh dimensionieren Sie Worker, Speicher und Staging-Builds innerhalb der Plattform; On-Premise zahlen Sie Server, Speicher, Bandbreite und Monitoring selbst, und der Server muss dauerhaft Netzwerkzugang zum Validierungsdienst von Odoo haben.
- Personal: On-Premise braucht jemanden, der Linux, PostgreSQL, HTTPS und Sicherheitsupdates administrieren kann; Odoo.sh braucht Entwickler, die sicher mit Git umgehen; Odoo Online braucht beides nicht.
- Lebenszyklus der Anpassungen: Jedes eigene Modul muss gewartet und bei jedem Upgrade portiert werden – auf Odoo.sh und On-Premise ein wiederkehrender Kostenfaktor, sofern dies nicht durch ein Wartungsabonnement abgedeckt ist.
Für wen sich welche Option eignet
Odoo Online eignet sich für Unternehmen, die mit Standard-Odoo plus Studio arbeiten können, den schnellsten Start wünschen und mit dem Upgrade-Zeitplan von Odoo einverstanden sind. Typische Kandidaten sind Handels-, Dienstleistungs- und Einzelhandelsunternehmen mit Standardprozessen.
Odoo.sh eignet sich für Projekte, die eigene Module oder Drittanbieter-Apps benötigen, aber keine Server betreiben wollen, und die Wert darauf legen, jede Änderung vor dem Livegang auf einer Staging-Kopie der Produktion zu testen.
On-Premise eignet sich für Organisationen mit eigener IT-Abteilung, strengen Anforderungen an Datenstandort oder Netzwerk, Integrationen mit lokaler Hardware oder dem Bedarf, genau selbst zu bestimmen, wann Upgrades stattfinden.
Wenn Sie Odoo Community in Betracht ziehen, beachten Sie: Odoo.sh erfordert einen Enterprise-Abonnementcode, und der oben beschriebene kostenlose Upgrade-Service ist eine Enterprise-Leistung. Community wird daher in der Regel selbst gehostet und in Eigenregie upgegradet.
Enterprise ist keine eigene Codebasis: Die Installationsdokumentation von Odoo beschreibt das Enterprise-Repository als Sammlung zusätzlicher Add-ons auf Basis von Community, sodass eine selbst gehostete Enterprise-Installation beides benötigt. Ein späterer Wechsel von Community zu Enterprise ist ein eigenes Projekt, denn die Upgrade-Dokumentation von Odoo behandelt einen Editionswechsel nicht als Teil eines Upgrades.
Späterer Wechsel zwischen Hosting-Arten
Die Entscheidung ist nicht endgültig, doch ein Wechsel ist in manche Richtungen einfacher als in andere.
- Von Odoo Online zu Odoo.sh oder On-Premise: Laden Sie im Datenbankmanager ein Backup herunter und importieren oder stellen Sie es wieder her. Online-Zwischenversionen werden anderswo nicht unterstützt, daher müssen Sie eventuell zuerst auf die nächste Hauptversion upgraden.
- Von Odoo.sh oder On-Premise zu Odoo Online: Alle nicht standardmäßigen Apps müssen zunächst in einem Staging-Build oder einer duplizierten Datenbank deinstalliert werden; die Migration selbst wird über ein Ticket beim Odoo-Support beantragt.
- Von On-Premise zu Odoo.sh: Nutzen Sie den Import im Reiter „Backups“ des Produktions-Branches. Der Import benötigt freien Speicherplatz in Höhe des Vierfachen der Dump-Größe, überschreibt die aktuellen Daten des Branches und deaktiviert ausgehende Mailserver und geplante Aktionen, bis Sie die benötigten wieder aktivieren.
Eine Checkliste für die Entscheidung
- Benötigen wir jetzt oder absehbar ein eigenes Python-Modul oder ein Modul aus dem Apps Store? Falls ja, Odoo Online ausschließen.
- Können wir den verpflichtenden Upgrade-Zeitplan von Odoo Online akzeptieren, oder brauchen wir mehr Kontrolle darüber, wann jeder Versionswechsel erfolgt?
- Brauchen wir eine Staging-Kopie der Produktion, um jede Änderung vor dem Livegang zu testen?
- Haben wir Personal – oder können wir es einstellen –, das Linux, PostgreSQL, HTTPS, Monitoring und Sicherheit für einen On-Premise-Server betreut?
- Gibt es Vorgaben zu Datenstandort, Netzwerk oder Hardware, die einen eigenen Server erfordern?
- Wer ist für die Prüfung der Backups und für Wiederherstellungstests zuständig, und wie oft werden sie durchgeführt?
- Wer wartet und portiert unsere eigenen Module bei jedem Upgrade, und ist das durch ein Wartungsabonnement abgedeckt?
Wie 1CBMS Sie unterstützen kann
1CBMS unterstützt Unternehmen in Ägypten und im Irak dabei, vor Beginn der Implementierung das passende Odoo-Hosting zu wählen. Wir gleichen Ihre Anforderungen mit den Möglichkeiten jeder Plattform ab, erkennen den Bedarf an eigenen Modulen frühzeitig, richten Odoo.sh-Projekte oder On-Premise-Server mit soliden Backup- und Sicherheitspraktiken ein und planen Upgrades so, dass Ihr Odoo-19-Enterprise-System im Support bleibt. Kontaktieren Sie uns über www.1cbms.com, um Ihren Fall zu besprechen.