Skip to content

Keeping Production on odoo.sh

Production stays on odoo.sh. Odizy runs the rest from the same GitHub repository: a Test Server per feature branch, and Staging Servers that rehearse each upgrade on a copy of production.

Set it up

  1. Create an Application Definition from an osh one — odoo18-osh-template-v2 or odoo19-osh-template — pointed at your repository. See Odizy and odoo.sh.
  2. Connect GitHub to Muppy: an Incoming Webhook with the Github Webhook Decoder, and a webhook on the repository. See Connect your git provider.
  3. Turn the LXC CI/CD on, and add ^refs/tags/ to Branch exclusion Regex. See Setting Up LXC CI/CD.
  4. Create your Staging Server.

A push on the production branch changes nothing on Odizy: odoo.sh builds it.

Bring production data to staging

Muppy cannot read odoo.sh's backups by itself. Muppy support provides a shell script, in beta, that you run on odoo.sh to retrieve the production backup. Ask support for it: they tell you how to load the backup on your Staging Server.

Neutralize before you start

The restored database is a copy of production: its scheduled actions and outgoing mail servers run as soon as the application starts, and reach your real customers. Neutralize it first — Odoo's neutralize command disables them — then start the application.

Rehearse an upgrade

  1. Deploy the version to release on the Staging Server: Upgrade / Deploy, with the branch or ref odoo.sh will run. See Deploying Staging and Production.
  2. Read the deployment's database upgrade log, then test the application.
  3. Once it passes, merge into the production branch on odoo.sh, which builds and deploys it.