Auto Image Updates

OEC.sh can automatically pull the latest Odoo base image and update your running environments on a schedule. When the update runs, the platform pulls the new image, recreates your Odoo container, and verifies it starts successfully. If the new image fails to start, the system automatically rolls back to the previous image.

Why Use This

Odoo releases security patches, bug fixes, and minor improvements as updates to its base Docker image. Without auto-updates, you would need to manually trigger a redeploy each time a new image is available. Auto Image Updates automate this:

• Security patches — pick up fixes to the base OS and Python dependencies as soon as they ship
• Bug fixes — Odoo often back-ports fixes to the running version (e.g., 17.0, 18.0) without a version bump
• Predictable maintenance windows — schedule updates during off-peak hours when users are not active
• Safe by default — automatic rollback if the new image fails to start

Enabling Auto Image Updates

1. Open your environment
2. Go to Settings → Auto Image Update
3. Turn on Enable scheduled image update
4. Set your schedule (cron expression, UTC)
5. Choose whether to run module upgrades
6. Click Save

The next update will run at the next occurrence of your schedule. This applies to every server connected to OEC.sh, including servers you own or that were provisioned inside your own cloud account: enabling the schedule on an environment is your consent for the platform to recreate that environment's Odoo container at the scheduled time. Leave it off and nothing touches the container until you click Update Now.

Schedules must be at least 6 hours apart. Module upgrades (step 5) run -u all against your database after the new image starts; on servers you own, scheduled runs skip that step for now and only swap the image, so run module upgrades from Update Now when you are watching, ideally after testing the new image on staging.

Schedule

The schedule is a standard 5-field cron expression in UTC:

minute  hour  day-of-month  month  day-of-week
  0      3        *           *         0

The default is Sunday at 3:00 AM UTC (0 3 * * 0).

Common schedules:

Module Upgrades

When Run module upgrades is enabled (the default), the platform runs:

odoo -c /etc/odoo/odoo.conf --no-http --stop-after-init --update all

before recreating the container. This upgrades module schemas to match any changes in the new image. It adds 10–30 minutes to the update process but keeps your modules in sync.

Disable module upgrades only if you manage module upgrades manually or if your modules are known to have no schema dependencies on the base image. For most environments, leaving it enabled is the safer choice.

Rollback on Failure

If the new image fails to start (for example, a container crash or failed health check), the platform automatically:

1. Detects the failure
2. Pulls the previous image tag
3. Recreates the container from the previous image
4. Marks the update as rolled_back in the status

Your environment continues running on the previous image. The next scheduled update will try again with whatever is latest at that point.

Monitoring Updates

The Image Update settings panel shows:

No change means the image was already up to date — the platform checked but found no newer version.

Manual Trigger

You can trigger an image update outside the schedule. Open the environment, go to Settings, expand Auto Image Update and click Update Now. This runs the same process as the scheduled update: pull latest, run module upgrades if enabled, recreate container, roll back on failure. Because it recreates the container, Update Now needs the same permission as a deploy.

Freeze a Build

An environment follows the stable image of its Odoo version, for example odoo:18.0. Odoo publishes new builds of that image over time, so any deploy (including one you run for an unrelated change) can move the environment onto a newer build.

If you want an environment to stay on the exact build it runs today, freeze it:

1. Open the environment and go to Settings → Build
2. Check the version and the short build id shown there
3. Click Freeze this build and confirm

Nothing restarts. From then on, every deploy and Update Now uses that exact build, and scheduled image updates have no effect while the environment is frozen.

To move on, click Unfreeze build. The environment follows the stable image again from the next deploy or Update Now, which is the moment you choose to take the newer build. A good routine is to unfreeze staging first, update it, test, then do the same on production.

The Build section shows the dated version Odoo publishes for the build, for example 18.0-20260817. That is the same tag on Docker Hub (odoo:18.0-20260817), so you can pull exactly that build to test locally.

To run a specific dated build, click Choose a specific build, pick one from the list and confirm. The environment is frozen on that build and switches to it on the next deploy or Update Now; nothing restarts until then. Picking a build older than the one running can break modules you updated since, so try it on staging first.

Best Practices

For production environments

• Schedule updates for your lowest-traffic window (usually late night or weekend)
• Enable module upgrades — it adds time but prevents schema drift
• Review the update status the next day to confirm success

For development environments

• Use a more frequent schedule (daily) to stay close to the latest image
• Disable module upgrades if you are iterating on schema changes yourself

For staging environments

• Match your production schedule offset by a few hours — this lets staging test the new image before production sees it