Odoo Staging Environment Guide

What Is a Staging Environment?

A staging environment is a near-identical copy of your production Odoo instance that runs on a separate server. Same Odoo version, same modules, same data structure — but isolated from your live business.

Think of it as a dress rehearsal. You test everything in staging first — module upgrades, custom code, Odoo version bumps, configuration changes — and only push to production once you're confident nothing breaks.

Why You Need Staging

Running Odoo updates directly on production is gambling with your business. Here's what staging prevents:

Setting Up a Staging Server

Your staging server should mirror production as closely as possible. Same operating system, same PostgreSQL version, same Odoo version. The only differences should be intentional (less RAM is fine, different domain).

Minimum staging specs

Staging can run on a smaller server than production — you're testing functionality, not load capacity. A $10-20/month VPS is enough for most teams.

Cloning Production to Staging

Two things to copy: the PostgreSQL database and the filestore (attachments, documents).

Step 1: Database dump

# On production server
pg_dump -Fc -Z 5 -f /tmp/odoo_prod.dump odoo_production
# Copy to staging
scp /tmp/odoo_prod.dump staging:/tmp/

Step 2: Restore to staging

# On staging server
sudo systemctl stop odoo
# Drop and recreate
sudo -u postgres dropdb odoo_staging
sudo -u postgres createdb -O odoo odoo_staging
# Restore
pg_restore -d odoo_staging /tmp/odoo_prod.dump
sudo systemctl start odoo

Step 3: Sync filestore

# Sync attachments from production to staging
rsync -avz --delete \
  production:/opt/odoo/.local/share/Odoo/filestore/odoo_production/ \
  /opt/odoo/.local/share/Odoo/filestore/odoo_staging/

Data Sanitization

After cloning, sanitize staging data immediately. You don't want staging sending real emails to customers or processing real payments.

-- Run on staging database after restore
-- Disable all outgoing mail servers
UPDATE ir_mail_server SET active = false;
-- Reset all user passwords to a random value
-- Generate one with: openssl rand -base64 16
UPDATE res_users SET password = (SELECT gen_random_uuid()::text)
  WHERE id > 2;
-- Anonymize partner emails (keep admin)
UPDATE res_partner SET email = 'staging+' || id || '@example.com'
  WHERE email IS NOT NULL AND id > 2;
-- Clear payment provider credentials
UPDATE payment_provider SET state = 'disabled';
-- Disable scheduled mail actions
UPDATE ir_cron SET active = false
  WHERE name ILIKE '%mail%' OR name ILIKE '%email%';
-- Clear webhook URLs
DELETE FROM ir_config_parameter
  WHERE key ILIKE '%webhook%';

Configuration Differences

Your staging odoo.conf should differ from production in a few key ways:

[options]
; Use a different database
db_name = odoo_staging
; Different port to avoid conflicts
http_port = 8070
longpolling_port = 8072
; Fewer workers (staging needs less)
workers = 2
max_cron_threads = 1
; Enable dev mode for easier testing
dev_mode = reload,qweb
; Separate log file
logfile = /var/log/odoo/odoo-staging.log
; Staging URL
db_filter = odoo_staging

Set up a staging subdomain (e.g., staging.yourcompany.com) with its own SSL certificate. This keeps URLs clean and makes it obvious which environment you're in.

Testing Workflow

A solid staging workflow follows these steps:

OEC.sh: One-Click Staging

All of the above — server provisioning, database cloning, data sanitization, SSL setup, email disabling — takes hours the first time and 30+ minutes on every refresh. OEC.sh does it in one click.