Odoo hosting on Hetzner: design the operations, not just the server.
Hetzner Cloud can be a sound foundation for Odoo Community, but creating a virtual machine is only the first step. Production readiness depends on region choice, persistent PostgreSQL and filestore data, restricted networking, HTTPS, recoverable off-site backups, monitoring, and rehearsed upgrades.

The direct answer: you can host Odoo Community on a Hetzner cloud or dedicated server, but Hetzner provides infrastructure rather than Odoo application management. A credible deployment keeps PostgreSQL and the matching Odoo filestore persistent, exposes only the reverse proxy, backs up both data sets off-server, and assigns someone responsibility for alerts, patches, restores, and Odoo upgrades.
DIY is attractive when your team already operates Linux, PostgreSQL, web proxies, and Odoo. Managed deployment is usually the safer economic choice when downtime, untested restores, or delayed security updates cost more than the operating service.
A simple production architecture is often the best one
For a small or medium installation, start with one adequately sized VM running an Odoo service, PostgreSQL, and Nginx or another reverse proxy. Keep Odoo bound to a private interface or localhost; publish only ports 80 and 443 through the proxy. Restrict SSH to administrator addresses or a VPN. Separating PostgreSQL onto another server can improve isolation and scaling, but it also creates network, backup, latency, and failure-mode complexity. Add that boundary only when measurements or availability requirements justify it.
Odoo’s installation documentation confirms that Odoo uses PostgreSQL. Its production deployment guide covers worker sizing, database filtering, HTTPS, proxy mode, and backups. Those are application responsibilities; choosing a large VM does not configure them.
Place data deliberately and keep both halves of Odoo
Choose the region primarily for user latency, data-residency obligations, and recovery design—not a marginal benchmark. As checked on 26 August 2026, Hetzner’s official locations page lists Falkenstein, Nuremberg, Helsinki, Ashburn, Hillsboro, and Singapore. Product availability differs by location, so verify the current matrix before ordering rather than relying on old plan comparisons.
An Odoo database is not a complete Odoo backup. PostgreSQL stores business records and attachment metadata; the Odoo data directory contains a per-database filestore holding attachment bodies. Losing either side can leave broken documents. Put all state on explicitly identified persistent storage and document its mount points. Hetzner Cloud Volumes are networked block storage, but they are not automatically a backup merely because blocks are replicated.
Local server disks can be simpler and faster; a Volume can make capacity changes and server replacement easier. The important decision is operational: know where PostgreSQL and the filestore live, ensure mounts return after reboot, monitor space and I/O, and include every stateful path in recovery procedures.
Use two firewall layers and terminate HTTPS correctly
Apply a Hetzner Cloud Firewall before first boot. Its documented default blocks inbound traffic not allowed by a rule; permit web traffic and narrowly scoped administration only. Keep an operating-system firewall too, because it travels with the workload and protects against configuration mistakes or alternate interfaces. PostgreSQL and Odoo’s native port should not be open to the public internet.
Odoo says a secure production deployment must use HTTPS and should sit behind a web server that terminates TLS. Configure sensible request-size and timeout limits, forward the expected headers, and enable Odoo proxy_mode only when it really is behind that trusted proxy. Use dbfilter, disable database listing/manager access in production, retain a strong master password, and run Odoo and PostgreSQL as unprivileged service accounts. These controls prevent a one-server convenience from becoming a public administrative surface.
Snapshots are useful rollback points, not sufficient Odoo backups
Hetzner’s backup and snapshot documentation describes both as server-disk copies. As of 26 August 2026, automatic Backups use seven rotating slots and Snapshots are manual and retained until deletion. Crucially, neither includes attached Volumes. A crash-time disk image may also capture PostgreSQL and the filestore at different logical moments.
Build application-consistent backups: produce a PostgreSQL dump or coordinated database backup, capture the corresponding filestore, record Odoo/addon versions and configuration, encrypt the archive, and copy it to a remote system that the Odoo host cannot rewrite. Odoo explicitly recommends daily database-and-filestore backups copied to a remote archival server inaccessible from the production server.
Keep infrastructure snapshots as a second layer before risky operating-system changes, not the only layer. Define retention around recovery-point needs, test restoration into an isolated test environment, verify attachments as well as database rows, and record recovery time. A backup job that exits successfully but has never restored is evidence of a file, not evidence of recoverability.
Monitor the application and rehearse updates
Watch external HTTPS availability, certificate expiry, response latency, CPU, memory, load, disk capacity, inode use, PostgreSQL connections, backup age, failed jobs, Odoo worker restarts, and error logs. Route alerts to a person with an escalation path. Infrastructure graphs alone can remain green while login, scheduled actions, outgoing mail, or an important workflow is broken, so add synthetic application checks.
Separate routine bugfix updates from major-version upgrades. Odoo’s bugfix update guide says to take a full external backup first, install updated code, and restart the service. For every change, reproduce production on staging, update Odoo and addons as a tested set, run business workflow checks, and keep a rollback plan. Major upgrades require database conversion plus compatible custom and third-party modules; rehearse them against a current copy before scheduling production downtime.
Hetzner versus managed Odoo is not a server-price comparison
| Responsibility | DIY on Hetzner | Managed deployment |
|---|---|---|
| Provisioning | You select, build, and document infrastructure | Provider supplies an application-ready environment |
| Security and uptime | Your team patches, monitors, alerts, and responds | Operational scope should be stated in the service agreement |
| Recovery | You design, export, test, and retain backups | Provider operates backups; you still verify retention and restores |
| Upgrades | You stage Odoo, addon, and database changes | Provider coordinates the tested application lifecycle |
DIY gives maximum infrastructure control and can be cost-effective for a capable operations team. Managed hosting transfers recurring work, not accountability: confirm recovery objectives, data location, support hours, monitoring, update cadence, test environments, export rights, and exit procedures in writing.
One click should describe the path, not hide the work
Odin’s one-click path provisions a server on Odin’s managed infrastructure; it is not a deployment into your Hetzner account. It can install available industry and country templates, supply live and test copies, and cover ongoing operations. That is a different product from renting a Hetzner VM and administering it yourself. Compare the choices on control, service scope, recovery, staging, upgrade ownership, and total staff time—not an introductory server price.
FAQ
Is Hetzner managed Odoo hosting?
No. Hetzner supplies cloud and dedicated infrastructure. Unless a separate service is contracted, you remain responsible for installing, securing, monitoring, backing up, restoring, and upgrading Odoo.
Do Hetzner server snapshots back up an Odoo Cloud Volume?
No. Hetzner states that server Backups and Snapshots do not include attached Volumes. Back up PostgreSQL and the matching Odoo filestore separately and copy them off-server.
Should PostgreSQL run on a separate Hetzner server?
Not automatically. One well-managed server is often simpler for modest workloads. Separate PostgreSQL when measured scale, isolation, or availability requirements justify the added network and recovery complexity.
What ports should public Odoo expose?
Normally only HTTP and HTTPS at the reverse proxy, with HTTP redirected to HTTPS. Restrict SSH to trusted sources, and do not expose PostgreSQL or Odoo’s native application port publicly.
Plan the whole Odoo lifecycle
Choose who owns production at 3 a.m.
Compare infrastructure control with a managed path that includes live and test copies and ongoing operations.