Frequently asked questions

Three usual causes: the branch you pushed to isn't mapped to an environment, auto-deploy is off for that environment, or the repository webhook is missing. Check the branch mapping under the environment's Settings tab; if the mapping is right, disconnect and reconnect the repository to re-register the webhook.

Open the environment and go to the Logs tab, then select the failed build. The log shows module resolution and the image build; most failures are a missing dependency in a manifest or a module that doesn't exist in the chosen Odoo version.

Open the environment's History tab and connect to an earlier successful build. Previous images are retained, so rolling back does not require a rebuild. Note that a rollback does not revert database migrations — if the bad deploy migrated the schema, restore a backup instead.

Yes. Turn off auto-deploy for the production environment under its Settings tab. Pushes are then still built on demand with Build now, so you choose when the release happens.

Take a backup of production, then restore it into staging. The restore dialog asks for the target environment's name so a production restore cannot happen by accident.

Change the runtime on a staging environment first, restore a copy of production into it, and test. Once it holds up, change production's runtime and deploy. Never move production first.

It is probably hitting its reserved memory ceiling. Raise the allocation under the environment's Settings tab; the new reservation applies on the next deploy. Allocation is also what you're billed on, so this changes your invoice.

Production is the installation's anchor — its database and domain hang off it. If you genuinely want it gone, delete the whole installation, which removes every environment, database and backup with it.

On DooWise infrastructure in the Netherlands. Each environment has its own database and storage volume, with no transfer outside the EU.

No. A restore replaces the environment's database, and whatever was there is gone. Take a fresh backup right before restoring, so the pre-restore state stays recoverable.

For the retention window set per environment. Older backups are removed automatically once they fall outside it. Raise the window if you need a longer history.

The CPU, memory and disk each environment reserves — not what it actually consumes. That keeps invoices predictable: a traffic spike doesn't change the bill. Changing an allocation mid-month is pro-rated.

Yes, for as long as it exists, based on what it reserves. Development environments are meant to be short-lived — delete them when the branch is merged.

Team & settings, then Invite member. Pick the narrowest role that lets them do their job: Developer for people who deploy, Viewer for people who only need to look.

Contact support. An organization must have an owner, and restoring one requires staff access — it cannot be repaired from inside the app.