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.
Auto Image Updates are disabled by default. You opt in per environment.
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
- Open your environment
- Go to Settings → Image Update
- Turn on Enable scheduled image update
- Set your schedule (cron expression, UTC)
- Choose whether to run module upgrades
- Click Save
The next update will run at the next occurrence of your schedule.
Schedule
The schedule is a standard 5-field cron expression in UTC:
minute hour day-of-month month day-of-week
0 3 * * 0The default is Sunday at 3:00 AM UTC (0 3 * * 0).
Common schedules:
| Schedule | Cron | Notes |
|---|---|---|
| Sunday 3 AM UTC (default) | 0 3 * * 0 | Weekly, low-traffic time |
| Every night at 2 AM UTC | 0 2 * * * | Daily, picks up patches quickly |
| First Monday of month at 1 AM UTC | 0 1 * * 1#1 | Monthly maintenance window |
All times are UTC. Convert to your local timezone when planning maintenance windows.
Module Upgrades
When Run module upgrades is enabled (the default), the platform runs:
odoo-bin -c /etc/odoo/odoo.conf --no-http --stop-after-init --update allbefore 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:
- Detects the failure
- Pulls the previous image tag
- Recreates the container from the previous image
- Marks the update as
rolled_backin 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:
| Field | Description |
|---|---|
| Last updated | When the most recent update ran |
| Last status | Success, No change, Failed, or Rolled back |
| Next update | When the next scheduled update will run |
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 from the environment overview. In the Base Image Update card on the Overview tab, 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.
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