La respuesta corta
Hetzner es un buen hogar para Odoo, y barato. Elige un servidor cloud con suficiente memoria. Pon Postgres en él o en un segundo servidor en una red privada. Usa un Hetzner Cloud Firewall que solo deje entrar el 80, el 443 y tu propio SSH. Envía cada noche una copia de la base de datos y del filestore a Object Storage, en otra ubicación. Luego prueba una restauración antes de salir en vivo.
Muchos equipos de Odoo en Europa eligen Hetzner. Los servidores son rápidos para lo que cuestan, y puedes elegir Alemania, Finlandia, Estados Unidos o Singapur. Esta guía te da los comandos exactos para montar Odoo allí, para que siga rápido y seguro después de la primera semana.
Para la instalación en sí (Odoo, Postgres, el archivo de configuración y el proxy), sigue nuestra guía sobre Odoo en un VPS. Esta página cubre lo que cambia en Hetzner.
Qué servidor de Hetzner elegir
Prepara la herramienta hcloud
Puedes hacer todo esto en la Hetzner Console. La herramienta de línea de comandos hcloud es más rápida y más fácil de repetir, así que aquí usamos esa.
Primero, crea un token de API. En la Hetzner Console, abre tu proyecto, luego Security, luego API tokens, luego Generate API token. Elige Read & Write. Copia el token ahora. No podrás verlo otra vez.
Luego instala hcloud en tu propio equipo y conéctalo al proyecto:
# macOS or Linux with Homebrew
brew install hcloud
# or Linux, without Homebrew
curl -sSLO https://github.com/hetznercloud/cli/releases/latest/download/hcloud-linux-amd64.tar.gz
sudo tar -C /usr/local/bin --no-same-owner -xzf hcloud-linux-amd64.tar.gz hcloud
hcloud context create odoo-prod # paste the token when asked
CPU compartida o dedicada
Hetzner Cloud tiene dos tipos de servidores:
- Shared vCPU. La CPU se comparte con otros servidores de la misma máquina. Está bien para pruebas y equipos pequeños.
- Dedicated vCPU (por ejemplo CCX23). La CPU es solo tuya. Es mejor cuando la gente usa Odoo todo el día, porque una CPU compartida puede ir más lenta cuando tus vecinos están ocupados, y los usuarios de Odoo lo notan enseguida.
El mínimo para empezar: 2 vCPU, 4 GB de memoria y 50 GB de disco. Con eso corren Odoo y Postgres en un solo servidor para un equipo pequeño. La memoria importa más que la CPU: cada worker necesita su parte, y Postgres quiere la suya. Para más usuarios, importaciones grandes o Postgres en su propio servidor, nuestra guía sobre cuántos workers de Odoo necesitas muestra cómo calcularlo.
Mira lo que hay disponible:
hcloud server-type list
hcloud location list
hcloud image list --type system
Elige la ubicación
Tus datos viven donde vive el servidor. fsn1 (Falkenstein) y nbg1 (Núremberg) están en Alemania. hel1 es Helsinki, en Finlandia. ash y hil están en Estados Unidos, y sin es Singapur. Para una empresa de la UE, una ubicación en Alemania o Finlandia mantiene los datos en la UE.
Crea el servidor
Añade tu clave SSH, crea el firewall (siguiente sección) y luego crea el servidor:
hcloud ssh-key create --name my-laptop --public-key-from-file ~/.ssh/id_ed25519.pub
hcloud server create \
--name odoo-1 \
--type ccx23 \
--image ubuntu-24.04 \
--location fsn1 \
--ssh-key my-laptop \
--firewall odoo-web
Deja IPv4 e IPv6 (lo que viene por defecto). Si añades un registro AAAA para tu dominio, asegúrate de que el proxy también escucha en IPv6, o algunos usuarios no llegarán a Odoo.
Revisa el CPU steal en servidores compartidos
En un servidor compartido, el "steal" es el tiempo que tu servidor esperó a la CPU real. Revísalo en horario de trabajo:
vmstat 5 12
Mira la última columna, st. Si a menudo pasa de unos pocos por ciento mientras los usuarios se quejan de que Odoo va lento, pasa a un tipo dedicado:
hcloud server poweroff odoo-1
hcloud server change-type --keep-disk odoo-1 ccx23
hcloud server poweron odoo-1
--keep-disk mantiene el tamaño de disco anterior, así que puedes volver a bajar más tarde.
Pon el filestore en un volumen
Los adjuntos viven en el filestore, y crece cada día. Un Hetzner Volume te deja añadir espacio de disco sin cambiar el servidor. Crea uno y conéctalo:
hcloud volume create --name odoo-data --size 100 --server odoo-1 --format ext4 --automount
Hetzner lo monta en /mnt/HC_Volume_<id>. En el servidor, mueve allí los datos de Odoo y vuelve a montarlo en /var/lib/odoo:
ls /mnt # find HC_Volume_12345
systemctl stop odoo
rsync -a /var/lib/odoo/ /mnt/HC_Volume_12345/
chown odoo:odoo /mnt/HC_Volume_12345
mv /var/lib/odoo /var/lib/odoo.old
mkdir /var/lib/odoo
echo '/mnt/HC_Volume_12345 /var/lib/odoo none bind,x-systemd.requires-mounts-for=/mnt/HC_Volume_12345 0 0' >> /etc/fstab
systemctl daemon-reload
mount /var/lib/odoo
findmnt /var/lib/odoo # should show the volume
systemctl start odoo
Abre algunos adjuntos en Odoo. Cuando funcionen, borra /var/lib/odoo.old.
Para hacerlo crecer más tarde:
hcloud volume resize --size 200 odoo-data
lsblk # find the device, often /dev/sdb
resize2fs /dev/sdb
Los volúmenes solo pueden crecer, no encogerse. Una cosa más: las copias de seguridad y los snapshots de servidor de Hetzner no incluyen los volúmenes. Tu propia copia (más abajo) es la que salva el filestore.
Dónde va Postgres
Hetzner Cloud no tiene PostgreSQL gestionado. Así que lo gestionas tú, de una de estas dos formas:
- En el mismo servidor que Odoo. Simple, y está bien para la mayoría de los equipos pequeños y medianos. Postgres escucha solo en
localhost, que es lo que viene por defecto. No hay nada más que hacer aquí. - En un segundo servidor, en una red privada. Mejor cuando la base de datos crece mucho o muchos usuarios trabajan a la vez.
En los dos casos, Odoo se conecta con su propio usuario de base de datos, odoo, nunca con postgres.
Segundo servidor: la red privada
Crea una red y una subred. Todos los servidores de una misma red privada deben estar en la misma zona de red. fsn1, nbg1 y hel1 están todos en eu-central.
hcloud network create --name odoo-net --ip-range 10.0.0.0/16
hcloud network add-subnet odoo-net --type cloud --network-zone eu-central --ip-range 10.0.0.0/24
hcloud server create --name odoo-db --type ccx23 --image ubuntu-24.04 \
--location fsn1 --ssh-key my-laptop --firewall odoo-db
hcloud server attach-to-network odoo-1 --network odoo-net --ip 10.0.0.2
hcloud server attach-to-network odoo-db --network odoo-net --ip 10.0.0.3
Segundo servidor: que Postgres escuche solo en la IP privada
En odoo-db (Ubuntu 24.04 trae PostgreSQL 16):
apt install -y postgresql
sudo -u postgres createuser --createdb --pwprompt odoo
En /etc/postgresql/16/main/postgresql.conf:
listen_addresses = 'localhost,10.0.0.3'
Al final de /etc/postgresql/16/main/pg_hba.conf, permite solo el servidor de Odoo:
host all odoo 10.0.0.2/32 scram-sha-256
Reinicia y comprueba:
systemctl restart postgresql
ss -tlnp | grep 5432 # should show 127.0.0.1 and 10.0.0.3, never 0.0.0.0
En odoo-1, prueba la conexión y luego apunta Odoo a ella en odoo.conf:
psql -h 10.0.0.3 -U odoo -d postgres -c 'select 1'
db_host = 10.0.0.3
db_port = 5432
db_user = odoo
db_password = the-password-you-chose
Ten en cuenta que los Hetzner Cloud Firewalls no filtran el tráfico dentro de una red privada. Por eso Postgres debe escuchar solo en 10.0.0.3, y pg_hba.conf debe permitir solo 10.0.0.2.
Firewall
Un Hetzner Cloud Firewall bloquea todo el tráfico de entrada hasta que añades reglas. El tráfico de salida sigue abierto. Crea uno para el servidor de Odoo:
hcloud firewall create --name odoo-web
hcloud firewall add-rule odoo-web --direction in --protocol tcp --port 80 --source-ips 0.0.0.0/0 --source-ips ::/0
hcloud firewall add-rule odoo-web --direction in --protocol tcp --port 443 --source-ips 0.0.0.0/0 --source-ips ::/0
hcloud firewall add-rule odoo-web --direction in --protocol tcp --port 22 --source-ips 203.0.113.10/32
hcloud firewall add-rule odoo-web --direction in --protocol icmp --source-ips 0.0.0.0/0 --source-ips ::/0
Cambia 203.0.113.10 por tu propia IP. El ping (ICMP) sigue abierto porque ayuda cuando tienes que buscar un problema.
Para el servidor de base de datos, permite solo SSH:
hcloud firewall create --name odoo-db
hcloud firewall add-rule odoo-db --direction in --protocol tcp --port 22 --source-ips 203.0.113.10/32
Si el servidor ya existe, conecta el firewall con:
hcloud firewall apply-to-resource odoo-web --type server --server odoo-1
Los puertos propios de Odoo (8069 y 8072) no están en las reglas, así que solo el proxy del mismo servidor puede alcanzarlos. Comprueba desde tu equipo que están cerrados:
nc -zv -w 5 <server-ip> 8069 # should time out
Copias de seguridad
Para Odoo necesitas la base de datos y el filestore, guardados juntos y copiados fuera del servidor. Así se envían a Hetzner Object Storage, en una ubicación distinta a la de tu servidor.
Elige la ubicación de las copias
Object Storage funciona en fsn1, nbg1 y hel1. Elige una que no sea la de tu servidor:
- Servidor en
fsn1onbg1: pon las copias enhel1. - Servidor en
hel1: pon las copias enfsn1. - Servidor en Estados Unidos o Singapur: Object Storage solo está en Europa, así que tus copias saldrían de tu región. Si eso importa para tus datos, usa un servicio de almacenamiento en tu propia región.
Usa un proyecto aparte para las copias
En Hetzner, las claves S3 sirven para todos los buckets del mismo proyecto. Así que dale a las copias su propio proyecto. Así la clave de tu servidor solo puede llegar al bucket de copias.
- En la Hetzner Console, crea un proyecto nuevo llamado
odoo-backups. - En ese proyecto, abre Security, luego S3 Credentials, luego Generate credentials. Llámalo
odoo-1. Copia ahora la access key y la secret key. No podrás ver la secret otra vez.
Instala la AWS CLI y guarda las claves
Hetzner Object Storage habla la API de S3, así que la AWS CLI funciona con él. En odoo-1:
apt install -y unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o awscliv2.zip # use awscli-exe-linux-aarch64.zip on Arm servers
unzip awscliv2.zip && ./aws/install
mkdir -p /etc/odoo-backup
/etc/odoo-backup/aws-config:
[default]
endpoint_url = https://hel1.your-objectstorage.com
region = hel1
request_checksum_calculation = when_required
response_checksum_validation = when_required
/etc/odoo-backup/aws-credentials:
[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY
chown -R odoo:odoo /etc/odoo-backup
chmod 600 /etc/odoo-backup/*
export AWS_CONFIG_FILE=/etc/odoo-backup/aws-config
export AWS_SHARED_CREDENTIALS_FILE=/etc/odoo-backup/aws-credentials
Crea el bucket con Object Lock
Object Lock impide que nadie borre una copia durante un número fijo de días. Ni tú, ni un script que falla, ni alguien que entra en el servidor. Solo puedes activarlo al crear el bucket. Los nombres de bucket se comparten en todo Hetzner, así que elige un nombre único.
aws s3api create-bucket --bucket your-odoo-backups --region hel1 --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket your-odoo-backups --object-lock-configuration \
'{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 14 }}}'
En modo COMPLIANCE, nadie puede acortar el bloqueo una vez puesto. Esa es la idea, pero empieza con un número de días del que estés seguro. El modo GOVERNANCE se puede deshacer, y eso también significa que una clave robada podría deshacerlo.
Guarda 30 días y luego borra
Guarda esto como lifecycle.json. Hace caducar las copias a los 30 días, y luego limpia las versiones viejas y los marcadores que deja Object Lock:
{
"Rules": [
{
"ID": "expire-backups",
"Status": "Enabled",
"Prefix": "",
"Expiration": { "Days": 30 },
"NoncurrentVersionExpiration": { "NoncurrentDays": 1 },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 2 }
},
{
"ID": "delete-markers",
"Status": "Enabled",
"Prefix": "",
"Expiration": { "ExpiredObjectDeleteMarker": true }
}
]
}
aws s3api put-bucket-lifecycle-configuration --bucket your-odoo-backups --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket your-odoo-backups
El script de copia
/usr/local/bin/odoo-backup.sh:
#!/bin/bash
# /usr/local/bin/odoo-backup.sh, run as the odoo user
set -euo pipefail
DB=yourdb
DAY=$(date +%F)
DIR=/backups/$DAY
mkdir -p "$DIR"
pg_dump -Fc "$DB" > "$DIR/$DB.dump"
tar -czf "$DIR/$DB-filestore.tar.gz" -C /var/lib/odoo/filestore "$DB"
aws s3 cp --recursive --only-show-errors "$DIR" "s3://your-odoo-backups/$DAY/"
find /backups -mindepth 1 -maxdepth 1 -type d -mtime +3 -exec rm -rf {} +
curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-BACKUP-UUID > /dev/null
La última línea avisa a un servicio externo de que la copia funcionó. Más sobre eso en Alertas. Luego:
mkdir -p /backups && chown odoo:odoo /backups
chmod 755 /usr/local/bin/odoo-backup.sh
Si Postgres corre en odoo-db, ejecuta el script en odoo-1 de todos modos, porque el filestore vive allí. Añade PGHOST=10.0.0.3 al servicio de abajo, y pon la contraseña en /etc/odoo-backup/pgpass como 10.0.0.3:5432:*:odoo:the-password (con dueño odoo y modo 600), con PGPASSFILE=/etc/odoo-backup/pgpass.
Ejecútalo cada noche
/etc/systemd/system/odoo-backup.service:
[Unit]
Description=Odoo backup to Hetzner Object Storage
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
User=odoo
Environment=AWS_CONFIG_FILE=/etc/odoo-backup/aws-config
Environment=AWS_SHARED_CREDENTIALS_FILE=/etc/odoo-backup/aws-credentials
ExecStart=/usr/local/bin/odoo-backup.sh
/etc/systemd/system/odoo-backup.timer:
[Unit]
Description=Nightly Odoo backup
[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true
[Install]
WantedBy=timers.target
Actívalo, ejecútalo una vez a mano y revisa el resultado:
systemctl daemon-reload
systemctl enable --now odoo-backup.timer
systemctl start odoo-backup.service
journalctl -u odoo-backup.service -n 50
systemctl list-timers odoo-backup.timer
aws s3 ls s3://your-odoo-backups/ --recursive
aws s3api get-object-retention --bucket your-odoo-backups --key "$(date +%F)/yourdb.dump"
El último comando debe mostrar COMPLIANCE y una fecha dentro de 14 días.
Prueba de restauración
Una copia que nunca restauraste es una esperanza, no una copia. Crea un servidor de prueba, descarga los archivos de anoche y restáuralos.
hcloud server create --name odoo-restore-test --type ccx23 --image ubuntu-24.04 \
--location hel1 --ssh-key my-laptop --firewall odoo-web
En él, instala Odoo y Postgres igual que en producción, más la AWS CLI y los mismos archivos de /etc/odoo-backup. Luego:
export AWS_CONFIG_FILE=/etc/odoo-backup/aws-config
export AWS_SHARED_CREDENTIALS_FILE=/etc/odoo-backup/aws-credentials
cd /tmp
aws s3 cp --recursive s3://your-odoo-backups/2026-10-25/ .
chown odoo:odoo yourdb.dump yourdb-filestore.tar.gz
sudo -u odoo bash -c '
createdb -O odoo yourdb_restored
pg_restore -d yourdb_restored --no-owner --role=odoo yourdb.dump
mkdir -p /var/lib/odoo/filestore/yourdb_restored
tar -xzf yourdb-filestore.tar.gz -C /var/lib/odoo/filestore/yourdb_restored --strip-components=1
'
Antes de arrancar Odoo en la copia, neutralízala. Una copia de producción sigue teniendo tus servidores de correo y tus tareas programadas, así que puede enviar correos a clientes reales. Como usuario odoo, ejecuta:
odoo neutralize -c /etc/odoo/odoo.conf -d yourdb_restored
Usa odoo-bin en lugar de odoo si ejecutas Odoo desde el código fuente. Esto apaga en la copia los servidores de correo saliente, las acciones programadas y los proveedores de pago. Nuestra guía sobre copiar producción a staging explica lo que cubre y lo que se le escapa.
Arranca Odoo con db_name = yourdb_restored. Entra, abre algunas facturas viejas y abre sus adjuntos en PDF. Si los adjuntos se abren, la copia funciona. Luego borra el servidor de prueba:
hcloud server delete odoo-restore-test
Hazlo otra vez cada pocos meses, y después de cada actualización grande de Odoo. Nuestra guía sobre cómo saber si una copia de Odoo se restaurará cubre qué revisar.
Copias de seguridad y snapshots de Hetzner
Hetzner tiene sus propias copias de seguridad y snapshots de servidor. Son útiles, pero no sustituyen a la copia de arriba.
- Las copias de seguridad se hacen una vez al día, a una hora que elige Hetzner. Cada servidor guarda hasta siete. Actívalas con
hcloud server enable-backup odoo-1. - Los snapshots se hacen cuando tú lo pides, y se quedan hasta que los borras.
- Ninguno de los dos incluye los volúmenes. Si tu filestore está en un volumen, no está en ellos.
- Copian el disco mientras Postgres está corriendo, y se quedan en Hetzner. Tu
pg_dumpes la copia en la que puedes confiar y que puedes llevar a cualquier sitio.
Activa las copias para tener una vuelta atrás rápida después de una mala actualización del sistema. Haz un snapshot justo antes de cada actualización de Odoo:
hcloud server create-image --type snapshot --description "before Odoo upgrade" odoo-1
hcloud image list --type snapshot
Para volver atrás, crea un servidor nuevo desde esa imagen con hcloud server create --image <snapshot-id> ....
Alertas
Hetzner muestra gráficos de CPU, de lecturas y escrituras de disco y de tráfico de red, en la Console o con hcloud server metrics --type cpu odoo-1. Muestran actividad, no lo lleno que está el disco, ni si Odoo responde. Esas alertas las configuras tú.
La copia no se hizo. Crea un check gratis en healthchecks.io, configúralo para esperar un ping al día, y pon su URL en la última línea del script de copia. Si falta una noche, recibes un correo.
El disco se llena. Crea un segundo check, y este script:
#!/bin/bash
# /usr/local/bin/disk-check.sh
set -euo pipefail
LIMIT=80
for M in / /var/lib/odoo; do
USE=$(df --output=pcent "$M" | tail -1 | tr -dc '0-9')
if [ "$USE" -ge "$LIMIT" ]; then
curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-DISK-UUID/fail > /dev/null
exit 0
fi
done
curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-DISK-UUID > /dev/null
Ejecútalo cada hora con un servicio y un timer como los de la copia (ExecStart=/usr/local/bin/disk-check.sh, OnCalendar=hourly).
Odoo está caído. Apunta cualquier servicio externo de uptime a https://odoo.example.com/web/health. Desde Odoo 17, responde {"status": "pass"} cuando Odoo funciona.
Enviar correo desde Odoo
Hetzner bloquea por defecto los puertos de salida 25 y 465 en los servidores cloud. El puerto 587 está abierto. Así que en Odoo, en Settings, Technical, Outgoing Mail Servers, usa el servidor SMTP de tu proveedor de correo en el puerto 587 con STARTTLS.
Si necesitas el puerto 25 o el 465, puedes pedir a Hetzner que los abra con una solicitud de límite en la Console. Es posible cuando tu cuenta tiene un mes y la primera factura está pagada. Hetzner decide caso por caso.
Trampas de Odoo en cualquier servidor, Hetzner incluido
- Websocket. Desde Odoo 16, el chat y las actualizaciones en vivo usan el puerto 8072. Tu proxy debe enviar
/websocketallí. - Proxy mode. Pon
proxy_mode = Truey envíaX-Forwarded-HostyX-Forwarded-Proto, o tus enlaces saldrán conhttp://. - Gestor de bases de datos. Pon
list_db = Falsey unadmin_passwdfuerte. - Disco. Los logs, el filestore y las copias locales crecen. Vigila el disco y rota los logs.
En odoo.conf:
proxy_mode = True
list_db = False
admin_passwd = a-long-random-password
workers = 5
gevent_port = 8072
En el bloque server de nginx:
location /websocket {
proxy_pass http://127.0.0.1:8072;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
Ajusta workers a la memoria del servidor, no al ejemplo de arriba.
Antes de salir en vivo
- Odoo corre con
workerspor encima de 0, ajustado a la memoria del servidor /websocketva al puerto 8072, y el chat funcionaproxy_mode = True, y los enlaces de los correos empiezan porhttps://list_db = Falsey unadmin_passwdfuerte- El firewall de Hetzner solo permite 80, 443 y tu propio SSH, y el puerto 8069 no responde desde fuera
- Si Postgres está en su propio servidor, escucha solo en la IP privada
- El correo saliente funciona en el puerto 587
- El certificado SSL se renueva solo
systemctl list-timersmuestra el timer de la copia, y los archivos de anoche están en el bucket con Object Lock- Los logs rotan, y recibes una alerta cuando el disco se llena, falta una copia u Odoo deja de responder
- Una copia de la base de datos y de los archivos se ha restaurado en otro servidor, y los adjuntos se abren
- Se hace un snapshot antes de cada actualización de Odoo
Quédate con Hetzner, déjanos el trabajo de Odoo
Puedes quedarte con tu servidor de Hetzner y aun así no gestionar Odoo tú mismo. Con bring your own server, el servidor sigue en tu cuenta de Hetzner y en la ubicación que elijas. Nosotros hacemos funcionar Odoo en él: despliegues desde Git, staging, copias de seguridad, actualizaciones y ayuda de expertos en Odoo. Tú mantienes el servidor en marcha y con el tamaño suficiente. Nuestro software se conecta desde tu servidor hacia fuera, así que no nos abres ningún puerto.
Skysize está hecho por ex ingenieros de Odoo y tiene la certificación ISO 27001.
Habla con un experto en hosting de Odoo
Preguntas frecuentes
¿Es Hetzner bueno para Odoo? Sí. Es rápido para lo que cuesta, y tiene ubicaciones en la UE, Estados Unidos y Singapur. Elige CPU dedicada para equipos que usan Odoo todo el día.
¿Tiene Hetzner PostgreSQL gestionado para Odoo? No. Pon Postgres en el servidor de Odoo, o en un segundo servidor en una red privada.
¿Bastan las copias de seguridad de Hetzner para Odoo? Solas no. No incluyen los volúmenes, y se quedan en Hetzner. Guarda también la base de datos y el filestore juntos, fuera del servidor, y prueba una restauración.
¿En qué ubicación de Hetzner guardo las copias de Odoo? En una distinta a la de tu servidor. Si el servidor está en Falkenstein o Núremberg, usa Helsinki. Si está en Helsinki, usa Falkenstein.
¿Por qué Odoo no puede enviar correo desde mi servidor de Hetzner? Los puertos 25 y 465 están bloqueados por defecto en Hetzner Cloud. Usa el puerto 587 con STARTTLS, o pide a Hetzner que abra los otros puertos cuando tu cuenta cumpla los requisitos.
¿Pongo el filestore de Odoo en un Hetzner Volume? Sí, si va a crecer. Un volumen puede crecer sin cambiar el servidor. Solo recuerda que las copias y los snapshots de Hetzner no incluyen los volúmenes, así que tu propia copia debe cubrirlo.