Zodoo (formerly Wodoo) is a developer-centric Docker framework for Odoo, built and maintained by Zebroo. It bundles Odoo, Postgres and the surrounding tooling into a reproducible, container-based workflow, so you can spin up, debug and update Odoo projects with a handful of CLI commands instead of wrestling with manual virtualenvs, system Python versions and ad-hoc Docker configurations. In short, Zodoo is the productivity layer between you and Odoo.
When to use Zodoo
Zodoo is the right choice when you need to run an Odoo instance locally for development, testing or demoing without polluting your host system; reproduce production environments consistently across Mac, Windows (WSL2) and Linux dev machines; iterate quickly on custom modules with built-in support for code reload, demo data and database resets; wire Odoo into CI/CD pipelines (together with zCICD and zSYNC) for automated tests, builds and deployments; or manage multiple Odoo projects on the same machine, each with its own version, port and Postgres database. If your goal is simply to call an Odoo API from a Python script, you don’t need Zodoo — use Odoo’s native XML-RPC / JSON-RPC or a thin client library. Zodoo’s value lies in running and managing the Odoo instance itself.
Core concept
Zodoo wraps a standard Odoo deployment in a Docker Compose stack and exposes a single CLI (odoo) that orchestrates the Odoo server container with the Python version your project requires, a Postgres container with sane defaults for development, and auxiliary services such as cron, queue jobs and asset compilation, all configured automatically from your project’s manifest. All project state — selected Odoo version, port, demo flag, Python version and so on — lives under ~/.odoo/settings.<project-name>, so each project on your machine stays independent and reproducible.
Quick start
The high-level workflow is the same on every supported OS. First, install Zodoo from the official installer (it registers a global odoo CLI on your machine via pipx). Next, initialise a project inside your Odoo repo with odoo init . and pick the Odoo version (e.g. 16.0, 17.0 or 18.0). Then bootstrap and run the project: odoo reload regenerates docker-compose from your manifest, odoo build builds the Docker images, odoo up -d starts Odoo and Postgres in the background, odoo -f db reset initialises the database (with demo data if ODOO_DEMO=1), and odoo update installs or upgrades the modules listed in MANIFEST. Finally open Odoo at the URL shown by odoo status (default credentials are admin / admin). For step-by-step OS-specific guides, see Local Odoo Development Setup on Mac and Local Odoo Development Setup on Windows; on Linux, follow the Windows/WSL guide from step 4 onward.
Common commands
The odoo CLI is the single entry point for everything. For project lifecycle use odoo init . to initialise a new project, odoo reload to regenerate docker-compose and project settings (add —demo to enable demo data for every module, and run it any time settings or module dependencies change), odoo build to build the Docker images, and odoo next to pick the next available host port when running multiple projects in parallel. For running and debugging use odoo up -d to start all containers in the background, odoo status to print the URL, DB info, default credentials and feature flags, and odoo dev to recreate the containers in dev mode for interactive debugging. For database management use odoo -f db reset to drop and recreate the Postgres DB (loading demo data when ODOO_DEMO=1), odoo -f restore odoo-db <dump-path> to restore a customer dump, and odoo restore-web-icons to repair broken ir.attachments links after a restore. For modules and code use odoo update to install or upgrade every module listed in your MANIFEST and odoo update <module_name> for a faster targeted update. For configuration use odoo config —full to print the full effective config, odoo setting POSTGRES_VERSION 17 and odoo setting ODOO_PYTHON_VERSION 3.12 to pin the database and Python interpreter (followed by odoo reload + odoo build), odoo setting DEVMODE=1 -s to enable development mode globally, and odoo setting ODOO_DEMO=1 to tell the next db reset to load demo data. Run odoo —help or odoo <command> —help for the full reference.
Developer tips and best practices
Learn Odoo’s APIs first — Zodoo orchestrates Odoo, it doesn’t replace it; the ORM, security model and view system you debug inside the container are vanilla Odoo. Always pin your versions by setting ODOO_PYTHON_VERSION and POSTGRES_VERSION explicitly, so your team and CI run the exact same stack you do. Use one project per repo and don’t share ~/.odoo/settings.* between projects — let odoo init and odoo next keep them isolated. Run heavy operations in the background: odoo up -d together with odoo logs is friendlier than blocking your terminal. Wrap Zodoo in CI — the same commands you use locally (odoo reload, odoo build, odoo update) are the building blocks of zCICD pipelines, so keep your local and CI workflows symmetrical. Reset early and reset often: odoo -f db reset is fast and gives you a clean state, much better than chasing migration bugs in a stale local DB. Whenever you change module code (Python, XML views, security rules, data files, etc.), remember to run odoo update so the changes are loaded into the running database; pure Python changes can often be picked up live in dev mode (odoo dev), but structural changes always require odoo update.
Resources
GitHub repository: github.com/Odoo-Ninjas/zodoo
Use the other articles in this category for deeper guides on the VS Code Extension, the Zodoo registry, debug mode, OS-specific setup, benchmarks and quick-start instructions for both Community and Enterprise instances of Odoo.