Se rendre au contenu

Odoo sur Hetzner : comment bien l'héberger

Odoo sur Hetzner : comment bien l'héberger
octobre 27, 2026 · 17 min de lecture

La réponse courte

Hetzner est un bon choix, peu cher, pour Odoo. Prenez un serveur cloud avec assez de mémoire. Mettez Postgres dessus ou sur un deuxième serveur, sur un réseau privé. Utilisez un Hetzner Cloud Firewall qui ne laisse entrer que 80, 443 et votre propre SSH. Envoyez chaque nuit une sauvegarde de la base et du filestore vers Object Storage, dans un autre site. Puis testez une restauration avant la mise en ligne.

Beaucoup d'équipes Odoo en Europe choisissent Hetzner. Les serveurs sont rapides pour leur prix, et vous pouvez choisir l'Allemagne, la Finlande, les États-Unis ou Singapour. Ce guide vous donne les commandes exactes pour y installer Odoo, pour qu'il reste rapide et sûr après la première semaine.

Pour l'installation elle-même (Odoo, Postgres, le fichier de configuration et le proxy), suivez notre guide sur Odoo sur un VPS. Cette page couvre ce qui change sur Hetzner.

Quel serveur Hetzner choisir

Installer l'outil hcloud

Vous pouvez tout faire dans la Hetzner Console. L'outil en ligne de commande hcloud est plus rapide et plus facile à refaire, c'est donc lui que nous utilisons ici.

D'abord, créez un token d'API. Dans la Hetzner Console, ouvrez votre projet, puis Security, puis API tokens, puis Generate API token. Choisissez Read & Write. Copiez le token tout de suite. Vous ne pourrez plus le voir.

Puis installez hcloud sur votre ordinateur et reliez-le au projet :

# 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 partagé ou dédié

Hetzner Cloud a deux types de serveurs :

  • vCPU partagé. Le CPU est partagé avec d'autres serveurs sur la même machine. Très bien pour les tests et les petites équipes.
  • vCPU dédié (par exemple CCX23). Le CPU est à vous seul. Mieux quand les gens utilisent Odoo toute la journée, car un CPU partagé peut ralentir quand vos voisins sont occupés, et les utilisateurs d'Odoo le sentent tout de suite.

Le minimum pour démarrer : 2 vCPU, 4 Go de mémoire et 50 Go de disque. Cela fait tourner Odoo et Postgres sur un seul serveur pour une petite équipe. La mémoire compte plus que le CPU : chaque worker a besoin de sa part, et Postgres veut la sienne. Pour plus d'utilisateurs, de gros imports ou Postgres sur son propre serveur, notre guide sur le nombre de workers Odoo dont vous avez besoin montre comment bien dimensionner.

Voyez ce qui est proposé :

hcloud server-type list
hcloud location list
hcloud image list --type system

Choisir l'emplacement

Vos données vivent là où vit le serveur. fsn1 (Falkenstein) et nbg1 (Nuremberg) sont en Allemagne. hel1 est Helsinki, en Finlande. ash et hil sont aux États-Unis, et sin est Singapour. Pour une entreprise de l'UE, un site en Allemagne ou en Finlande garde les données dans l'UE.

Créer le serveur

Ajoutez votre clé SSH, créez le pare-feu (section suivante), puis créez le serveur :

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

Gardez IPv4 et IPv6 (le réglage par défaut). Si vous ajoutez un enregistrement AAAA pour votre domaine, vérifiez que le proxy écoute aussi en IPv6, sinon certains utilisateurs n'arriveront pas sur Odoo.

Vérifier le CPU steal sur les serveurs partagés

Sur un serveur partagé, le « steal » est le temps pendant lequel votre serveur a attendu le vrai CPU. Vérifiez-le pendant les heures de travail :

vmstat 5 12

Regardez la dernière colonne, st. Si elle reste souvent au-dessus de quelques pour cent pendant que les utilisateurs trouvent Odoo lent, passez à un type dédié :

hcloud server poweroff odoo-1
hcloud server change-type --keep-disk odoo-1 ccx23
hcloud server poweron odoo-1

--keep-disk garde l'ancienne taille de disque, pour que vous puissiez redescendre plus tard.

Mettre le filestore sur un volume

Les pièces jointes vivent dans le filestore, et il grossit chaque jour. Un Hetzner Volume vous permet d'ajouter de l'espace disque sans changer de serveur. Créez-en un et attachez-le :

hcloud volume create --name odoo-data --size 100 --server odoo-1 --format ext4 --automount

Hetzner le monte sur /mnt/HC_Volume_<id>. Sur le serveur, déplacez les données d'Odoo dessus et remontez-les sur /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

Ouvrez quelques pièces jointes dans Odoo. Quand elles fonctionnent, supprimez /var/lib/odoo.old.

Pour l'agrandir plus tard :

hcloud volume resize --size 200 odoo-data
lsblk                            # find the device, often /dev/sdb
resize2fs /dev/sdb

Un volume peut seulement grandir, pas rétrécir. Encore une chose à savoir : les sauvegardes et snapshots de serveur Hetzner n'incluent pas les volumes. C'est votre propre sauvegarde (plus bas) qui protège le filestore.

Où mettre Postgres

Hetzner Cloud n'a pas de PostgreSQL managé. Vous le gérez donc vous-même, de l'une de ces deux façons :

  • Sur le même serveur qu'Odoo. Simple, et très bien pour la plupart des petites et moyennes équipes. Postgres écoute uniquement sur localhost, c'est le réglage par défaut. Rien d'autre à faire ici.
  • Sur un deuxième serveur, sur un réseau privé. Mieux quand la base devient grosse ou quand beaucoup d'utilisateurs travaillent en même temps.

Dans les deux cas, Odoo se connecte avec son propre utilisateur de base de données, odoo, jamais postgres.

Deuxième serveur : le réseau privé

Créez un réseau et un sous-réseau. Tous les serveurs d'un même réseau privé doivent être dans la même zone réseau. fsn1, nbg1 et hel1 sont tous dans 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

Deuxième serveur : Postgres écoute uniquement sur l'IP privée

Sur odoo-db (Ubuntu 24.04 fournit PostgreSQL 16) :

apt install -y postgresql
sudo -u postgres createuser --createdb --pwprompt odoo

Dans /etc/postgresql/16/main/postgresql.conf :

listen_addresses = 'localhost,10.0.0.3'

À la fin de /etc/postgresql/16/main/pg_hba.conf, n'autorisez que le serveur Odoo :

host    all    odoo    10.0.0.2/32    scram-sha-256

Redémarrez et vérifiez :

systemctl restart postgresql
ss -tlnp | grep 5432          # should show 127.0.0.1 and 10.0.0.3, never 0.0.0.0

Sur odoo-1, testez la connexion, puis indiquez ce serveur à Odoo dans 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

Attention : les Hetzner Cloud Firewalls ne filtrent pas le trafic à l'intérieur d'un réseau privé. C'est pour cela que Postgres doit écouter uniquement sur 10.0.0.3 et que pg_hba.conf doit autoriser uniquement 10.0.0.2.

Pare-feu

Un Hetzner Cloud Firewall bloque tout le trafic entrant tant que vous n'ajoutez pas de règles. Le trafic sortant reste ouvert. Créez-en un pour le serveur 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

Remplacez 203.0.113.10 par votre propre IP. Le ping (ICMP) reste ouvert, car il aide quand vous cherchez un problème.

Pour le serveur de base de données, n'autorisez que 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 un serveur existe déjà, attachez-lui le pare-feu avec :

hcloud firewall apply-to-resource odoo-web --type server --server odoo-1

Les ports d'Odoo (8069 et 8072) ne sont pas dans les règles, donc seul le proxy sur le même serveur peut les joindre. Vérifiez depuis votre ordinateur qu'ils sont fermés :

nc -zv -w 5 <server-ip> 8069    # should time out

Sauvegardes

Pour Odoo, il vous faut la base de données et le filestore, sauvegardés ensemble et copiés hors du serveur. Voici comment les envoyer vers Hetzner Object Storage, dans un autre site que votre serveur.

Choisir le site des sauvegardes

Object Storage existe à fsn1, nbg1 et hel1. Choisissez un site qui n'est pas celui de votre serveur :

  • Serveur à fsn1 ou nbg1 : mettez les sauvegardes à hel1.
  • Serveur à hel1 : mettez les sauvegardes à fsn1.
  • Serveur aux États-Unis ou à Singapour : Object Storage n'existe qu'en Europe, donc vos sauvegardes quitteraient votre région. Si cela compte pour vos données, utilisez plutôt un service de stockage dans votre propre région.

Utiliser un projet à part pour les sauvegardes

Chez Hetzner, les clés S3 fonctionnent sur tous les buckets du même projet. Donnez donc aux sauvegardes leur propre projet. Ainsi, la clé sur votre serveur ne peut joindre que le bucket des sauvegardes.

  1. Dans la Hetzner Console, créez un nouveau projet nommé odoo-backups.
  2. Dans ce projet, ouvrez Security, puis S3 Credentials, puis Generate credentials. Nommez-les odoo-1. Copiez tout de suite la clé d'accès et la clé secrète. Vous ne pourrez plus voir la clé secrète.

Installer l'AWS CLI et enregistrer les clés

Hetzner Object Storage parle l'API S3, donc l'AWS CLI fonctionne avec. Sur 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

Créer le bucket avec Object Lock

Object Lock empêche quiconque de supprimer une sauvegarde pendant un nombre de jours fixé. Ni vous, ni un script qui tourne mal, ni quelqu'un qui entre dans le serveur. Vous ne pouvez l'activer qu'à la création du bucket. Les noms de bucket sont partagés sur tout Hetzner, alors choisissez un nom unique.

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 mode COMPLIANCE, personne ne peut raccourcir le verrou une fois posé. C'est le but, mais commencez avec un nombre de jours dont vous êtes sûr. Le mode GOVERNANCE peut être annulé, ce qui veut aussi dire qu'une clé volée pourrait l'annuler.

Garder 30 jours, puis supprimer

Enregistrez ceci sous lifecycle.json. Les sauvegardes expirent après 30 jours, puis les anciennes versions et les marqueurs laissés par Object Lock sont nettoyés :

{
  "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

Le script de sauvegarde

/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 dernière ligne dit à un service extérieur que la sauvegarde a fonctionné. Plus de détails dans la partie Alertes. Puis :

mkdir -p /backups && chown odoo:odoo /backups
chmod 755 /usr/local/bin/odoo-backup.sh

Si Postgres tourne sur odoo-db, lancez quand même le script sur odoo-1, car le filestore vit là. Ajoutez PGHOST=10.0.0.3 au service ci-dessous, et mettez le mot de passe dans /etc/odoo-backup/pgpass sous la forme 10.0.0.3:5432:*:odoo:the-password (propriétaire odoo, mode 600) avec PGPASSFILE=/etc/odoo-backup/pgpass.

Le lancer chaque nuit

/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

Activez-le, lancez-le une fois à la main et vérifiez le résultat :

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"

La dernière commande doit afficher COMPLIANCE et une date dans 14 jours.

Test de restauration

Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde. Créez un serveur de test, récupérez les fichiers de la nuit dernière et restaurez-les.

hcloud server create --name odoo-restore-test --type ccx23 --image ubuntu-24.04 \
  --location hel1 --ssh-key my-laptop --firewall odoo-web

Dessus, installez Odoo et Postgres comme en production, plus l'AWS CLI et les mêmes fichiers /etc/odoo-backup. Puis :

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
'

Avant de démarrer Odoo sur la copie, neutralisez-la. Une copie de la production garde vos serveurs de messagerie et vos tâches planifiées, elle peut donc envoyer des e-mails à de vrais clients. En tant qu'utilisateur odoo, lancez :

odoo neutralize -c /etc/odoo/odoo.conf -d yourdb_restored

Utilisez odoo-bin au lieu de odoo si vous faites tourner Odoo depuis les sources. Cela désactive dans la copie les serveurs de messagerie sortants, les actions planifiées et les moyens de paiement. Notre guide sur la copie de la production vers le staging explique ce qu'elle couvre et ce qu'elle oublie.

Démarrez Odoo avec db_name = yourdb_restored. Connectez-vous, ouvrez quelques anciennes factures et leurs pièces jointes PDF. Si les pièces jointes s'ouvrent, la sauvegarde fonctionne. Puis supprimez le serveur de test :

hcloud server delete odoo-restore-test

Refaites-le tous les quelques mois, et après chaque grosse mise à jour d'Odoo. Notre guide sur comment savoir si une sauvegarde Odoo se restaurera explique quoi vérifier.

Sauvegardes et snapshots Hetzner

Hetzner a ses propres sauvegardes et snapshots de serveur. Ils sont utiles, mais ne remplacent pas la sauvegarde ci-dessus.

  • Les sauvegardes tournent une fois par jour, à une heure choisie par Hetzner. Chaque serveur en garde jusqu'à sept. Activez-les avec hcloud server enable-backup odoo-1.
  • Les snapshots se font à votre demande, et restent jusqu'à ce que vous les supprimiez.
  • Aucun des deux n'inclut les volumes. Si votre filestore est sur un volume, il n'y est pas.
  • Ils copient le disque pendant que Postgres tourne, et ils restent chez Hetzner. Votre pg_dump est la copie fiable, que vous pouvez déplacer n'importe où.

Activez les sauvegardes pour revenir vite en arrière après une mauvaise mise à jour du système. Prenez un snapshot juste avant chaque mise à jour d'Odoo :

hcloud server create-image --type snapshot --description "before Odoo upgrade" odoo-1
hcloud image list --type snapshot

Pour revenir en arrière, créez un nouveau serveur à partir de cette image avec hcloud server create --image <snapshot-id> ....

Alertes

Hetzner affiche des graphiques pour le CPU, les lectures et écritures disque et le trafic réseau, dans la Console ou avec hcloud server metrics --type cpu odoo-1. Ils montrent l'activité, pas le remplissage du disque, ni si Odoo répond. Ces alertes-là, mettez-les en place vous-même.

La sauvegarde n'a pas tourné. Créez un check gratuit sur healthchecks.io, réglez-le pour attendre un ping par jour, et mettez son URL dans la dernière ligne du script de sauvegarde. Si une nuit manque, vous recevez un e-mail.

Le disque se remplit. Créez un deuxième check, et ce 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

Lancez-le toutes les heures avec un service et un timer comme ceux de la sauvegarde (ExecStart=/usr/local/bin/disk-check.sh, OnCalendar=hourly).

Odoo est en panne. Pointez n'importe quel service de surveillance externe vers https://odoo.example.com/web/health. Depuis Odoo 17, il répond {"status": "pass"} quand Odoo fonctionne.

Envoyer des e-mails depuis Odoo

Hetzner bloque par défaut les ports sortants 25 et 465 sur les serveurs cloud. Le port 587 est ouvert. Dans Odoo, sous Settings, Technical, Outgoing Mail Servers, utilisez donc le serveur SMTP de votre fournisseur de messagerie sur le port 587 avec STARTTLS.

Si vous avez besoin du port 25 ou 465, vous pouvez demander à Hetzner de les ouvrir avec une demande de limite dans la Console. C'est possible une fois que votre compte a un mois et que la première facture est payée. Hetzner décide au cas par cas.

Les pièges Odoo sur tout serveur, Hetzner compris

  • Websocket. Depuis Odoo 16, le chat et les mises à jour en direct passent par le port 8072. Votre proxy doit y envoyer /websocket.
  • Proxy mode. Mettez proxy_mode = True et envoyez X-Forwarded-Host et X-Forwarded-Proto, sinon vos liens sortent en http://.
  • Gestionnaire de bases. Mettez list_db = False et un admin_passwd solide.
  • Disque. Les logs, le filestore et les sauvegardes locales grossissent. Surveillez le disque et faites tourner les logs.

Dans odoo.conf :

proxy_mode = True
list_db = False
admin_passwd = a-long-random-password
workers = 5
gevent_port = 8072

Dans le bloc 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;
}

Réglez workers selon la mémoire du serveur, pas selon l'exemple ci-dessus.

Avant la mise en ligne

  • Odoo tourne avec workers au-dessus de 0, réglé selon la mémoire du serveur
  • /websocket va vers le port 8072, et le chat fonctionne
  • proxy_mode = True, et les liens dans les e-mails commencent par https://
  • list_db = False et un admin_passwd solide
  • Le pare-feu Hetzner n'autorise que 80, 443 et votre propre SSH, et le port 8069 ne répond pas depuis l'extérieur
  • Si Postgres est sur son propre serveur, il écoute uniquement sur l'IP privée
  • L'envoi d'e-mails fonctionne sur le port 587
  • Le certificat SSL se renouvelle tout seul
  • systemctl list-timers affiche le timer de sauvegarde, et les fichiers de la nuit dernière sont dans le bucket avec Object Lock
  • Les logs tournent, et vous recevez une alerte quand le disque se remplit, qu'une sauvegarde manque ou qu'Odoo ne répond plus
  • Une sauvegarde de la base et des fichiers a été restaurée sur un autre serveur, et les pièces jointes s'ouvrent
  • Un snapshot est pris avant chaque mise à jour d'Odoo

Gardez Hetzner, confiez-nous le travail Odoo

Vous pouvez garder votre serveur Hetzner sans gérer Odoo vous-même. Avec bring your own server, le serveur reste dans votre compte Hetzner et à l'emplacement de votre choix. Nous faisons tourner Odoo dessus : déploiements depuis Git, staging, sauvegardes, mises à jour et l'aide d'experts Odoo. Vous gardez le serveur en marche et assez grand. Notre logiciel se connecte depuis votre serveur vers l'extérieur, vous n'ouvrez donc aucun port pour nous.

Skysize est conçu par d'anciens ingénieurs d'Odoo et certifié ISO 27001.

Parlez à un expert en hébergement Odoo

FAQ

Hetzner est-il un bon choix pour Odoo ? Oui. Il est rapide pour son prix, avec des sites dans l'UE, aux États-Unis et à Singapour. Prenez un CPU dédié pour les équipes qui utilisent Odoo toute la journée.

Hetzner propose-t-il un PostgreSQL managé pour Odoo ? Non. Faites tourner Postgres sur le serveur Odoo, ou sur un deuxième serveur sur un réseau privé.

Les sauvegardes Hetzner suffisent-elles pour Odoo ? Pas seules. Elles n'incluent pas les volumes, et elles restent chez Hetzner. Sauvegardez aussi la base et le filestore ensemble, hors du serveur, et testez une restauration.

Quel site Hetzner doit accueillir mes sauvegardes Odoo ? Un autre que celui de votre serveur. Si le serveur est à Falkenstein ou Nuremberg, utilisez Helsinki. S'il est à Helsinki, utilisez Falkenstein.

Pourquoi Odoo n'arrive-t-il pas à envoyer d'e-mails depuis mon serveur Hetzner ? Les ports 25 et 465 sont bloqués par défaut sur Hetzner Cloud. Utilisez le port 587 avec STARTTLS, ou demandez à Hetzner d'ouvrir les autres ports quand votre compte remplit les conditions.

Faut-il mettre le filestore Odoo sur un Hetzner Volume ? Oui, s'il va grossir. Un volume peut grandir sans changer de serveur. Souvenez-vous seulement que les sauvegardes et snapshots Hetzner ignorent les volumes : votre propre sauvegarde doit donc le couvrir.

Odoo sur Hetzner : comment bien l'héberger
Écrit sur l'infrastructure Odoo chez Skysize, un hébergeur Odoo basé en Belgique, créé par d'anciens ingénieurs Odoo et certifié ISO 27001, servant des entreprises et des agences dans le monde entier.

Continuez à lire

Tous les articles →