Odizy and odoo.sh¶
Odizy runs an odoo.sh repository as it is: same GitHub repository, same layout, no file to add. This page maps odoo.sh to Odizy. Two pages follow from it:
- Keeping Production on odoo.sh — Odizy serves development, test and staging, odoo.sh keeps production.
- Migrating from odoo.sh — production moves to Odizy.
The osh Application Definitions¶
An odoo.sh repository holds Odoo addons at its root. The osh Application Definitions are built for that layout:
| Application Definition | Odoo |
|---|---|
odoo18-osh-template-v2 |
18.0 |
odoo19-osh-template |
19.0 |
On a server built from one of them:
- the repository is cloned into
user_addons, inside the application directory, and that directory is on the addons path; requirements.txt, at the root of the repository, is installed;- the application runs as two services: the web server (
gui) and the scheduled actions (cron).
Muppy adds two files to the clone when the repository has none: .muppy/mpy_setup.sh, the
build procedure, and .muppy/buildit.jsonc, the build recipe. They show as untracked files in
the clone. Commit your own .muppy/buildit.jsonc to change the recipe; see
How Odoo Servers Are Built.
Submodules¶
Submodules are cloned with the repository and updated at each deployment. Only the root of
the repository is on the addons path, though. When addons sit inside a submodule, declare its
folder in your .muppy/buildit.jsonc as a type: local addon; see
Adding addons.
How odoo.sh maps to Odizy¶
| odoo.sh | Odizy |
|---|---|
| The production branch | The Application Definition's Default branch / depth, run by Production Servers. They are deployed by hand. |
| A staging branch | The Default Staging branch, run by Staging Servers. They are deployed by hand. |
| A development branch, built at each push | A feature branch. Each developer who pushes on it gets a Test Server, deployed at each push. |
| A build | A deployment: code updated, builder run, database backed up and upgraded, application restarted. Its record is on the App Server, page Upgrades. |
| Staging built from a copy of production | A Staging Server whose database you restore from a production backup. |
| The web shell and editor | The browser IDE (Code Server) and SSH. See Accessing Your Servers. |
| Daily backups | Muppy's database backups, kept in an S3 bucket. |
| The project's GitHub integration | A webhook declared on the GitHub repository. See Connect your git provider. |
Three differences to plan for:
- Pull requests build nothing. A Test Server follows a branch: pushing on the branch of a pull request deploys it.
- Staging and Production are deployed by hand, when you choose. See Deploying Staging and Production.
- A copy of production stays live. odoo.sh neutralizes the database of a staging build. Odizy restores it as it is: its scheduled actions and outgoing mail servers run as soon as the application starts. Neutralize the database before starting the application.
The pipeline itself is described in How LXC CI/CD Works.