How to Set Up GitOps for Odoo: A Practical Guide

GitOps means your Git repository is the source of truth for what runs, and a push is the deploy. For Odoo that is a genuinely nice workflow — but Odoo has enough quirks that a naïve 'git pull and restart' will bite you. Here is a practical shape that holds up, and how ERPForge implements each piece so you don't have to.

1. Lay out the repository

Keep your custom modules in one repository, one directory per module, each with its own __manifest__.py. Map a branch to an environment — main to production, a staging branch to staging — so a push to a branch is an unambiguous instruction about where the code should go.

2. Trigger on push with a webhook

A push should notify your platform immediately, not on a polling timer. A Git webhook does this. Two things matter: verify the webhook signature (an HMAC over the payload) so nobody can trigger fake deploys, and respond fast — do the actual build in the background and return right away, or the provider will time out and retry, and you'll build twice.

3. Build safely — fail without breaking production

This is the step teams skip, and it is the one that matters most. Before you touch the running instance, validate the new code. Compile every module's Python in memory — do not write .pyc files into a shared volume, which can be root-owned and fail for the wrong reason. Only if everything compiles do you promote it.

The payoff: a bad commit fails the build with the exact file and line, and the live instance keeps serving the last known-good code instead of crash-looping.

models/harmonium_tuning.py, line 227: invalid syntax
    def broken(:
> instance untouched — still serving a1c39f4

4. Reload Odoo, not just the files

Once code is promoted, Odoo needs to pick it up: restart the process and update the module list so new or changed modules are recognised. Get the addons path right or the modules simply won't appear. Respect worker settings too — reports quietly break if the worker configuration can't render PDFs.

5. Make it observable

A deploy you can't see is a deploy you can't trust. You want a build status per push (success or failed, with the error), and a live tail of the Odoo logs with level filters and search so you can find an error without scrolling. Backups belong here too — scheduled, and actually restore-tested.

Don't build this five times

Every item above is undifferentiated platform work. ERPForge implements the whole loop — signed webhooks, background builds, in-memory compile gate, safe promotion, Odoo reload, build status and live logs — for both Community and Enterprise. If you're comparing managed options, read ERPForge vs Odoo.sh; if you're on Community specifically, start with Odoo Community hosting.