Deployments

A deployment in oCore represents the process of building and deploying code changes to an environment's instances. Deployments can be triggered manually through the dashboard or automatically via Git push events.

What triggers a deployment

Deployments can be initiated in several ways:

Trigger	How it works
Git push	Push to a branch mapped to an environment (e.g., `main` -> Production). Requires auto-deploy enabled.
Manual deploy	Click "Deploy Now" in the dashboard for any environment
API call	POST to the deployment API endpoint for CI/CD integration
Rollback	Restore a previous deployment to undo changes

Deployment process

Loading diagram...

Step-by-step

Trigger -- A deployment is initiated (Git push, manual, or API).
Enqueue -- The deployment job is enqueued in the River job queue for async processing.
Clone -- The worker clones the Git repository at the specified branch and commit.
Build -- A Docker image is built with the Odoo base image plus custom modules from the repository.
Pre-deploy snapshot -- The current database is snapshotted for rollback capability. This is a full PostgreSQL dump stored alongside the deployment record.
Stop -- The currently running container is gracefully stopped.
Start -- The new container starts with the updated image and configuration.
Health check -- oCore verifies the Odoo instance is responding to HTTP requests. The health check retries with exponential backoff.
Complete or rollback -- If the health check passes, the deployment is marked successful. If it fails after all retries, the system automatically rolls back by restoring the pre-deploy snapshot and restarting the previous container.

The entire deployment process runs asynchronously via the River job queue. You can monitor progress in real time through the dashboard, which shows the current step and any log output.

Deployment statuses

Status	Description
Queued	Deployment job is waiting in the queue
Building	Repository is being cloned and Docker image is being built
Deploying	Container is being stopped and the new one is starting
Running	Deployment complete, health check passed, instance is live
Failed	Deployment or health check failed
Rolled back	Automatically rolled back after health check failure
Cancelled	Deployment was cancelled before completion

Pre-deploy snapshots

Every deployment creates a database snapshot before making changes. This ensures you can always return to the previous state if something goes wrong.

Snapshots include:

Full database dump -- A complete PostgreSQL dump of the instance database
Timestamp -- When the snapshot was taken
Deployment reference -- Which deployment triggered the snapshot
Retention -- Snapshots are retained according to the backup retention policy

Pre-deploy snapshots are essential for safe deployments. If a deployment introduces a breaking database migration, the snapshot allows a complete rollback to the pre-migration state.

Manual rollback

In addition to automatic rollback on health check failure, you can manually roll back to any previous deployment:

Navigate to the environment's deployment history
Select the deployment you want to roll back to
Click "Rollback to this version"
oCore restores the database snapshot and restarts the container with the previous image

Build process

When a deployment builds a Docker image, the process includes:

Base image -- Start from the official Odoo Docker image for the configured version
Custom modules -- Copy custom modules from the Git repository into the Odoo addons path
Dependencies -- Install any Python dependencies specified in the repository's requirements.txt
Configuration -- Generate the Odoo configuration file with the correct database settings, port, and module list

The build output (logs, errors, warnings) is captured and available in the deployment detail view.

Deployment history

oCore maintains a complete deployment history for each environment, including:

Deployment ID and timestamp
Trigger type (Git push, manual, API, rollback)
Git commit hash and message
Build duration and deployment duration
Status and any error messages
Pre-deploy snapshot reference

This history enables audit trails, debugging failed deployments, and understanding what changed when.

Async processing

Deployments are processed asynchronously through the River job queue. This means:

Non-blocking -- The API returns immediately after queuing the deployment. The dashboard shows real-time progress.
Retryable -- If a transient error occurs (network timeout, Docker pull failure), the job can be retried.
Ordered -- Deployments to the same environment are processed sequentially to prevent conflicts.
Cancellable -- A queued or in-progress deployment can be cancelled through the dashboard.