Odooium.sh is the deployment control plane for the Odoo systems CDS runs. Your developers push to a branch; a build runs, a staging environment updates, and production is promoted by a second person — the exact artifact staging tested, with the database untouched.
Every action on this platform is a job with a receipt: who asked, what ran, how long it took, what changed. Nothing happens on a server without one.
A seven-step wizard turns a repository and an industry into a seeded, running staging environment — apps installed, company set up, pricelists loaded, master data uploaded, in that order. The same inputs produce the same database, every time.
7–9 minutes · zero AI in the loopA push to a staging branch builds and deploys itself. Authority comes from the branch, never from who pushed — though the push is recorded against them. A second push while one runs is recorded as skipped, not queued twice.
GitHub decides who pushesProduction runs the exact artifact staging tested — only the code moves, the database stays. A project admin promotes it, the control plane records who did, and a protected backup runs before the swap.
the container swap is the only downtimeDaily, weekly, monthly, offsite — to S3, SFTP or object storage of your choosing. Every week the newest copy is restored into a throwaway environment, booted and row-counted, attachments checked. An untested backup is not a backup.
a failed test blocks the next upgradeSystem, storage and HTTP panels drawn on demand from data that never leaves your server — no module inside Odoo, no cron, no queries against your database. Deploys and backups appear as markers, so "did it start after the deploy?" is answered by looking.
a silent server reads unknown, never healthyThe migration rules are a versioned library, snapshotted when the run starts, so nothing changes underneath a running upgrade. It repeats on staging until green; the cutover is gated on a passing restore test.
18.0 → 19.0, rehearsed before it is realThe interesting part of a control plane is not what it does — it is what it refuses to do, out loud, with the reason on it.
The webhook binds the push to the branch. A development branch gets a disposable environment; a staging branch rebuilds on a neutralised copy of production.
Its own machine, real data, always neutralised — no mail leaves, no cron fires, no provider is called. Testers get a keyed 12-hour shell; production gets none.
The exact artifact staging tested is proposed for production — a digest, not a rebuild. A protected backup is taken first.
The approval is recorded by the control plane against the exact digest proposed, and the proposer cannot be the approver. The swap is the only downtime; the database is untouched.
It writes a job. The agent on your machine pulls that job over an outboundconnection, checks the command exists in its own catalogue, that the job is bound to this host, that it has not expired and has not run before — and only then runs it. No inbound port is open to us.
Production is updated by a push to its own branch or by a project admin. A module update takes a protected backup first, and a failed update rolls back. Pushes to any other branch — builds, staging deploys — cannot reach production at all. What each command requires is decided on your own server, against a catalogue compiled into the runner it is checked by.
If Odooium.com is unavailable, this platform keeps building, deploying and backing up — and loses its AI features. That is the right direction: the brain is optional, the hands are not.
The three authorities beside this text describe the design 015 archived on 2026-09-13 (OD-55). What survives, and what this page promises, is the box-side check: the agent pulls its work, verifies the command and the binding against its own catalogue, and only then runs it.
A production write needs a person's signature, and the person who proposed cannot be the one who signs.
Builds, staging deploys and the nightly backup. Its scope stops at production-class writes, and that stop is verified on the box, not promised by us.
Signs the command catalogue, the approver manifest and each environment's class. It never signs a runtime job: without it, the other two could be bypassed by changing the rules instead of forging a job.
Groups are assigned per project by the project's own admin. A group is a set of defaults; anything beyond it is an extra grant with a reason in the trail. Push rights stay on GitHub.
| project admin | Manages people and access inside the project, settings, domains — and can propose a production change. Cannot bring a new person onto the platform: that is CDS's act. |
| maintainer | Operations without people-powers: settings, staging restores, production log reads. |
| developer | Code, builds and development environments. No production data. |
| tester | Staging and UAT. Reads what they need, changes nothing in production. |
| auditor | Reads the access trail and the read-only screens. Never opens a database. |
| extra grants | Any single permission can be granted to one person, beyond their group — and every grant is a line in the trail with a reason. |
You cannot authenticate here without an invitation. Signing in with GitHub proves who you are; it does not grant you anything. Until someone has invited you — to a project, or to the platform itself — the sign-in page tells you exactly that, names who can invite you, and stops. An invitation is addressed to your email by the CDS team, and sign-in is GitHub.
Two acts, two authorities. CDS operates every server on this platform and invites every person onto it — picking someone from GitHub who has never been here is a platform act, and no project role grows into it. Once a person is on the platform, your project's own admin invites them into your project and manages their access there, without a ticket to us.
No pricing page, no billing, no wallet, no self-serve trial. This is the control plane for systems CDS already runs for you — the commercial arrangement lives in your contract, not in a checkout flow. If you are not a CDS customer yet, that conversation starts with people: cdsegypt.com.