Odoo AWS : déployer sur EC2 et préparer la reprise

Un déploiement Odoo AWS demande une instance EC2, PostgreSQL et un stockage persistant pour le filestore. Vous pouvez réunir le tout sur un serveur si vous acceptez son indisponibilité. RDS sépare l'exploitation de la base, mais laisse les pièces jointes sur EC2. Son indicateur de sauvegarde ne suffit donc pas à prouver que votre ERP redémarrera avec ses documents.

Ce tutoriel concerne une installation neuve d'Odoo 19 Community, PostgreSQL 16 et Docker Compose sous Linux. Enterprise demande ses modules supplémentaires et son abonnement. Sources et tarifs vérifiés le 5 novembre 2026. Les étapes AWS sont une procédure documentaire : nous ne revendiquons ni déploiement ni mesure de charge sur un compte AWS pendant cette rédaction.

1. Dessiner le déploiement Odoo AWS avant de créer les ressources#

Pour commencer, une instance EC2 et un volume EBS chiffré peuvent accueillir l'application et PostgreSQL. Placez les deux volumes Docker sur EBS, dont /var/lib/odoo, qui contient le filestore. Écartez le stockage temporaire local de l'instance pour l'unique copie de vos documents.

Choisissez une région et consignez-la avec votre configuration. Paris, eu-west-3, sert au calcul de prix ci-dessous. Ce choix ne démontre pas à lui seul la conformité au RGPD : vérifiez aussi la destination des sauvegardes et les personnes qui peuvent y accéder.

Gardez RDS privé. Autorisez 5432 depuis le security group applicatif, jamais depuis Internet. Déplacer PostgreSQL ne déplace pas les pièces jointes et ne rend pas Odoo hautement disponible. Le serveur applicatif unique reste un point de panne.

2. Dimensionner sur vos traitements plutôt que sur le nom de l'instance#

Choisissez CPU et mémoire à partir d'imports, de rapports et de requêtes simultanées représentatifs. Le guide de déploiement Odoo 19 (nouvel onglet) propose (CPU × 2) + 1 comme estimation du nombre de workers. Il rappelle que les crons consomment aussi du CPU. Ce calcul ne garantit aucune capacité pour vos modules spécifiques.

Ajoutez PostgreSQL et le système au budget des workers HTTP. limit_memory_hard borne la mémoire virtuelle d'un worker sans réserver de RAM physique, si bien qu'une petite instance peut épuiser sa mémoire avec un nombre de workers copié d'une grosse machine alors que chacun reste sous son seuil individuel. Mesurez aussi l'hôte.

La t3.medium utilisée pour le calcul financier fonctionne avec des crédits CPU. Elle illustre une facture, pas une recommandation de capacité en production. Surveillez ces crédits pendant les traitements prolongés et prévoyez les éventuels crédits supplémentaires facturés. Pour une charge CPU soutenue, comparez une famille sans crédits avant d'acheter sur le seul nombre de vCPU.

Mesurez séparément la croissance de la base et des pièces jointes. Prévoyez l'espace des dumps et des opérations de maintenance. Le disque qui contient les données aujourd'hui ne contiendra peut-être pas leur sauvegarde demain. Remplacer EC2 ne libère pas un système de fichiers plein.

3. Installer en privé puis n'ouvrir que le proxy#

Préparez un hôte EC2 Linux avec Docker Engine et le plugin Compose installés. Attribuez-lui un rôle IAM pour les accès AWS nécessaires, plutôt que de déposer une clé d'accès dans le dossier applicatif. Réservez l'administration à votre réseau de gestion ou à une connexion Session Manager configurée. N'ouvrez pas SSH à tous pour gagner quelques minutes.

Reprenez la procédure Docker Compose et restauration pour les volumes, les identifiants PostgreSQL distincts et l'initialisation. Elle cible Odoo 20 : pour ce déploiement Odoo 19, remplacez son image Odoo par un build officiel odoo:19.0 et notez le digest téléchargé. Conservez PostgreSQL 16 et des modules compatibles Odoo 19. Ces instructions créent une base neuve ; elles ne rétrogradent pas une base existante.

Dans la configuration du service Compose web, ajustez workers à vos mesures, sélectionnez la base avec db_name et dbfilter, puis désactivez sa liste avec list_db = False. Gardez un mot de passe maître Odoo distinct des identifiants PostgreSQL. Aucun de ces secrets ne va dans Git.

Publiez les ports de l'hôte sur 127.0.0.1:8069 et 127.0.0.1:8072. Installez Nginx sur l'hôte pour terminer HTTPS et router /websocket vers 8072 en mode multiprocessus. Activez proxy_mode uniquement derrière ce proxy de confiance. Bloquez aussi /web/database au proxy.

Dans le security group EC2, autorisez 443 depuis Internet. N'ouvrez 80 que si la redirection HTTP ou votre validation de certificat l'exige. Ne publiez jamais 5432, 8069 ou 8072 sur Internet. Depuis une autre machine, contrôlez votre propre serveur :

curl -I https://erp.example.com/web/login
curl -sS -o /dev/null -w '%{http_code}\n' \
  https://erp.example.com/web/database/manager

Le gestionnaire doit répondre 403 avec le blocage indiqué. Inspectez aussi la connexion websocket dans le navigateur : le statut attendu est 101. Vérifiez de l'extérieur que les ports internes restent fermés, en IPv6 également si vous l'activez. Une connexion réussie à Odoo ne valide pas ces autres chemins.

4. Choisir RDS avant de charger les données de production#

Gardez PostgreSQL sur EC2 si la panne d'un hôte constitue une limite acceptable et si votre équipe sait le corriger et le restaurer. Choisissez RDS pour un besoin précis d'exploitation de la base. Ajouter une brique au schéma ne justifie pas sa facture.

Pour RDS, créez une instance PostgreSQL prise en charge dans des sous-réseaux privés et un rôle applicatif dédié. N'exécutez pas Odoo avec le compte maître RDS. Renseignez db_host, db_port, db_user et db_password dans votre configuration de déploiement protégée, avec une validation du certificat TLS adaptée au point d'accès RDS.

Vérifiez les connexions disponibles pour la classe RDS retenue. db_maxconn règle un pool par processus Odoo, pas un total pour le serveur. Comptez les workers HTTP et l'activité cron avant de comparer avec max_connections côté PostgreSQL. Gardez une réserve pour l'administration et mesurez les connexions sous charge avant de relever les limites.

La base RDS restaurée doit retrouver son filestore correspondant. Définissez et testez cet appariement avant la bascule. Restaurer des lignes à un instant plus récent en gardant d'anciens fichiers sur EBS peut laisser des pièces jointes impossibles à ouvrir.

5. Produire un ensemble de reprise sans écritures concurrentes#

Pour la variante Compose sur un seul hôte, arrêtez tous les processus Odoo capables d'écrire avant de copier PostgreSQL et son filestore. Cela inclut les crons et tout autre processus qui écrit dans cette base. Un snapshot EBS pris indépendamment du dump ne prouve pas que les deux représentent le même état applicatif.

Depuis le dossier Compose, dans un shell Bash dédié, ce bloc produit un ensemble pour la base erp. Il suppose les services db et web, ainsi que les volumes de la procédure Docker liée, avec PostgreSQL local :

set -eu
umask 077
backup="backups/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$backup"
docker compose stop -t 120 web
trap 'docker compose start web' EXIT
docker compose exec -T db pg_dump -U odoo -Fc erp > "$backup/db.dump.part"
docker compose run --rm --no-deps --entrypoint tar web \
  -C /var/lib/odoo -czf - filestore/erp > "$backup/filestore.tar.gz.part"
mv "$backup/db.dump.part" "$backup/db.dump"
mv "$backup/filestore.tar.gz.part" "$backup/filestore.tar.gz"
sha256sum "$backup/db.dump" "$backup/filestore.tar.gz" > "$backup/SHA256SUMS"

Tout ensemble contenant un fichier .part reste incomplet. Chiffrez les ensembles terminés et copiez-les hors de l'hôte, avec une rétention protégée contre la suppression par les identifiants applicatifs. Conservez aussi les digests des images, la configuration et les révisions des modules. Ce bloc ne s'applique pas tel quel à RDS.

Restaurez sur une machine isolée dont les intégrations sortantes sont désactivées. Importez le dump dans une base vide, remettez le filestore correspondant, puis démarrez Odoo avec les crons désactivés. Ouvrez une pièce jointe connue et produisez un rapport. Notez la durée de reprise et l'ancienneté des données récupérées pour les comparer à vos objectifs.

6. Chiffrer le serveur sans oublier le travail#

Pour Linux à la demande à Paris, le catalogue tarifaire EC2 d'AWS (nouvel onglet) indique 0,0472 USD/h pour t3.medium et 0,0928 USD/Go-mois pour gp3. Le catalogue VPC d'AWS (nouvel onglet) indique 0,005 USD/h pour une IPv4 publique utilisée. AWS publie ces prix en dollars ; aucune conversion en euros n'est supposée.

Ce sous-total exclut RDS, les snapshots, le stockage des sauvegardes, le trafic sortant, les performances disque supplémentaires, les crédits CPU facturables et le travail humain. Ne le présentez pas comme le coût total d'Odoo. Si vous séparez la base, ajoutez votre classe RDS et votre rétention des sauvegardes à une estimation régionale.

Attribuez à quelqu'un les correctifs système et PostgreSQL, le renouvellement des certificats, les alertes disque et les exercices de restauration. Le comparatif des hébergements Odoo aide à comparer ce travail aux autres options. Pour tester vos modules sur une plateforme en libre accès, essayez Ofleet sur une instance de test distincte et comparez les tâches de déploiement qui vous restent.