Multiple Environment Deployment on Same Server

Deploy development, staging, and production environments on a single server.

Why Multiple Environments?

• ✅ Test changes safely before going live
• ✅ Show clients work-in-progress on staging
• ✅ Keep costs low by sharing one server
• ✅ Maintain separate configs per environment

How It Works

OEC.sh runs each environment in isolated Docker containers on the same server. Each gets its own:

• Database (PostgreSQL container)
• Odoo application container
• Subdomain (e.g., project-dev.apps.oec.sh, project-staging.apps.oec.sh)

They share the server's CPU, RAM, and disk — you control how much each environment gets.

Step 1: Set Up Your Project

If you haven't already, create a project with your Git repository.

Step 2: Create Multiple Environments

1. Open your project
2. Go to Environments tab
3. Click Add Environment for each:

4. Select the same server for all environments
5. Deploy each environment

Step 3: Configure Per Environment

Each environment can have different:

• Git branch — dev, staging, main
• Odoo config — debug mode, workers, log level
• Custom domain — staging.yoursite.com, app.yoursite.com
• Addons — test modules on dev without affecting production

Resource Planning

For a single server, plan your total resources:

Tip: Development environments can share resources more aggressively since they're not always active.

How Each Resource Is Shared

Each environment gets its own CPU / RAM / disk allocation. But the three resources behave differently when multiple environments share one server.

CPU — soft limit, can over-commit

CPU is allocated as cgroup weights. You can sum your environments' CPU values above the server's total core count and it still works:

• If env A is idle and env B is busy, env B uses the idle cycles from env A automatically.
• The allocation acts as a minimum guarantee during contention, not a hard ceiling.
• On a 4-core server, four envs of 2 CPU each (=8 CPU total) is fine in practice as long as they don't all peak at the same time.

RAM — hard limit, no over-commit

RAM is a hard ceiling per environment. The cgroup will kill (OOM) any container that exceeds its limit.

• If env A is idle, env B cannot borrow its RAM.
• Sum of environment RAM must stay ≤ server RAM − ~1 GB system overhead.
• Don't over-provision. If you give every env enough headroom for occasional spikes, you'll run out of bookable RAM fast.

Disk — hard allocation per env

Each environment gets its own slice of the VM filesystem, reserved at deploy time.

• No overflow into another env's space.
• Sum of environment disk must stay ≤ server disk − ~10 GB system overhead (Docker images, logs, OS).
• Disk fills up faster than people expect — Odoo filestore, attachments, audit logs, postgres WAL. Monitor and scale before hitting 80%.

Practical sizing for Odoo

You can resize at any time from the environment's Settings → Resources tab. CPU and RAM changes apply on the next container restart; disk increases apply immediately (decreases require a fresh env).

Best Practices

1. Use branches — Map each environment to a Git branch (dev → development, staging → staging, main → production)
2. Clone for fresh data — Periodically clone production to staging for realistic testing
3. Set up backups — At minimum, back up production daily
4. Monitor resources — Check server monitoring to ensure environments aren't competing for resources
5. Clean up — Delete temporary environments when done to free resources

Next Steps

• Clone an Environment — Copy production data to staging
• Add Custom Domain — Give each environment a proper URL
• Scale Resources — Adjust CPU/RAM per environment