A build-to-order Odoo module that puts your website and/or backend into a controlled maintenance mode during deploys, migrations, and cutovers — with an allowlisted admin bypass, a branded holding page, and scheduled windows. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
App manifest
Built around your workflow
A build-to-order Odoo module that puts your website and/or backend into a controlled maintenance mode during deploys, migrations, and cutovers — with an allowlisted admin bypass, a branded holding page, and scheduled windows. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Odoo.
You go live in about 2–4 weeks, with a post-launch support window.
Every Odoo team hits the same awkward moment: you need to run a database migration, deploy a risky change, reconcile inventory, or cut over to a new fiscal year — and users keep transacting against a system that is mid-surgery. Odoo core has no first-class "close the shop for thirty minutes" switch. The nearest options are all blunt: take the server process down (which returns raw HTTP errors and looks like a real outage), unpublish the website (which does nothing for the backend, the portal, or the /web login), or drop an Nginx maintenance page in front (which locks out your own admins along with everyone else and can't be toggled from inside Odoo). The result is either data written during an unsafe window, or a self-inflicted outage with no branding, no messaging, and no controlled way back in for the person actually doing the work.
Maintenance Mode is a build-to-order Odoo module that gives you a real, application-level maintenance switch scoped to exactly what you choose: the public website, the backend /web client, the customer portal, or all of them. Technically it is implemented as a small config model (an res.config.settings extension plus a dedicated maintenance.window model built on models.Model) that a request-level hook consults on every inbound request. When the mode is active, an override of ir.http._dispatch (the pre-handler in 17.0/18.0/19.0) intercepts the request and serves a branded QWeb template with an HTTP 503 Service Unavailable status and a correct Retry-After header, so search crawlers back off cleanly instead of de-indexing your pages. Nothing reaches the controllers or the ORM write path while the gate is closed.
The behaviour is designed for the people who run the deploy, not just the people locked out by it. An allowlist — driven by ir.model.access.csv plus record rules on the window model — lets nominated users, specific groups, or requests carrying a secret bypass token or an IP on an allowlist continue to log in and work normally while everyone else sees the holding page. That means your admin, your integrator, and your QA tester can verify the release on the live database before you re-open the doors. You get a compute field showing current state, an activation reason and ETA that render into the holding-page copy, optional scheduled windows (start/stop timestamps enforced by an ir.cron automated action so a window opens and closes itself overnight), and an audit trail of who toggled the mode and when. XML-RPC/JSON-RPC traffic can be independently gated or exempted, so a scheduled integration doesn't hammer a closed instance — or, if you prefer, keeps syncing while human traffic is held.
Because this is built to order, we start from your actual topology — single company or multi-company, Community or Enterprise, self-hosted or Odoo.sh, behind Cloudflare/Nginx or not — and tailor the scope: which surfaces are gated, what the bypass mechanism is, how the holding page is branded and localized, and whether windows are manual, scheduled, or triggered by your deploy pipeline over the RPC API. You review the working module on a staging copy of your database during UAT, we hand over the source and the git repository, and only then do we deploy to production with a rollback plan in hand.
Delivery is typically two to four weeks from confirmed scope, depending on how many surfaces and integrations are in play. Pricing starts from $249 (indicative, single-company base scope); multi-company gating, per-website scoping, deploy-pipeline integration over XML-RPC/JSON-RPC, and bespoke branding/localization of the holding page increase the quoted scope. You get a firm fixed quote after a short scoping call — never a surprise.
Runs deploys, migrations, and fiscal-year cutovers and needs a safe, application-level way to freeze user transactions for a controlled window without taking the server down or returning raw error pages. Wants a bypass so they can validate the release on production before re-opening.
Delivers projects for multiple clients and needs a reliable maintenance gate that scopes to website, backend, and portal independently, keeps their own team's access open, and holds back scheduled RPC integrations during risky changes.
Runs an Odoo website/eCommerce storefront and wants planned maintenance windows with a branded, honestly-messaged holding page (reason + ETA) that protects SEO with a proper 503, instead of an ugly outage that hurts rankings and trust.
Operates several companies on one Odoo database and needs to gate a specific company or website for a period-close or data reconciliation while the rest of the group keeps trading, with an audit trail of who closed and re-opened the gate.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Scope of the gate | Website, backend `/web`, and portal gated independently; per-website and multi-company aware | Whatever you build — usually starts narrow and grows over time | Often website-only; backend and portal left exposed | |
| Admin / integrator bypass | User/group allowlist plus secret token or IP allowlist, enforced via record rules | Possible but you design and secure it yourself | Sometimes a single hard-coded bypass; rarely group-based | |
| SEO-safe status codes | HTTP 503 with `Retry-After` so crawlers back off cleanly | Depends entirely on how carefully it's coded | Varies; many return a 200 holding page that risks de-indexing | |
| Scheduling | Start/stop windows auto-enforced by an `ir.cron` job | Add-on work you'd have to spec and build | Usually manual toggle only | |
| Branding & messaging | Branded, localized QWeb page with activation reason and ETA | You build and translate the template yourself | Basic template, limited localization | |
| Audit trail | Records who toggled the mode and when; optional chatter log | Only if you build logging in | Rarely included | |
| Fit to your environment | Built to your topology (Community/Enterprise, Odoo.sh, multi-company) with UAT and rollback | Fully bespoke but you own all the risk and effort | Generic; you adapt your process to the module | |
| Ownership & support | Full source + git handover, training, post-go-live support window | You own it but also maintain it entirely alone | Vendor-controlled; support quality varies |
This is a build-to-order module, not an instant download. Typical delivery is two to four weeks from confirmed scope, depending on how many surfaces (website, backend, portal) and integrations you need gated. After a short scoping call we agree the scope, build it, hand it to you for UAT on a staging copy of your database, then deploy to production with a rollback plan.
Pricing starts from $249 as an indicative from-price for a single-company base scope. The final number depends on drivers like multi-company gating, per-website scoping, deploy-pipeline integration over the RPC API, and how much bespoke branding/localization the holding page needs. You get a firm fixed quote after the scoping call — no open-ended hourly billing and no surprise fixed price before we understand your setup.
It works on both. The module is built on standard framework primitives — an `ir.http` dispatch override, a config model, `ir.model.access.csv`, record rules, QWeb, and `ir.cron` — that exist in Community and Enterprise alike. We target Odoo 17.0, 18.0, or 19.0 and confirm your exact edition and version during scoping so the delivered code is pinned to your environment.
Yes — that's a core design point. An allowlist of users or groups, plus an optional secret bypass token or IP allowlist, lets nominated staff log in and work normally on the live database while everyone else sees the branded holding page. This is what lets you validate a release in production before you re-open to users.
No. The holding page is served with an HTTP `503 Service Unavailable` status and a `Retry-After` header — the correct signals that tell search crawlers the outage is temporary, so they back off and return later instead of de-indexing your pages. A plain server shutdown or a generic error page doesn't send those signals; this does.
Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because you receive the full source and git repository, you can extend it yourself or ask us for changes. When you later upgrade Odoo (for example 18.0 to 19.0), we can quote a compatibility pass — the dispatch hooks and model APIs shift slightly between majors, so a version bump is a small scoped task rather than a rebuild.
Yes, if you want it. We can wire the mode to be flipped on and off over the JSON-RPC/XML-RPC API so your CI/CD closes the gate before a release and re-opens it after, and you can also use scheduled windows driven by `ir.cron` so a maintenance window opens and closes itself at set times without anyone logging in.
A build-to-order Odoo module that puts your website and/or backend into a controlled maintenance mode during deploys, migrations, and cutovers — with an allowlisted admin bypass, a branded holding page, and scheduled windows. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.