Odoo deployment

git push. Odoo deploys.

Every branch of your Odoo repository is an instance. Push to it and CICDoo builds and deploys it on your own server, with a live log, a staging copy to test on and a backup behind it.

GitHub, GitLab.com or self-hosted GitLab. Community and Enterprise.

branch = instance

development

feature/*

merge

staging

staging

merge

production

main

The short answer

How Odoo deployment should work

A good Odoo deployment process has four properties. Code lives in Git and nothing is edited on the server. Every change runs on a staging copy of production before users see it. Deploying is one repeatable action, not a checklist someone follows at night. And there is a way back: a revert in Git, or a backup taken just before the change.

Most teams get there by writing scripts: a CI job that runs Odoo's tests, a deploy step that pulls the branch, updates modules with -u and restarts the service, and a cron that copies production into staging. It works until the person who wrote it leaves. The Odoo CI/CD with GitHub guide walks through that approach step by step.

CICDoo builds the same pipeline into the platform. Branches map to instances, instances belong to a stage, and a push to a branch deploys that instance on the server you assigned to its stage.

The pipeline

From commit to production, in stages

Development

One instance per feature branch. Fork a new one from any base branch in the console, build, try it, throw it away.

Staging

Merge into staging from the console and the staging instance deploys the result, so you test on something close to production.

Production

Merge staging into production when it is right. The production instance deploys, and a Soft Restart upgrades your modules.

Read how stages, branches and instances and merging work in the docs.

What you get

Deployment details that matter on a bad day

Deploys start on push

No button to remember. A push to an instance branch queues a Deploy job for that instance.

A queue with live logs

Deploys, restarts, backups and merges run as jobs with a status and a log that refreshes while it runs.

Soft and hard restarts

A Soft Restart restarts Odoo and upgrades modules; a Hard Restart restarts the container when something is stuck.

Merges from the console

Promote development to staging to production without leaving the browser, with permissions on who may merge.

A backup before you need it

Take an on-demand backup before a risky release and restore it in one action if the release goes wrong.

Your modules, your packages

Custom and OCA addons from the repository, extra Python and system packages, environment variables and a startup script per instance.

Side by side

Scripts you maintain, or a pipeline you use

DIY CI plus deploy scripts CICDoo
Instance per branch Hand-built per environment Automatic
Deploy trigger CI job or SSH session Push to the branch
Promote to staging and production Git merges plus a manual deploy Merge from the console
Module upgrades Remember to run -u Soft Restart
Deploy logs In the CI runner Live, per instance
Backup before release Separate script On demand, one click
Who can deploy Whoever has SSH Per-action workspace permissions

Running tests in CI? Keep them: CICDoo deploys from the same branches your CI tests. Migrating from Odoo.sh? See CICDoo vs Odoo.sh.

FAQ

Questions, answered

How do you deploy Odoo from Git?

Keep your custom modules in a Git repository, deploy a branch per environment, and on each deploy pull the branch, update the changed modules with odoo -u, and restart the Odoo service. With CICDoo a push to the branch does all of that for the instance that runs it.

What is the best CI/CD setup for Odoo?

Three stages (development, staging, production), tests running on every push with odoo --test-enable against a throwaway database, staging refreshed from a neutralised copy of production, and a deploy step that is one repeatable action. Add a backup before every production release.

Can I use GitHub Actions or GitLab CI with CICDoo?

Yes. Keep running tests and linters in your CI. CICDoo deploys from the same branches, so a merge that passes CI is the push that deploys.

How do I roll back an Odoo deployment?

Revert the commit in Git and push, and the instance redeploys the previous code. If a module upgrade already changed data, restore the backup taken before the release. Take one on demand before every risky release.

Does CICDoo support Odoo Enterprise deployments?

Yes. Community and Enterprise, 11.0 to the latest release, plus master. Enterprise needs a GitHub token with access to the enterprise addons repository.

Which Git providers are supported?

GitHub, GitLab.com and self-hosted GitLab.

Make the next release a git push

Connect a server, link your repository and deploy your first branch. Or plan it with an engineer.

No per-seat fees. Your servers stay yours.