Wer auf Odoo.sh entwickelt, testet und deployt, sollte eine aktuelle Plattformänderung unbedingt kennen: Staging-Datenbanken werden ab sofort nach nur 30 Tagen automatisch gelöscht. Bisher lag die Frist bei 90 Tagen – Odoo hat sie ohne große Vorankündigung auf einen Monat verkürzt. Die Änderung betrifft alle Odoo.sh-Projekte, unabhängig vom Abo-Tier oder der Odoo-Version.
In diesem Beitrag erklären wir, was genau sich geändert hat, warum Odoo diesen Schritt geht, wie die Community reagiert – und welche Best Practices wir als Odoo Gold Partner unseren Kunden empfehlen.
Was hat sich konkret geändert?
Die offizielle Odoo-Dokumentation wurde kürzlich aktualisiert und stellt klar:
„Databases created for staging branches are automatically deleted after one month. To use the branch again, you must rebuild it."
Wichtig dabei: Es handelt sich um eine harte Plattform-Policy. Kein Abo-Tier, keine Einstellung und kein Workaround auf Plattformebene können diese automatische Löschung deaktivieren. Der Branch selbst bleibt erhalten – nur die zugehörige Datenbank wird entfernt und muss bei Bedarf neu aufgebaut werden.
Die Dokumentation wurde per Pull Request #17738 auf GitHub aktualisiert und bestätigt diese Änderung offiziell.
Die drei Branch-Typen auf Odoo.sh im Überblick
Um die Änderung richtig einzuordnen, lohnt sich ein Blick auf die drei Branch-Stufen, die Odoo.sh anbietet:
Production Branch
Der Production Branch ist die Live-Umgebung mit echten Geschäftsdaten und Benutzern. Diese Umgebung wird dauerhaft betrieben und von Odoo.sh automatisch gesichert – mit sieben täglichen, vier wöchentlichen und drei monatlichen Backups. Es gibt immer genau einen Production Branch pro Projekt.
Staging Branches
Staging Branches dienen als temporäre Testumgebungen, die in der Regel auf einer neutralisierten Kopie der Produktionsdatenbank basieren. Sie werden typischerweise für Qualitätssicherung, User Acceptance Tests (UAT) oder Upgrade-Validierungen eingesetzt. Staging-Datenbanken werden nicht automatisch gesichert – manuelle Backups sind jedoch möglich (bis zu fünf pro Tag). Ab sofort gilt: Die Staging-Datenbank wird nach 30 Tagen automatisch gelöscht. Bei Trial-Projekten werden Staging Branches ebenfalls nach 30 Tagen auf den Development-Stage zurückgesetzt.
Development Branches
Development Branches sind kurzlebige Entwicklungsumgebungen, die bei jedem neuen Commit eine frische Datenbank mit Demo-Daten erstellen. Sie dienen ausschließlich der technischen Entwicklung, dem Bugfixing und dem Ausführen von Unit Tests. Auch hier gibt es keine automatischen Backups.
Warum macht Odoo das?
Odoo kommuniziert die Gründe nicht im Detail, aber aus der Plattformarchitektur und den offiziellen Dokumentationsänderungen lassen sich klare Motive ableiten:
Staging ist per Design temporär. Odoo behandelt Staging-Umgebungen als kurzlebige, disposable Environments – nicht als persistente Systeme. Sie sollen neue Features unter produktionsnahen Bedingungen testen, ohne die Live-Datenbank zu gefährden.
Ressourcenoptimierung. Durch das automatische Ablaufen werden ungenutzte Serverressourcen freigegeben. Das hält die Plattformleistung für alle Nutzer aufrecht – besonders relevant, da Odoo.sh eine Shared-Infrastructure-Plattform ist.
Datenaktualität erzwingen. Eine Staging-Datenbank ist ein Snapshot der Produktion zu einem bestimmten Zeitpunkt. Nach wenigen Wochen weicht dieser Snapshot erheblich von der aktuellen Produktion ab: neue Transaktionen, Kundendaten, Lagerbewegungen, Buchungen. Tests auf veralteten Kopien liefern potenziell irreführende Ergebnisse. Die erzwungene Neuerstellung sorgt dafür, dass Tests auf frischen, aktuellen Daten basieren.
Backup-Policy unterstreicht die Philosophie. Odoo stellt in der Dokumentation ausdrücklich klar, dass weder Staging- noch Development-Builds für persistente Datenspeicherung vorgesehen sind – und dass Odoo keine Backups für diese Umgebungen garantiert oder Recovery sicherstellt.
Was sagt die Community?
Die Verkürzung von 90 auf 30 Tage hat in der Odoo-Community für erhebliche Diskussionen gesorgt. In den offiziellen Odoo-Foren häufen sich seit Mai 2026 die Beiträge – mit über 1.300 Views allein auf den ersten Thread zum Thema.
Die häufigsten Kritikpunkte aus der Community im Überblick:
Lange UAT-Zyklen werden erschwert. Viele Implementierungsprojekte haben Abnahmezyklen, die deutlich länger als 30 Tage dauern. Wenn Kunden Features über Wochen testen und freigeben, ist eine automatische Löschung der Testumgebung mitten im Prozess problematisch.
Man zahlt für den Storage – und verliert ihn. Mehrere Community-Mitglieder weisen darauf hin, dass Staging Branches im Abo enthalten sind und der Storage separat bezahlt wird. Die erzwungene Löschung trotz laufender Zahlung wird als widersprüchlich empfunden.
Keine Konfigurationsmöglichkeit. Besonders frustrierend für viele Nutzer: Es gibt keinen Schalter, kein Premium-Feature und kein Abo-Upgrade, das die Frist verlängern oder deaktivieren könnte. Die Policy ist plattformweit hart kodiert.
Versionsmanagement wird komplizierter. Entwicklungen, die Monate bis zur Freigabe brauchen, erfordern nun ein regelmäßiges manuelles Backup-und-Restore-Verfahren – zusätzlicher Aufwand, der nicht automatisiert werden kann.
Kommunikation kam zu kurz. Selbst Odoo-Mitarbeiter bestätigten im Forum, dass die interne Kommunikation zur Änderung von 90 auf 30 Tagen nicht erklärte, warum die Frist verkürzt wurde. Für ein Feature, das aktive Projekte direkt betrifft, hätten sich viele eine transparentere Ankündigung gewünscht.
Auf der anderen Seite argumentieren einige Community-Mitglieder, dass die Änderung operativ Sinn ergibt: Frischere Daten, sauberere Testumgebungen und weniger Abhängigkeit von veralteten Snapshots. Was auf den ersten Blick wie eine Einschränkung wirkt, kann bei richtiger Einbindung in den Workflow auch eine Verbesserung sein.
Unsere Empfehlungen als Odoo Gold Partner
Als langjähriger Odoo Gold Partner begleiten wir bei Datenpol zahlreiche Kunden auf Odoo.sh. Aus unserer Projekterfahrung empfehlen wir folgende Best Practices:
Manuelle Backups vor dem Ablauf erstellen. Odoo.sh erlaubt bis zu fünf manuelle Staging-Backups pro Tag. Sichern Sie Ihre Testdaten rechtzeitig, bevor die 30-Tage-Frist abläuft.
Rebuild-und-Restore als Routine etablieren. Der Branch kann jederzeit neu gebaut und ein zuvor gesichertes Backup wiederhergestellt werden. Das setzt den 30-Tage-Timer zurück. Planen Sie diesen Zyklus fest in Ihren Projektablauf ein.
UAT-Phasen realistisch planen. Berücksichtigen Sie die 30-Tage-Frist von Anfang an in der Projektplanung. Strukturieren Sie Abnahmezyklen in kürzere Iterationen, anstatt monatelange Tests auf einer einzigen Staging-Umgebung durchzuführen.
Testkonfigurationen dokumentieren. Halten Sie Setup-Schritte, Testdaten und spezielle Konfigurationen so fest, dass eine Staging-Umgebung jederzeit schnell und reproduzierbar neu aufgesetzt werden kann.
Staging nicht als Dauerlösung nutzen. Die Plattform ist darauf ausgelegt, dass Staging temporär bleibt. Workflows, die eine persistente Testumgebung voraussetzen, sollten überdacht und an die Plattformphilosophie angepasst werden.
Fazit
Die Verkürzung der Staging-Lebensdauer auf 30 Tage ist eine relevante Änderung für alle Odoo.sh-Nutzer. Wer seinen Workflow entsprechend anpasst – mit regelmäßigen Backups, geplanten Rebuild-Zyklen und dokumentierten Testkonfigurationen – kann die Einschränkung gut managen. Gleichzeitig ist die Kritik aus der Community nachvollziehbar: Mehr Transparenz in der Kommunikation und eine optionale Verlängerung für zahlende Kunden wären wünschenswerte Verbesserungen.
Odoo.sh: Staging Branches werden nach 30 Tagen automatisch gelöscht – was Sie jetzt wissen müssen