Odoo self-hosted requirements go far beyond CPU and RAM.
A production Odoo 19 system needs a supported installation, PostgreSQL, durable storage, HTTPS, a reverse proxy, protected database management, remote backups, monitoring, patching and an upgrade owner. Hardware matters, but unclear ownership causes more failures than an imperfect starting size.
The direct answer: there is no single official “Odoo server size” that fits every company. Capacity depends on concurrency, workload and custom code. The non-negotiable requirements are a maintainable architecture, secured public edge, complete recoverable data, observability and named people responsible for incidents and upgrades.
Odoo Community is LGPLv3 and requires no Enterprise subscription or per-user licence. It is not zero-cost infrastructure. Odin sells managed Community deployment, so we are commercially interested in the outsource option; use this checklist to evaluate us, another provider or your own team.
Start with a reproducible Odoo installation
- Supported operating environment: use an OS, Python and PostgreSQL combination compatible with your Odoo version.
- Documented method: choose official packages, source installation or Odoo’s official Docker image, then record versions and configuration.
- Separated environments: production changes should pass through development or staging with representative data and integrations.
- Controlled addons: version custom code, pin dependencies and review third-party module licences, maintenance and target-version support.
Containers are optional. Reproducibility is not. A hand-built server that nobody can recreate is technical debt from launch day.
Size against measured work, not named users
Inventory concurrent interactive users, website sessions, imports, reports, scheduled actions, email processing, integrations and attachment growth. A hundred occasional CRM users can be lighter than ten people running large manufacturing reports.
| Resource | Plan for | Watch |
|---|---|---|
| CPU | Concurrent requests, cron, reports | Saturation, queues, slow endpoints |
| Memory | Workers, PostgreSQL, large jobs | Swapping, worker recycling, OOM events |
| Storage | Database, filestore, logs, staging | Growth, latency, free space |
| Network | Users, integrations, backup transfer | Latency, errors, egress volume |
Leave headroom and define thresholds. High availability adds load balancers, shared or replicated state, database design and tested failover; it is an architecture project, not a checkbox on a small VM.
Require HTTPS and a correctly configured reverse proxy
Use a maintained reverse proxy for TLS, HTTP-to-HTTPS redirects and appropriate request headers. Configure Odoo proxy mode only behind a trusted proxy. Protect certificate renewal with monitoring rather than calendar memory. The official deployment documentation includes HTTPS and proxy configuration guidance.
Expose only intended services. PostgreSQL should not listen publicly. Restrict administrative paths at the network layer where practical, protect secrets outside source control, and rotate credentials when operators leave.
Lock down database discovery and management
Configure dbfilter to match the intended hostname-to-database design and disable public database listing or management in production. Keep the Odoo master password strong and separately controlled. A multi-database deployment needs explicit tenant isolation, certificate coverage and operational procedures.
Use a dedicated PostgreSQL role with the privileges Odoo needs, not a general superuser for routine operation. Set connection, logging and retention policies deliberately. Database performance tuning should follow evidence from the actual workload.
Back up the database and filestore as one system
An Odoo database contains transactional records while the filestore contains many attachments. Recovery requires a matching pair. Automate encrypted copies to remote storage, retain multiple generations and separate backup credentials from production credentials.
- Define recovery point and recovery time objectives.
- Alert on missed, stale or unexpectedly small backups.
- Test restoration into an isolated environment on a schedule.
- Open attachments and reconcile critical workflows after restore.
- Document who can authorize and perform recovery.
Provider snapshots are useful, but do not make one account and one region your only recovery path.
Monitor the service users experience
Collect service health, response latency, error rates, worker utilization, database connections, cron failures, certificate expiry, disk usage and backup freshness. Centralize logs with appropriate access and retention. Alerts need an owner, severity and response procedure; a dashboard nobody watches is decoration.
Patch the operating system, proxy, PostgreSQL, Python dependencies, Odoo and installed modules through staging. Maintain an asset and addon inventory so security notices can become concrete action instead of a search for what is running.
Fund upgrades before the current version becomes a trap
Assign ownership for minor updates and major-version migration. Before a major upgrade, inventory customizations, identify unsupported modules, clean unnecessary data, rehearse against a recent copy and test permissions, accounting, inventory, reports, integrations and scheduled jobs.
Keep rollback criteria and a cutover plan. Complex historical migration, localization or custom code may justify specialist help; a partner remains optional for a simple system with capable internal staff. For the installation sequence, use the self-hosting pillar guide.
Do not call it production until these are true
- HTTPS works and renewal is monitored.
- PostgreSQL and database management are not publicly exposed.
dbfilterand database listing match the hosting design.- A remote database-plus-filestore backup has been restored successfully.
- Monitoring alerts reach a named responder.
- Staging represents production well enough to test changes.
- Patch, incident and major-upgrade responsibilities are written down.
- Data ownership and export rights are contractually clear.
Official Odoo documentation
FAQ
How much RAM does self-hosted Odoo need?
There is no reliable universal number. Worker count, concurrent requests, reports, cron jobs, integrations, PostgreSQL and custom code determine memory. Start from measured workload assumptions, leave headroom and load-test staging.
Does production Odoo require HTTPS?
Yes. Public production traffic should use HTTPS, normally terminated by a maintained reverse proxy configured with the correct headers and monitored certificate renewal.
Why does an Odoo backup need the filestore?
The PostgreSQL database holds records while the filestore holds many attachments. Restoring only one can leave an incomplete system, so preserve and test a matching pair.
What is dbfilter in Odoo?
dbfilter controls which databases Odoo considers for a request, commonly using the hostname. It should be paired with database-listing and database-manager restrictions in public production.
Turn requirements into a hosting choice
Need this checklist owned, not merely completed once?
Odin commercially sells flat-fee Community deployment and ongoing management. Review our pricing and deployment scope against every requirement above.