Shodoosh
In production · EU · v0.9

Odoo hosting for
people who have
shipped Odoo before.

Instances that come up in under two minutes. Nightly backups you can restore into any instance. Your own domain with automatic TLS, and a dashboard that shows what is actually running. Built for teams tired of docker compose and a capped commission.

See what's under it
Odoo 17 · 18 · 19Moodle 4.5Postgres 16EU-hosted
~ ops · shodoosh-staging
$ shodoosh instances create --app odoo --version 19 --domain acme
real provisioning trace · re-plays every 8sall systems operational

Pricing

Same price list as Odoo.sh.
You keep 55%. No cap.

Your client pays exactly what they'd pay Odoo.sh — per worker, per staging environment, per GB. The difference is on your side of the invoice: Odoo pays partners 50% of hosting and stops at €150 a month per client. We pay 55% and never stop.

€48
Per worker
€12
Per staging
€0.16
Per GB
€400
Dedicated
GB

List price: €48/worker · €12/staging · €0.16/GB per month. Identical on Odoo.sh and Shodoosh.

Client hosting bill€356/mo
Odoo.sh pays you (50%, capped at €150/mo)€150/mocapped
Shodoosh pays you (55%, no cap)€196/mo
€18,000
per year on Odoo.sh, 10 clients
€23,496
per year on Shodoosh, 10 clients

This client is past the Odoo.sh cap: anything they spend above €300/mo earns you nothing extra there. Odoo Enterprise licences are excluded on both sides.

The platform

Every instance is a whole system,
not a container.

A Shodoosh instance is a namespace, its own Postgres, its own secrets vault, an Ingress with TLS, backups on schedule, and a place in the dashboard. Not a shared tenant with a schema prefix.

Provisioning

Boot a new production instance in under two minutes.

Pick an app and a version. We create the namespace, spin up its own Postgres, install the workload from a versioned Helm chart, request a Let's Encrypt certificate, and wire it into your dashboard. If any step fails, the whole thing is torn down again — you never end up with half of an environment.

1m 47s
Median cold boot
Atomic
Rollback on failure
Queued
Concurrent jobs
Backups

Nightly backups. Restore anywhere.

A full database dump to object storage every night, seven days kept. Restore into the same instance — or into a fresh staging one to reproduce a problem on real data.

Domains

Bring your own apex or subdomain.

Point a DNS record at us; we verify it, issue a Let's Encrypt certificate, and renew it. No blob of manual TLS config to babysit.

Secrets

One vault per instance. No shared blast radius.

Every tenant gets its own key material, sealed in OpenBao Transit. Rotate, revoke, and audit per tenant — never per fleet.

Two apps, one platform

Odoo and Moodle side-by-side.

Same lifecycle, same dashboard, same backup model. If you run both, you already know why that matters.

How it works

The whole lifecycle, in three commands you'd actually run.

01 · Provision
POST /api/instances
{
  "app": "odoo",
  "version": "19",
  "domain": "acme",
  "type": "PRODUCTION"
}
02 · Attach a domain
POST /api/instances/:id/domains
{
  "hostname": "erp.acme.com",
  "issuer": "letsencrypt"
}
03 · Restore anywhere
POST /api/backups/:id/restore
{
  "targetInstanceId": "acme-staging",
  "neutralize": true
}

Under the hood

No mystery meat. Here is exactly what runs your workload.

We do not hide the stack behind a "cloud" abstraction. You should know where your data lives, what schedules its backups, and who has the keys. If you want to leave, the artefacts are standard.

Orchestration
Kubernetes (K3s), Hetzner EU
Continuous delivery
Argo CD, per-cluster ApplicationSets
Database
Postgres per instance · nightly dumps to S3
Secrets
OpenBao Transit + KV, per-instance keys
Ingress
ingress-nginx + cert-manager
TLS
Let's Encrypt, automatic renewal
Object storage
AWS S3, STS creds via Bao AWS engine
Observability
Prometheus, live per-instance metrics