Instances

Instances (Environments) are isolated Odoo deployments running in Docker containers. Each instance has its own database, filestore, and configuration.

Instance States

State	Description	Actions
RUNNING	Active and accessible	Stop, Restart, Deploy, Quick Update
STOPPED	Inactive, data preserved	Start, Delete
DEPLOYING	Deployment in progress	View Logs
ERROR	Deployment failed	View Logs, Retry

Available Actions

• Deploy: Full deployment with git clone, container build, and DB init
• Quick Update: Downloads the latest code and upgrades only the changed modules, without a full rebuild — see "Environment actions" below
• Clone: Copy instance to new environment
• Start/Stop: Control instance state
• Restart: Restart Odoo container
• Rollback: Revert to previous deployment
• Delete: Remove instance and free resources

Environment actions: Stop, Start, Restart, Quick Update, Deploy

Five buttons touch a running instance, and they are not interchangeable — each does a different amount of work, and only some of them apply a code or module change. This section spells out exactly what each one does.

Action	What it actually does
Stop	Stops the Odoo container only (docker compose stop odoo). The database keeps running. The site is unreachable until you click Start. The instance's status becomes STOPPED, which tells the Auto Restart watchdog to leave it down — it will not bring a deliberately stopped instance back on its own.
Start	Starts the Odoo container back up (docker compose start odoo).
Restart	Restarts the Odoo container (docker compose restart odoo) — a few seconds of downtime. This reloads whatever Python code is already on the server; it downloads nothing and runs no module upgrade.
Quick Update	Downloads the latest code, detects what changed, upgrades only that, and (usually) keeps the site up the whole time. See below.
Deploy / Re-deploy	The full pipeline: downloads every repository, regenerates the Docker/Odoo/nginx configuration, pulls the Docker image, installs any new Python requirements, records a rollback point before any upgrade, upgrades only the modules whose change needs it (a Python-method-only change just restarts on the new code) — almost always without downtime (see “What happens when I push code?” in the FAQ).

Quick Update, in detail

Quick Update downloads the latest code for the project's own repository and every addon branch this environment mounts, shared or dedicated, then works out which modules actually changed for this environment's own database and upgrades only those — in a disposable one-off container, while the live instance keeps serving requests. It only restarts Odoo (a few seconds) when something actually changed; if the download turns up nothing new, it says so and leaves Odoo running untouched.

• If the upgrade collides with the live instance writing the same rows, it is retried exactly once with Odoo stopped for the length of the retry.
• If the upgrade genuinely fails, Quick Update itself fails and reports why — the live site is left running exactly as it was (it was never stopped, so there's nothing to roll back).
• A shared addon branch is one folder used by every environment that mounts it. Quick Update updates that folder, so any sibling environment sharing the same branch also receives the new files and is flagged “pending upgrade” — exactly like clicking that addon's own Pull button would. A sibling's own database is never touched by someone else's Quick Update.
• Quick Update does not regenerate docker-compose.yml/odoo.conf/nginx configuration, does not pull a new Docker image, does not install new Python requirements, and does not take a pre-deploy backup. Any change that needs one of those still needs a Deploy.

Which one should I use?

• Only changed a Python file (a method's logic, no new field/view/menu/security rule) — Restart is enough: Odoo re-reads its own code on start.
• Changed a field, a view, a menu, a security rule, or any data file (XML/CSV, or anything in the module's manifest) — that needs a real module upgrade, not just a restart. Use Quick Update (fast, no full pipeline) or Deploy (also updates the Docker image, requirements, and configuration).
• Changed a dependency, an environment variable, an addon mount, or anything in odoo.conf/Docker configuration — only Deploy regenerates those; Quick Update will not pick them up.

Troubleshooting: "Detected 0 changed modules"

Quick Update reporting zero changed modules means the database is already at the latest code it could find — either nothing new was pushed, or the download step itself could not reach the repository (check the Quick Update log for a warning line naming the repository it couldn't reach; it still runs with whatever code was already on the server rather than failing outright).

Configuration

• Technical Name: Unique identifier used for containers and DB
• Display Name: Human-readable name shown in UI
• Branch: Git branch to deploy
• Auto Deploy: Enable automatic deploy on git push
• Auto Restart: Automatically recover after a crash, host reboot, or external stop (on by default; see Auto Restart)
• Database Placement & Version: Set once at creation — co-located (default), another of your own servers, or a managed database service — plus which PostgreSQL version to run (see Database Placement)
• Environment Variables: Custom configuration per instance

API Endpoints

POST   /environments/:id/deploy              # Full deploy
POST   /environments/:id/quick-update        # Fast update
POST   /environments/:id/clone               # Clone environment
POST   /environments/:id/start             # Start instance
POST   /environments/:id/stop              # Stop instance
POST   /environments/:id/restart           # Restart instance
POST   /environments/:id/rollback            # Rollback deploy
DELETE /environments/:id                   # Delete instance

Access URLs

Once deployed, instances are accessible via:

• Custom Domain: Configured in domain settings
• SPCBot Subdomain: instance-name.spcbot.com
• Direct IP: http://server-ip:allocated-port