What real OEC.sh customers run, and why they picked us
Eight anonymized deployments drawn from support tickets, migration run logs, and platform telemetry. Full names once each customer signs off.
Every case study below is a real OEC.sh customer. Names, locations, and identifying details have been removed. The problems, stack choices, numbers, and quotes are drawn from support tickets, migration run logs, and platform telemetry. We publish each with real names once the customer has reviewed and agreed to the version. If one of these sounds like you, it probably is.
Odoo partner managing client sites
Southern Europe · 24 client projects · 28 Odoo environments on two of their own servers
Problem
They run Odoo for two dozen clients, each with its own production site and often a staging copy, across Odoo 18, 19 and 20, on their own hardware.
Stack
Odoo 18, 19 and 20, Community and Enterprise. A 16-core, 39 GB production server and a separate development server. Clients moving in from Odoo Online, Odoo.sh and older on-premise installs.
Alternatives considered
Running each client's Odoo by hand on their own servers.
Decision
Connect their own servers to OEC.sh and run every client as a project with production and staging environments, using automation rules to refresh staging from production.
I recently discovered the project automation tab. It's great, you made a nice job.
Technology services company
North America · 4 Odoo environments on their own 32 GB server · 22 GB site
Problem
Their production Odoo ran on a managed host with no server access, and they needed full staging copies of a 22 GB database plus filestore to develop against.
Stack
Odoo with custom modules from their own Git repositories. 9 GB database and 12.5 GB filestore. Their own 4-core, 32 GB server, with a 300 GB disk added for room.
Alternatives considered
Staying with their previous managed host.
Decision
Connect their own server to OEC.sh, import the CloudPepper backup, and clone production into staging environments on the same machine.
Thanks for these fixes, they look great.
Microfinance and loan management SMB
East Africa · 54 custom Odoo modules · 2 developers on retainer · own Hetzner server
Problem
Had 54 custom Odoo modules living on a single VM with no git-backed source. A single rebuild risked losing years of custom work.
Stack
Odoo 15 Community on self-managed Hetzner. Fifty-four custom addons covering loan origination, salary deductions, and a serial-fetch API. Two in-country developers on retainer, no dedicated ops.
Alternatives considered
Keep running on the native odoo.service VM. Odoo.sh was ruled out early: 54 custom modules do not fit its sandboxed addon model.
Decision
Full database and filestore migration into a managed OEC.sh environment on their own Hetzner server. Their GitHub repo is linked as a first-class addon source, so custom modules survive every redeploy.
We pointed OEC.sh at our GitHub, kicked off the migration, and 4 minutes later all 54 of our custom modules were running in our own cloud. Every redeploy since has pulled straight from git.
Healthcare and life sciences group
Southeast Asia · 4 Odoo environments on one AWS VM · PG17 upgrade pipeline · Cloudflare Tunnel
Problem
Needed to run four Odoo environments on one AWS VM without exposing SSH, and to clone production into staging with patient data scrubbed before the application answered any request.
Stack
Odoo on AWS behind a Cloudflare Tunnel. Four environments in a dev / dev-pg17 / stg-pg17 / prod-pg17 pipeline. PG17 upgrade in flight. Local data-protection regime in play.
Alternatives considered
Odoo.sh was rejected on data-handling and residency grounds. Fully self-managed on their own AWS was rejected on operational burden for a small ops team.
Decision
Clone-safe-for-personal-data pipeline. Container start is deferred until the SQL scrub completes, a filestore skip flag covers imaging uploads, and a per-project scrub hook lets the customer own their anonymization rules. Native terminal over Cloudflare Tunnel means no public SSH and no per-engineer Cloudflare Access token.
Six months in: four Odoo environments on one VM, no public SSH, and every staging clone scrubs patient data before the app answers a request. The Dec 1 cutover was uneventful, which is the compliment.
Specialty retail and ecommerce
DACH · 6 Odoo environments on one 32 GB Hetzner VM · 6 workers + 2 cron in prod
Problem
Six Odoo environments shared one VM. The production environment needed a bigger PgBouncer pool than the other five, without a full redeploy or change window.
Stack
Odoo on a self-managed 32 GB Hetzner VM. Six Odoo environments on one box. PgBouncer in session pool mode in front of a single Postgres primary. In-house dev team running their own tuning.
Alternatives considered
Scale horizontally and move envs onto new VMs. Rebuild on a bigger Hetzner tier. The team chose the targeted per-environment pool override as the cheaper fix with the shortest change window.
Decision
PgBouncer pool size as a first-class field on the project environment. Config change applied without a full redeploy, and the override is now a persistent setting that survives every future redeploy.
On one Hetzner box we run six Odoo environments, and I bumped production's pool size from 22 to 60 as a field on the environment. The override sticks through every redeploy.
Managed IT services and reseller
North America · Multi-env on own AWS · external managed Postgres planned · Aurora reader for reporting
Problem
Their previous reseller host did not support real dev, staging, and production separation or an external managed Postgres, so reporting workloads were competing with production on the same database.
Stack
Odoo on OEC.sh across dev, staging, and production evaluation tiers. BYO AWS account. External managed Postgres on the roadmap with an Aurora reader endpoint for reporting isolation. Public API and dashboard running side by side.
Alternatives considered
Stay on their previous reseller host. Odoo.sh was ruled out on environment separation and external-database support.
Decision
Bring their own AWS account, three environment tiers deployed in parallel, external managed Postgres as a first-class attach, and an Aurora reader endpoint so reporting hits a replica instead of production.
We spun up dev, staging, and prod in parallel on our own AWS the first week, and now we're attaching managed Postgres with an Aurora reader so reporting hits a replica, not prod.
Odoo implementation partner and consultancy
Southern Europe · Boutique partner firm · single-digit engineers · first production end-client on OEC.sh
Problem
Needed to deliver managed Odoo to an end-client under the partner firm's own brand, while keeping the end-client relationship and the incident response flow with the partner, not with a third-party host.
Stack
Managed Odoo environment on the partner firm's own cloud account. Partner-branded platform surface. Partner-side telemetry. Boutique engineering team with no in-house SRE function.
Alternatives considered
Odoo.sh is the common partner default, but per-user cost is opaque to resell at margin. A self-managed VPS is impossible to brand-stand-behind without a 24x7 ops rotation.
Decision
A managed platform surface the partner puts their own brand on in front of the end-client. End-client data lives on the partner's own cloud account. The partner retains the end-client relationship and owns the incident response flow directly.
Reselling someone else's SaaS means handing over the account, the brand, and the pager. On OEC.sh my client sees our name, our cloud account holds the data, and my team owns the response.
Odoo partner running their own branded SaaS
Cross-regional partner community · 3 Odoo modules in their own repo · Odoo 19 base · 388 tests green at merge
Problem
Reselling $29 to $49 Odoo tenants with per-user hosting economics wiped margin before the first customer signed. They also wanted the storefront, portal, and billing as Odoo modules they could extend themselves, not a walled-garden product page.
Stack
Three Odoo modules on the agency's own instance: storefront, portal, and billing. Odoo 19 base, OCA contract module for subscription cycles, native Odoo payment UI. Public API keys with the oec_live_rw_ prefix drive per-tenant provisioning on the platform side.
Alternatives considered
Odoo.sh, where per-user Enterprise economics made the model unworkable for $29 to $49 tenants. A hand-rolled multi-tenant build on raw cloud, ruled out on build time: months rather than weeks.
Decision
The SaaS plan at $249 flat. End-to-end tenant lifecycle (signup, provision, bill, suspend, reactivate, offboard) runs through the agency's own three Odoo modules. Per-tenant provisioning is scripted against the public API.
Flat $249/mo lets us resell tenants at $29 to $49 with real margin. The storefront, portal, and billing are Odoo modules in our own repo, and provisioning runs through a public API we script ourselves.
If you're sizing a similar deployment
Deploy Odoo on your cloud
Pick your cloud, keep your data, pay less. Start free, no credit card required.