Odoo mit Docker entwickeln - das Partner-Setup

Kurz vorweg - warum die offiziellen Odoo-Images der falsche Start für Entwicklung sind

Das offizielle Odoo-Docker-Image ist für den Produktivbetrieb gebaut, nicht für die Entwicklung. Für einen sauberen Prod-Container ist es ideal - für die tägliche Modul-Arbeit bremst es dich: kein Hot-Reload, umständliches Anhängen des Debuggers, langsames IO auf dem gemounteten Filestore.

Für die Entwicklung willst du das Gegenteil: Code-Änderung speichern, Odoo lädt neu, Breakpoint greift. Genau dafür gibt es zwei etablierte Docker-Muster - und ein Projekt-Layout, das nebenbei zu dem passt, wie deine Module später bei erpdock laufen. Wenn du Kundeninstanzen bei uns hostest, spart dir dieses Setup das klassische “läuft bei mir, aber nicht in Produktion”.

Für wen das hier ist: Odoo-Integratoren und Entwickler, die eigene Module bauen und die Instanzen ihrer Kunden bei erpdock betreiben. Du entwickelst, wir hosten - dieses Setup verbindet beides.

Zwei Wege: Devcontainer oder docker-compose

Es gibt zwei Muster für Odoo-Entwicklung mit Docker und VS Code. Beide funktionieren, sie unterscheiden sich darin, wo dein Editor sitzt:

Ansatz	Wo du arbeitest	Debugging	Wann sinnvoll
Devcontainer	im Container (VS Code hängt sich rein)	integriert, F5 startet Odoo im Debugger	schnellstes Setup, ein Kommando, gut für Einsteiger und einheitliche Teams
docker-compose	auf deinem Rechner, Odoo läuft im Container	remote via debugpy (attach)	mehr Kontrolle, näher am späteren Prod-Layout

Für ein Team, das oft dieselbe Umgebung aufsetzt, ist der Devcontainer der pragmatische Standard: .devcontainer-Ordner ins Repo, “In Container öffnen”, fertig. Wer es näher am Produktions-Layout mag, nimmt docker-compose. Der Rest dieses Artikels zeigt das compose-Muster, weil es die Verbindung zu Git und Staging am klarsten macht.

Die Projektstruktur, die zu erpdock passt

Halte alles unter einem Workspace, jeder Ordner mit klarer Rolle. Das ist nicht nur ordentlich - es spiegelt genau die Trennung, die dein Hosting bei uns später braucht:

extra_addons/ - deine eigenen Module. Das ist dein Git-Repo, das später auch die Kundeninstanz füttert.
odoo/ - der Odoo-Core als Git-Submodul, auf eine feste Version gepinnt (z.B. 19.0).
docker/ - deine docker-compose.yml und Overrides.
conf/ - odoo.conf für die Laufzeit.
scripts/ - Helfer für wiederkehrende Aufgaben (DB anlegen, Modul updaten).

Der entscheidende Punkt für Partner: Der gepinnte Core. Lokal entwickelst du gegen exakt die Odoo-Version, auf der die Kundeninstanz läuft - nicht gegen “irgendein 19.x von letzter Woche”. Bei erpdock ist der Odoo-Core pro Instanz auf einen festen Git-Stand gepinnt. Wenn deine lokale odoo/-Submodul-Version denselben Stand hat, entwickelst du gegen dieselbe Basis, die in Produktion läuft. Das ist der halbe Weg zu “keine Überraschungen beim Deploy”.

docker-compose: Postgres getrennt, Addons gemountet, Hot-Reload

Trenne Postgres in einen eigenen Container und mounte deine Module ins Odoo-Verzeichnis. So sieht das Grundgerüst aus:

services:
  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: odoo
      POSTGRES_PASSWORD: odoo
      POSTGRES_DB: postgres
    ports:
      - "5433:5432"   # 5433 vermeidet Kollision mit lokalem Postgres
    volumes:
      - odoo-db:/var/lib/postgresql/data

  odoo:
    image: odoo:19
    depends_on: [db]
    ports:
      - "8069:8069"
    volumes:
      - ./extra_addons:/mnt/extra-addons   # deine Module, live gemountet
      - ./conf:/etc/odoo
    command: odoo --dev=reload,qweb,xml

volumes:
  odoo-db:

Drei Dinge, die den Unterschied machen:

Getrennter Postgres auf Port 5433. Der Standard-Fehler ist, den System-Postgres auf 5432 anzusprechen - ein eigener Port erspart dir “connection refused”.
Addons gemountet nach /mnt/extra-addons. Odoo scannt diesen Pfad nach Ordnern mit __manifest__.py und findet deine Module automatisch. Änderungen am Host sind sofort im Container.
Hot-Reload gezielt: --dev=reload,qweb,xml. Nimm nicht --dev=all - das schaltet Dinge zu, die die Performance kosten. reload lädt Python-Änderungen nach, qweb und xml sparen dir Neustarts bei Templates und Views.

Nach einer Änderung an Python-Code greift der Reload; bei neuen Feldern oder Migrationen brauchst du weiterhin einen Modul-Update-Lauf (-u dein_modul).

Debugging mit debugpy und VS Code

Für echtes Breakpoint-Debugging hängst du dich mit debugpy an den laufenden Container. Zwei Schritte:

debugpy ins Image: pip install -U debugpy, dann Odoo über debugpy starten (python3 -m debugpy --listen 0.0.0.0:5678 ...) und den Port in compose freigeben.
launch.json mit attach und Pfad-Mappings. Das Mapping ist der Teil, an dem die meisten scheitern: VS Code muss die Host-Pfade auf die Container-Pfade übersetzen, sonst greift kein Breakpoint. Mappe deinen lokalen extra_addons-Ordner auf /mnt/extra-addons und die lokale Odoo-Quelle auf den Odoo-Pfad im Container.

Kleiner Tipp aus der Praxis: ipdb ist der angenehmere interaktive Debugger als das eingebaute pdb, und ein pre-commit-Hook mit black, isort und pylint-odoo hält den Code sauber, bevor er überhaupt ins Git kommt.

Vom lokalen Modul zur Kundeninstanz - der Weg über erpdock

Hier verbindet sich das lokale Setup mit dem Hosting. Der Ablauf, der Überraschungen vermeidet, ist immer derselbe - nur dass Staging bei uns eine echte Instanz ist, keine Kopie-Bastelei:

Lokal entwickeln gegen den gepinnten Core (siehe oben), mit Hot-Reload und Debugger.
In Git pushen. Deine Module leben in einem Repo - genau dem, aus dem die Kundeninstanz zieht.
Auf Staging ausrollen. Bei erpdock zieht die Instanz ihren Code aus deinem Git; eine Staging-Instanz spiegelt die Produktion. Du testest dort gegen echte Daten-Struktur, nicht gegen eine lokale Attrappe.
Nach Prod promoten, wenn Staging sauber ist. OCA-Module bindest du als Submodule ein - dieselbe Mechanik wie lokal.

Weil der Core pro Instanz gepinnt ist, testest du lokal, auf Staging und in Prod gegen dieselbe Odoo-Version. Ein späteres Versions-Upgrade planst du bewusst und pinnst danach neu - nicht durch einen unkontrollierten Sprung im Hintergrund.

Was du dir sparst - und was du behältst

Das Setup nimmt dir die Betriebslast ab, ohne dir die Kontrolle zu nehmen. Genau darum geht es im erpdock-Partner-Programm: du bleibst der Integrator und Entwickler, wir betreiben die Instanz.

Du behältst: deinen Code, dein Git, deine Modul-Hoheit, den direkten Draht zum Kunden.
Wir übernehmen: Server, Postgres-Tuning, Backups, TLS, Monitoring und den Deploy-Pfad von Git über Staging nach Prod.
Beide Seiten testen auf einer echten Staging-Instanz statt auf einer Kopie - dedizierte VMs, Hosting in Österreich.

Für die Community Edition gilt das genauso wie für Enterprise - die Dev-Umgebung ist dieselbe, nur die Lizenz-Frage unterscheidet sich. Und wenn du noch grundsätzlicher einsteigen willst: Wie sich Self-Hosting, Managed Hosting, odoo.sh und Odoo Online unterscheiden, sortiert der Überblick Odoo-Hosting verstehen.

FAQ

Kann ich das offizielle Odoo-Image auch für die Entwicklung nehmen? Ja, aber es ist auf Produktion optimiert - ohne Hot-Reload und mit umständlichem Debugger-Anschluss. Für die tägliche Modul-Arbeit lohnt sich ein Dev-Setup mit --dev=reload,qweb,xml und gemounteten Addons.

Devcontainer oder docker-compose - was soll ich nehmen? Devcontainer ist schneller aufgesetzt und gut für einheitliche Teams. docker-compose gibt dir mehr Kontrolle und liegt näher am Produktions-Layout. Beide funktionieren; entscheide nach Team-Größe und Debugging-Vorliebe.

Warum den Odoo-Core auf eine feste Version pinnen? Damit du lokal, auf Staging und in Produktion gegen dieselbe Odoo-Basis entwickelst. Bei erpdock ist der Core pro Instanz gepinnt - dein lokales Submodul auf denselben Stand zu setzen, verhindert “läuft bei mir, bricht in Prod”.

Wie kommt mein Modul auf die Kundeninstanz bei erpdock? Über Git: die Instanz zieht ihren Code aus deinem Repo, du testest zuerst auf einer Staging-Instanz und promotest dann nach Produktion. OCA-Module bindest du als Submodule ein.

Muss ich Postgres separat laufen lassen? In der Dev-Umgebung ja - ein eigener Postgres-Container auf einem abweichenden Port (z.B. 5433) erspart dir Kollisionen mit einem lokal installierten Postgres und hält die Daten in einem sauberen Volume.