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.
Failed deployments say why
A failed deployment now shows a one-sentence reason right on its card: a Python package missing from requirements.txt, a module whose dependencies are not available, a data file that could not be loaded (with the file and line), an error in your code (with the file and line), failing tests, and more. The See the log link next to it opens the log that shows the failure, already selected.
The message only contains module names, file paths inside your repository, line numbers and error types. It is shown by default and can be turned off per project under Settings, Failure reason on builds. On BYOS servers the detailed reasons require the next agent version.
Notifications: a bell in the dashboard, and your choice of channel
Project admins are now told when something needs their attention: a health issue on production, a failed production deployment, a domain that cannot be reached, a certificate about to expire, or a scheduled Odoo image update. Notifications arrive by email and under the new bell at the top of the dashboard, and each one opens the page it is about.
You choose the channels under My Account, Notifications: email, in the dashboard, both (the default) or neither. Billing notices are always sent on both. Domain alerts now go to the project's admins.
See Notifications.
Health signals for production
Skysize now watches the Odoo log and the container state of every production environment and turns known problems into health signals: scheduled actions that fail, time out or were deactivated by Odoo, workers killed on their time or memory limit, a container restarting in a loop, request errors, bursts of failed logins, missing attachment files, outgoing mail failures, and the default admin password still in use. Each signal says what happened, how often, and what usually fixes it.
Signals live in the new Health tab. A coloured dot on the tab, the project card and the production row shows the worst open level, and a banner appears when an issue is open. Signals can be acknowledged or muted, and an issue notifies the project's admins. On the Free Sandbox, production is watched too and the tab shows how many signals are open and at which level; the details come with a paid plan or a trial.
Automatic off-site copy of your backups
On paid plans, Skysize can copy your latest production backup to a bucket you own, weekly, every 2 weeks or monthly: Amazon S3, Google Cloud Storage, Cloudflare R2 or any S3-compatible storage. You get a second copy of your data outside the platform, in the same .zip format as Download backup. Skysize only writes to your bucket and never deletes from it.
Set it up under Settings, section Off-site copy, test the connection, and run a first copy with Copy now. See Automatic off-site copy.
Separate disk and backup allowances
Each managed hosting plan now includes two separate allowances: disk (your database and its files) and backups. A large database no longer eats into your backup space, and the other way around. Extra space is added in bundles for each one.
At 90% of an allowance the project page shows a warning with the usage and a ready order for the extra space. Over 100%, a grace period starts and project admins are notified before anything is disabled. A first subscription or a plan change already includes the bundles your current usage needs. The free tier keeps its single 5 GB limit.
See Storage allowances.
Odoo Enterprise from your own repository (BYOS)
Enterprise deployments on your own server can now read the Enterprise source from a private repository you control, on any git host, through a deploy key that Skysize sets up for you. A Docker image that already contains Enterprise remains the other option. When you create an Enterprise project on a server that has neither, the form asks for one.
See Operating on BYOS.
Connect your first server while creating a project (BYOS)
You no longer have to visit the Agents page first. When you create a project and choose My own server, the form offers the subscription if you have none yet and connects your first server right there. The first build starts as soon as the server connects.
See Set up your server.