Skip to main content

September 2026

SaaS mode: several databases in one project​

A single project can now serve several independent Odoo databases from its production deployment, all running the same code: the setup partners and software vendors need to run one Odoo solution for many customers. Each database has its own address (<database>.skysize.io or a custom domain starting with its name), its own backups, and can be created, imported, restored, or deleted from the new Databases tab. Pushing to production updates every database together, with an all-or-nothing rollback.

SaaS mode is a subscription add-on activated by our team: contact sales to enable it. See SaaS Mode.

Your own domain for every deployment (BYOS)​

Projects on Bring Your Own Server can now serve all their deployments under your own domain with one wildcard DNS record created once: production, staging branches and development builds each get a name one level under the domain, and the domain itself stays yours. Certificates are issued on your server automatically, and attaching a domain removes the rate limit that applies to default skysize.io addresses.

Set it up from the project's Settings tab under Your domain. See Your domain on BYOS.

Custom Docker image per server (BYOS)​

Your servers can now run your deployments from your own Docker image, derived from the official Odoo image. This is the way to add apt packages, system libraries, fonts, or compiled Python packages that a requirements.txt cannot install. The image is set once per server under Custom Docker image and is used from each branch's next deployment, update, or restart.

Images can also ship Odoo Enterprise. The documentation now explains exactly where the Enterprise modules must go for Odoo to find them, with a ready-to-use Dockerfile and a command to check the result.

See Custom Docker image.

Private Git submodules​

Repositories that pull modules from private submodules now deploy on managed hosting and BYOS alike. Each private submodule repository gets its own deploy key: when your Git account is connected, Skysize registers the key on the submodule's repository for you; otherwise the project settings show the public key to add yourself.

See Private submodules.

Moving from another Odoo host​

A new guide walks through a migration from another host (CloudPepper, Odoo.sh, Odoo Online, or your own server): taking inventory, exporting a clean backup, rehearsing on staging, and cutting over production.

Imports are also more forgiving: backups whose SQL dump contains ownership and privilege statements (OWNER TO, GRANT), as exported by several hosts, now import as they are instead of failing.

See Migrate from Another Odoo Host.

Optional pre-update snapshot​

Before modules are upgraded, every update copies the deployment's databases so a failed update can be rolled back completely. On large databases this copy is most of the downtime of an update. Project administrators can now turn it off under Settings with Pre-update database snapshot.

Turning it off requires accepting a disclaimer: updates then run without a rollback point, and keeping a recent backup before a risky update becomes your responsibility. The settings page and every update that ran without a snapshot show who turned it off and when.

See Update Build.

Safer, more useful staging rebuilds​

  • Staging now runs your staging branch's code. A rebuilt staging branch used to keep production's code on top of the copied production data. After the copy, the platform now deploys the staging branch itself and updates its modules, so staging really tests your branch against production data. If the branch cannot be applied, the build fails and staging keeps serving the untouched copy.
  • Staging data is neutralized before Odoo starts. Outgoing mail servers, scheduled actions, and live integrations are disabled before the staging server boots for the first time, instead of shortly after. A copy of production can no longer send email or refresh bank connections during its first seconds. If neutralization fails, the build fails and the server is never started.

Worker changes apply with a restart​

Changing workers, cron workers, or memory per worker used to start a full update build, with its snapshot and module upgrade. These changes now only restart the production deployment with the new settings, followed by the usual health check and automatic rollback if it fails.

Clearer rules for custom domains​

A custom domain cannot work while the branch's address is behind the Cloudflare proxy: visitors get certificate errors, or Cloudflare error 1014 when your own DNS is on Cloudflare too. The dashboard now refuses to add a custom domain in that situation and tells you to turn the proxy off first. If your domain's DNS is on Cloudflare, create its record as DNS only.

See Domains.

First deployment from an empty repository​

A project created on a repository without any commit used to show nothing and deploy nothing. The Builds and Branches tabs now explain what to do, with the Git commands to push a first commit and a Refresh branches button. The first branch you push becomes the production branch and deploys automatically.

Slow queries that matter​

The slow queries list on the Monitoring tab now only shows statements that are actually slow: those averaging at least 100 ms, or with a single run of at least 1 second, still ranked by total time. Very fast statements that Odoo runs millions of times, and transaction commands, no longer crowd out the queries worth optimizing. On BYOS servers this requires agent version 1.4.1 or later.