Documentation

An installation is one Odoo application. It holds a Git repository and one or more environments — production, staging, and development branches you can spin up and throw away.

1. 1Choose New installation and give it a name. The slug derived from it is used in namespaces and subdomains, so keep it short and lowercase.
2. 2Pick the Odoo runtime: version 16 through 19, Community or Enterprise. You can change it later and test the change on staging first.
3. 3Connect the Git repository holding your modules and pick the branch production should track.
4. 4Push a commit to that branch. The build starts on its own and the environment goes live once its health check passes.

Every environment gets its own Kubernetes namespace, its own Postgres database, its own storage volume and its own network rules. Nothing is shared, so a test can never read or write production data.

Each environment reserves an amount of CPU, memory and disk. That reservation is what you are billed for, and it is also the ceiling the environment can use — so give production room to breathe.

Each environment is mapped to one branch. When you push to that branch, DooWise clones the repository, resolves your modules, builds a container image and rolls it out. You do not write a Dockerfile and you do not touch the cluster.

git add addons/my_module
git commit -m "Add stock reservation rules"
git push origin staging

1. 1The push is received and a build is queued.
2. 2Modules are resolved and an image is built.
3. 3The database is migrated.
4. 4The new version starts and a health check runs.
5. 5If the check passes, traffic moves over. If not, the previous version keeps serving.

Turn off auto-deploy for an environment to require a manual Build now instead — useful for production when you want to choose the moment. Every build keeps its logs and its image, so you can roll back to an earlier one.

Backups are configured per environment: daily, weekly or disabled, with a retention window in days. You can also take one at any moment with Backup now.

• Restoring replaces the environment's current database with the backup's contents.
• Anything written after the backup was taken is lost, which is why the restore dialog asks you to type the environment name.
• Restoring production is a real outage. Test the restore on staging first when you can.

There are two ways in, depending on what you can get out of the old system. Both end at the same place: Environment → Backups → Import.

For anything large, let the old server upload it itself: in the environment, open Backups → Import → From the old server → Create import command, and run the command it shows on the old server. The script packs the database and filestore and sends them straight to Doowise — nothing depends on your laptop staying awake, and an interrupted upload retries by itself and resumes where it stopped.

curl -fsSL https://api.doowise.com/tools/migrate.sh -o doowise-migrate.sh
bash doowise-migrate.sh -d mydatabase -f /path/to/filestore/mydatabase -n \
  --upload 'https://api.doowise.com/imports/<token from the dashboard>'

The import command works once, for 24 hours, and only for the environment it was created in — treat it like a password. If the connection is lost for longer than the script is willing to wait, it prints a --resume command that continues the same upload from the archive it already built.

Smaller databases can also be uploaded from your own computer: Odoo's Database Manager backup (Backup, format zip), or an archive made with the script without --upload. The browser sends it in parts too: a dropped connection or a locked screen pauses the upload, and selecting the same file again continues where it stopped.

curl -fsSL https://api.doowise.com/tools/migrate.sh -o doowise-migrate.sh
chmod +x doowise-migrate.sh
./doowise-migrate.sh -d mydatabase

Without --upload it writes one file, doowise-migration-<database>-<date>.tar, containing the database dump and the filestore, next to where you run it (or in -o DIR). Upload that under Backups → Import → From this computer.

• Without --upload nothing is sent anywhere: the script only reads local files and writes that one archive.
• -n neutralizes the imported copy: its mail servers and scheduled actions are switched off before Odoo starts. The old server's database is never changed.
• Odoo keeps running while it works — pg_dump takes a consistent snapshot without blocking writes.
• The filestore is found automatically in the usual locations; pass -f /path/to/filestore/<db> if yours is elsewhere.
• For a password, use ~/.pgpass or PGPASSWORD rather than a flag, so it stays out of your shell history.
• Run it with -H to see every option.

Invite colleagues under Team & settings. Roles apply to the whole organization and everything in it.

Three tabs on the environment view are placeholders. They are visible so the shape of the product is clear, but they do nothing yet:

• Shell — a terminal into the environment's container.
• Editor — browsing and editing module files from the browser.
• Monitor — actual CPU, memory and disk use against the reserved amount.