Odoo sur AWS : comment bien l'héberger

La réponse courte

Pour héberger Odoo sur AWS, faites-le tourner sur une instance EC2 avec un disque EBS gp3. Mettez Postgres sur la même instance ou sur Amazon RDS. N'ouvrez que les ports 80 et 443, et connectez-vous avec Systems Manager au lieu de SSH. Envoyez les sauvegardes de la base et des fichiers vers un bucket S3 où l'instance peut écrire, mais ni lire ni supprimer. Évitez les instances burstable pour la production, et testez une restauration avant la mise en ligne.

Beaucoup d'entreprises ont déjà un compte AWS, alors Odoo y va aussi. AWS a une région près de presque tout le monde. Il offre aussi beaucoup de façons de mal régler Odoo, juste un peu. Ce guide vous donne les commandes exactes pour chaque étape AWS.

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 AWS.

Vous pouvez lancer toutes les commandes aws ci-dessous depuis votre propre ordinateur avec l'AWS CLI, ou depuis AWS CloudShell dans la console. Remplacez les identifiants en majuscules par les vôtres.

Quelle instance EC2 choisir

Deux choses comptent le plus pour Odoo :

• La mémoire. Le minimum pour démarrer est de 2 vCPU, 4 Go de mémoire et un disque de 50 Go. Cela fait tourner Odoo et Postgres sur une seule instance pour une petite équipe. Chaque worker a besoin de sa part de mémoire, et Postgres veut la sienne. Pour plus d'utilisateurs, de gros imports ou RDS, notre guide sur le nombre de workers Odoo dont vous avez besoin montre comment bien dimensionner.
• Un CPU stable. Odoo travaille toute la journée, tant que les gens l'utilisent.

Pourquoi pas une instance T

Les instances T (par exemple t3 ou t4g) sont « burstable ». Elles gagnent des crédits CPU quand elles sont calmes et les dépensent quand elles sont occupées. Les nouvelles instances T3, T3a et T4g démarrent en mode « unlimited ». Dans ce mode, l'instance ne ralentit jamais, mais si son CPU moyen reste au-dessus d'un seuil fixé sur 24 heures, AWS facture le surplus. Selon les propres calculs d'AWS, une T3 qui tourne à fond coûte plus cher qu'une M5 de même taille. Un Odoo utilisé toute la journée vit souvent au-dessus de ce seuil.

Pour la production, choisissez donc une famille à performance fixe :

• Famille M (usage général), par exemple m7i.large ou m7g.large. Un bon choix par défaut.
• Famille R (plus de mémoire par CPU), par exemple r7i.large. Bien quand Postgres tourne sur la même instance et que la base est grosse.

Les instances T conviennent pour une copie de test que peu de gens utilisent.

Graviton (ARM) convient, si les PDF s'impriment

Les instances avec un « g » dans le nom, comme m7g, utilisent les puces AWS Graviton (arm64). Odoo et Postgres tournent bien dessus. Le seul point à vérifier est wkhtmltopdf, qu'Odoo utilise pour imprimer les PDF. Ses paquets officiels pour arm64 existent pour Ubuntu 22.04 (jammy) et Debian 12 (bookworm). Choisissez l'un des deux, installez le paquet arm64 correspondant, et imprimez une facture avant la mise en ligne. Si votre système n'est pas dans cette liste, utilisez une instance Intel ou AMD (par exemple m7i ou m7a). Si vous pensez nous confier le travail Odoo plus tard, choisissez aussi Intel ou AMD : notre logiciel bring your own server tourne uniquement sur des serveurs x86.

Disque : EBS gp3

Gardez toutes les données sur EBS, pas sur les disques instance store. L'instance store est effacé quand l'instance s'arrête.

Utilisez le type de volume gp3. Il donne 3 000 IOPS et 125 Mio/s stables, quelle que soit la taille, et vous pouvez augmenter les deux plus tard sans prendre un plus gros disque. Gardez de la place pour le filestore et trois jours de sauvegardes locales.

Région

Choisissez la région avec soin. Vos données vivent dans la région choisie. Mettez l'instance, la base et le bucket de sauvegarde dans la même région, sauf si vous voulez exprès des sauvegardes dans une deuxième région.

Où mettre Postgres

Vous avez deux bonnes options :

• Sur la même instance EC2. Simple, et très bien pour beaucoup d'équipes. Suivez le guide VPS tel quel.
• Sur Amazon RDS for PostgreSQL. AWS gère le serveur de base de données, les correctifs et la restauration à un instant donné. Les étapes sont ci-dessous.

Préparer RDS pour Odoo

RDS a besoin d'un « DB subnet group » : au moins deux sous-réseaux dans deux Availability Zones différentes, dans le même VPC que votre instance EC2. Trouvez vos sous-réseaux, puis créez le groupe :

aws ec2 describe-subnets --filters Name=vpc-id,Values=VPC_ID \
  --query 'Subnets[].[SubnetId,AvailabilityZone]' --output table

aws rds create-db-subnet-group \
  --db-subnet-group-name odoo-db-subnets \
  --db-subnet-group-description "Odoo database" \
  --subnet-ids '["SUBNET_A","SUBNET_B"]'

La base a aussi besoin de son propre security group. Créez-le maintenant avec les commandes de la section suivante (odoo-db). Puis créez la base :

aws rds create-db-instance \
  --db-instance-identifier odoo-db \
  --engine postgres \
  --db-instance-class db.m7g.large \
  --storage-type gp3 \
  --allocated-storage 50 \
  --master-username odoo_admin \
  --manage-master-user-password \
  --db-subnet-group-name odoo-db-subnets \
  --vpc-security-group-ids SG_ODOO_DB \
  --no-publicly-accessible \
  --backup-retention-period 14 \
  --storage-encrypted \
  --deletion-protection

Ce que font ces options :

• --manage-master-user-password laisse RDS créer le mot de passe admin et le garder dans Secrets Manager. Il ne se retrouve jamais dans l'historique de votre shell.
• --no-publicly-accessible garde la base hors d'internet.
• --backup-retention-period 14 garde 14 jours de sauvegardes RDS. Depuis la CLI, la valeur par défaut n'est que de 1 jour.
• --deletion-protection empêche quiconque de supprimer la base par erreur.
• Ajoutez --multi-az si vous voulez une copie de secours dans une deuxième zone.
• Ajoutez --engine-version pour choisir une version de Postgres. aws rds describe-db-engine-versions --engine postgres les liste.

Créer l'utilisateur de base de données odoo

Odoo a besoin de son propre utilisateur, qui peut créer des bases. N'utilisez pas l'utilisateur admin RDS au quotidien.

Récupérez le mot de passe admin et l'adresse de la base :

SECRET_ARN=$(aws rds describe-db-instances --db-instance-identifier odoo-db \
  --query 'DBInstances[0].MasterUserSecret.SecretArn' --output text)
aws secretsmanager get-secret-value --secret-id "$SECRET_ARN" \
  --query SecretString --output text

aws rds describe-db-instances --db-instance-identifier odoo-db \
  --query 'DBInstances[0].Endpoint.Address' --output text

Sur l'instance Odoo, connectez-vous avec psql et créez l'utilisateur :

psql "host=YOUR_RDS_ENDPOINT user=odoo_admin dbname=postgres sslmode=require"

CREATE ROLE odoo WITH LOGIN CREATEDB PASSWORD 'a-long-random-password';

L'utilisateur admin RDS n'est pas un vrai superuser Postgres, mais il peut créer des rôles comme celui-ci.

Relier Odoo à RDS

Dans odoo.conf :

db_host = YOUR_RDS_ENDPOINT
db_port = 5432
db_user = odoo
db_password = a-long-random-password
db_sslmode = require

Depuis Postgres 15, RDS active rds.force_ssl par défaut. Il refuse les connexions sans SSL. db_sslmode = require fait qu'Odoo l'utilise toujours.

Prendre la bonne version du client Postgres

pg_dump refuse de sauvegarder un serveur d'une version majeure plus récente que la sienne. Si RDS tourne en Postgres 17, l'instance Odoo a besoin du client en version 17. Installez-le depuis le dépôt apt de PostgreSQL :

sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install -y postgresql-client-17

Les sauvegardes RDS ne couvrent pas le filestore

RDS sauvegarde la base de données et peut la restaurer à n'importe quelle seconde de la période de rétention. Il ne sauvegarde pas le filestore. Les pièces jointes et les images vivent sur le disque EC2, dans /var/lib/odoo/filestore. Il vous faut quand même la sauvegarde S3 ci-dessous, pour que la base et les fichiers soient sauvegardés ensemble.

Réseau et security groups

Security groups

Créez un groupe pour l'instance Odoo et un pour la base :

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true \
  --query 'Vpcs[0].VpcId' --output text)

aws ec2 create-security-group --group-name odoo-web \
  --description "Odoo web" --vpc-id "$VPC_ID"
aws ec2 authorize-security-group-ingress --group-id SG_ODOO_WEB \
  --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id SG_ODOO_WEB \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Il n'y a pas de règle pour le port 22. Vous vous connecterez avec Systems Manager à la place.

Si vous utilisez RDS, laissez seulement l'instance Odoo joindre Postgres. La règle vise le groupe odoo-web, pas une adresse IP :

aws ec2 create-security-group --group-name odoo-db \
  --description "Odoo database" --vpc-id "$VPC_ID"
aws ec2 authorize-security-group-ingress --group-id SG_ODOO_DB \
  --protocol tcp --port 5432 --source-group SG_ODOO_WEB

Les ports d'Odoo (8069 et 8072) restent fermés. Seul nginx, sur l'instance, leur parle.

Un rôle IAM pour l'instance

L'instance a besoin d'une identité dans AWS. Elle lui permet d'utiliser Systems Manager, d'envoyer les mesures du disque et, plus tard, d'écrire les sauvegardes. Enregistrez ceci sous ec2-trust.json :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Puis créez le rôle et son instance profile :

aws iam create-role --role-name odoo-server \
  --assume-role-policy-document file://ec2-trust.json
aws iam attach-role-policy --role-name odoo-server \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name odoo-server \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws iam create-instance-profile --instance-profile-name odoo-server
aws iam add-role-to-instance-profile \
  --instance-profile-name odoo-server --role-name odoo-server

Une instance EC2 ne prend pas un rôle directement. Elle prend un « instance profile » qui contient le rôle. Si vous créez le rôle dans la console IAM, la console crée le profile pour vous, avec le même nom.

Lancer l'instance

Dans la console EC2, allez dans Instances > Launch instances et réglez :

• AMI: Ubuntu Server 22.04 LTS ou Debian 12 (voir la note Graviton plus haut)
• Instance type: par exemple m7i.large ou m7g.large
• Key pair: inutile, car vous n'utiliserez pas SSH
• Network settings: votre VPC, un sous-réseau public et le groupe existant odoo-web
• Storage: gp3, assez grand pour le filestore et les sauvegardes
• Advanced details > IAM instance profile: odoo-server

Si l'instance tourne déjà, attachez-lui le profile avec :

aws ec2 associate-iam-instance-profile --instance-id INSTANCE_ID \
  --iam-instance-profile Name=odoo-server

Une adresse fixe

Donnez à l'instance une Elastic IP, pour que son adresse ne change pas quand elle s'arrête et redémarre :

aws ec2 allocate-address --domain vpc
aws ec2 associate-address --instance-id INSTANCE_ID --allocation-id EIPALLOC_ID

Faites pointer l'enregistrement DNS de votre domaine vers cette adresse avant de demander un certificat à Let's Encrypt.

Se connecter avec Session Manager, pas SSH

AWS Systems Manager Session Manager vous donne un shell sans port ouvert et sans clé SSH. Les AMI Ubuntu Server ont déjà l'agent SSM. La politique AmazonSSMManagedInstanceCore sur le rôle fait le reste. L'instance a seulement besoin du HTTPS sortant, que les security groups autorisent par défaut.

Pour vous connecter, ouvrez l'instance dans la console EC2 et choisissez Connect > Session Manager. Ou, depuis votre ordinateur, installez le plugin Session Manager de l'AWS CLI et lancez :

aws ssm start-session --target INSTANCE_ID

Vous arrivez en tant que ssm-user, qui peut utiliser sudo.

Sauvegardes vers S3

Créer le bucket

aws s3api create-bucket --bucket your-odoo-backups --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1

En us-east-1, retirez la ligne --create-bucket-configuration. Les noms de bucket sont partagés par tous les clients AWS, alors ajoutez quelque chose d'unique au vôtre.

Bloquez l'accès public. Les nouveaux buckets le bloquent déjà, et ceci le rend explicite :

aws s3api put-public-access-block --bucket your-odoo-backups \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Activez le versioning. Si un fichier de sauvegarde est un jour écrasé ou supprimé, l'ancienne copie reste comme version précédente :

aws s3api put-bucket-versioning --bucket your-odoo-backups \
  --versioning-configuration Status=Enabled

Supprimer les anciennes sauvegardes à date fixe

Enregistrez ceci sous lifecycle.json :

{
  "Rules": [
    {
      "ID": "expire-old-odoo-backups",
      "Filter": { "Prefix": "" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket your-odoo-backups \
  --lifecycle-configuration file://lifecycle.json

Les sauvegardes de plus de 30 jours sont supprimées. Avec le versioning, « supprimé » veut d'abord dire « caché ». La copie cachée reste encore 30 jours, puis part pour de bon. La dernière ligne nettoie les envois coupés en route. Cette commande remplace les règles de cycle de vie que le bucket avait avant.

Laisser l'instance écrire, et seulement écrire

Voici la politique du rôle. Elle autorise une seule action, s3:PutObject, sur un seul bucket. Enregistrez-la sous backup-write.json :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteOdooBackupsOnly",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-odoo-backups/*"
    }
  ]
}

aws iam put-role-policy --role-name odoo-server \
  --policy-name odoo-backup-write --policy-document file://backup-write.json

s3:PutObject couvre aussi les gros fichiers, que la CLI envoie en plusieurs parties. L'instance ne peut ni lister, ni lire, ni supprimer quoi que ce soit dans le bucket. Si quelqu'un entre dans le serveur, il ne peut pas effacer vos sauvegardes. Avec le versioning, même un fichier écrasé laisse l'ancienne copie en place.

Si vos règles internes demandent plus, S3 Object Lock peut bloquer les suppressions pendant un nombre de jours fixé, même pour un admin. Une fois activé sur un bucket, vous ne pouvez plus le désactiver. Testez-le d'abord sur un bucket de test.

Installer l'AWS CLI sur l'instance

sudo apt install -y unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Sur Graviton, utilisez plutôt awscli-exe-linux-aarch64.zip. La CLI récupère seule les identifiants du rôle. Vous ne stockez jamais de clé d'accès sur le serveur.

Le script de sauvegarde

Créez d'abord le dossier local :

sudo mkdir -p /backups
sudo chown odoo:odoo /backups

Enregistrez ceci sous /usr/local/bin/odoo-backup.sh et lancez sudo chmod 755 dessus :

#!/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 {} +

Avec RDS, pg_dump doit se connecter par le réseau. Remplacez la ligne pg_dump par :

pg_dump -h YOUR_RDS_ENDPOINT -U odoo -Fc "$DB" > "$DIR/$DB.dump"

Puis donnez à l'utilisateur odoo son mot de passe dans un fichier .pgpass, dans son dossier personnel :

sudo -u odoo -H bash -c 'echo "YOUR_RDS_ENDPOINT:5432:*:odoo:a-long-random-password" > ~/.pgpass && chmod 600 ~/.pgpass'

Le * permet à la même ligne de servir pour toutes les bases, y compris celle du test de restauration.

Le lancer chaque nuit

Créez /etc/systemd/system/odoo-backup.service :

[Unit]
Description=Odoo backup to S3
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=odoo
ExecStart=/usr/local/bin/odoo-backup.sh

Et /etc/systemd/system/odoo-backup.timer :

[Unit]
Description=Run the Odoo backup every night

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

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

sudo systemctl daemon-reload
sudo systemctl enable --now odoo-backup.timer
sudo systemctl start odoo-backup.service
journalctl -u odoo-backup.service -n 20

Depuis votre propre ordinateur, vérifiez que les fichiers sont arrivés :

aws s3 ls s3://your-odoo-backups/ --recursive

Tester une restauration

L'instance de production ne peut pas lire le bucket. C'est voulu. Le test de restauration tourne donc sur une deuxième instance, avec son propre rôle en lecture seule. Installez-y Odoo avec le guide VPS, puis enregistrez ceci sous backup-read.json :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOdooBackups",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::your-odoo-backups"
    },
    {
      "Sid": "ReadOdooBackups",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-odoo-backups/*"
    }
  ]
}

Créez le rôle comme avant, avec le même ec2-trust.json :

aws iam create-role --role-name odoo-restore \
  --assume-role-policy-document file://ec2-trust.json
aws iam attach-role-policy --role-name odoo-restore \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam put-role-policy --role-name odoo-restore \
  --policy-name odoo-backup-read --policy-document file://backup-read.json
aws iam create-instance-profile --instance-profile-name odoo-restore
aws iam add-role-to-instance-profile \
  --instance-profile-name odoo-restore --role-name odoo-restore
aws ec2 associate-iam-instance-profile --instance-id TEST_INSTANCE_ID \
  --iam-instance-profile Name=odoo-restore

Sur l'instance de test, en tant qu'utilisateur odoo, récupérez la sauvegarde d'une nuit et restaurez-la :

mkdir -p /tmp/restore && cd /tmp/restore
aws s3 cp --recursive s3://your-odoo-backups/2026-10-25/ .
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

Si la copie de test utilise RDS, ajoutez -h YOUR_RDS_ENDPOINT -U odoo à createdb et pg_restore.

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.

Puis connectez-vous à yourdb_restored et ouvrez quelques pièces jointes. Notre guide sur comment savoir si une sauvegarde Odoo se restaurera explique le test complet.

Recevoir une alerte avant que le disque soit plein

Les logs, le filestore et les sauvegardes locales grossissent. AWS ne voit pas le remplissage de votre disque, sauf si vous lui envoyez ce chiffre. L'agent CloudWatch s'en charge.

Installez-le sur l'instance (mettez arm64 dans l'adresse sur Graviton) :

curl -O https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

Enregistrez ceci sous /opt/aws/amazon-cloudwatch-agent/etc/odoo-disk.json :

{
  "metrics": {
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"],
        "drop_device": true,
        "metrics_collection_interval": 60
      }
    }
  }
}

Démarrez l'agent avec ce fichier :

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/odoo-disk.json

La mesure apparaît dans CloudWatch sous le nom disk_used_percent, dans le namespace CWAgent. Une alarme ne se déclenche que si elle donne exactement les mêmes dimensions. Listez-les donc d'abord, depuis votre ordinateur :

aws cloudwatch list-metrics --namespace CWAgent \
  --metric-name disk_used_percent \
  --dimensions Name=InstanceId,Value=INSTANCE_ID

Créez un topic pour les e-mails, et confirmez l'e-mail qu'AWS vous envoie :

aws sns create-topic --name odoo-alerts
aws sns subscribe --topic-arn TOPIC_ARN \
  --protocol email --notification-endpoint [email protected]

Puis créez l'alarme. Copiez les dimensions depuis le résultat de list-metrics. Sur Ubuntu, ce sont en général celles-ci :

aws cloudwatch put-metric-alarm \
  --alarm-name odoo-disk-80 \
  --namespace CWAgent --metric-name disk_used_percent \
  --dimensions Name=InstanceId,Value=INSTANCE_ID Name=path,Value=/ Name=fstype,Value=ext4 \
  --statistic Average --period 300 --evaluation-periods 1 \
  --threshold 80 --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data breaching \
  --alarm-actions TOPIC_ARN

--treat-missing-data breaching vous prévient aussi si l'agent arrête d'envoyer.

E-mails sortants

Par défaut, EC2 limite les e-mails envoyés sur le port 25. Les e-mails d'Odoo envoyés ainsi expirent ou disparaissent. Envoyez-les plutôt par un service SMTP sur le port 587. Votre fournisseur de messagerie actuel convient. Amazon SES aussi :

1. Dans la console SES, vérifiez votre domaine. SES vous donne des enregistrements DNS à ajouter.
2. Allez dans SMTP settings > Create SMTP credentials. L'utilisateur et le mot de passe SMTP ne sont pas vos clés AWS, et ils ne fonctionnent que dans une seule région.
3. Les nouveaux comptes SES ne peuvent écrire qu'aux adresses que vous avez vérifiées, jusqu'à 200 e-mails par jour. Demandez l'accès production depuis l'Account dashboard de SES. AWS répond en 4 jours environ.
4. Dans Odoo, activez le mode développeur. Allez dans Settings > Technical > Outgoing Mail Servers. Mettez le serveur email-smtp.YOUR_REGION.amazonaws.com, le port 587, le chiffrement TLS (STARTTLS), et l'utilisateur et le mot de passe SMTP.

Ne demandez à AWS de lever la limite du port 25 que si vous devez vraiment envoyer sur le port 25.

Les pièges Odoo sur tout serveur, AWS compris

Websocket. Depuis Odoo 16, le chat et les mises à jour en direct passent par le port 8072. nginx doit y envoyer /websocket, avec les en-têtes d'upgrade.

Proxy mode. Odoo ne fait confiance aux en-têtes transmis que si proxy_mode = True et que la requête contient X-Forwarded-Host. Sans les deux, vos liens sortent en http://.

Gestionnaire de bases. Mettez list_db = False et un admin_passwd solide.

Workers. Mettez workers au-dessus de 0, réglé selon la mémoire. Odoo démarre alors le worker du chat sur gevent_port.

Dans odoo.conf :

proxy_mode = True
list_db = False
admin_passwd = a-long-random-string
workers = 4
gevent_port = 8072

Dans nginx, à côté de votre bloc location / :

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

location /websocket {
  proxy_pass http://127.0.0.1:8072;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Real-IP $remote_addr;
}

Le bloc map va dans la section http, en dehors de server.

Derrière un Application Load Balancer

Vous n'avez pas besoin d'un load balancer pour une seule instance. Si vous en utilisez un quand même :

• L'ALB gère seul les websockets. Gardez nginx derrière lui, pour que /websocket aille toujours vers 8072.
• L'ALB envoie X-Forwarded-Proto et X-Forwarded-For, mais pas X-Forwarded-Host. Sans lui, Odoo ignore les autres. nginx doit donc l'ajouter.
• L'ALB termine le HTTPS, donc nginx voit du HTTP simple. Transmettez le protocole de l'ALB, pas celui de nginx.

Dans les deux blocs location de nginx, utilisez :

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

Puis ouvrez le port 80 de odoo-web au seul security group de l'ALB, pas à tout internet.

Avant la mise en ligne

• L'instance est de type M ou R (pas T), avec un disque gp3
• 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
• Seuls les ports 80 et 443 sont ouverts, et vous vous connectez avec Session Manager
• Avec RDS : db_sslmode = require, et seul odoo-web peut joindre le port 5432
• Le certificat SSL se renouvelle tout seul
• Les PDF s'impriment (wkhtmltopdf fonctionne, sur Graviton aussi)
• Les e-mails de test arrivent, envoyés sur le port 587
• Les logs tournent, et l'e-mail de l'alarme disque est confirmé
• Le timer de sauvegarde a tourné, et les fichiers sont dans S3
• Une sauvegarde a été restaurée sur une autre instance, et les pièces jointes s'ouvrent

Gardez AWS, confiez-nous le travail Odoo

Vous pouvez garder Odoo dans votre compte AWS sans le gérer vous-même. Avec bring your own server, l'instance reste dans votre compte et dans la région de votre choix. Nous faisons tourner Odoo dessus : déploiements depuis Git, staging, sauvegardes, mises à jour et l'aide d'experts Odoo. Vous gardez l'instance en marche et assez grande. Notre logiciel se connecte depuis votre instance 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

Odoo peut-il tourner sur AWS ? Oui. Utilisez une instance EC2 avec un disque EBS, Postgres sur l'instance ou sur RDS, et des sauvegardes vers S3.

Puis-je utiliser Amazon RDS pour Odoo ? Oui. Créez pour Odoo un utilisateur de base de données qui peut créer des bases. RDS ne sauvegarde pas le filestore, sauvegardez-le aussi.

Quelle instance EC2 est la meilleure pour Odoo ? Une instance avec assez de mémoire pour vos workers et Postgres, et un CPU stable. Évitez les instances burstable en production.

Odoo peut-il tourner sur des instances Graviton (ARM) ? Oui. Vérifiez que wkhtmltopdf a un paquet arm64 pour votre système. C'est le cas pour Ubuntu 22.04 et Debian 12. Puis imprimez un PDF avant la mise en ligne. Pour notre bring your own server, choisissez plutôt Intel ou AMD, car il tourne uniquement sur x86.

De quels droits IAM le serveur Odoo a-t-il besoin pour les sauvegardes ? Seulement s3:PutObject sur votre bucket de sauvegarde. Les restaurations utilisent un rôle à part, sur une autre instance, avec s3:ListBucket et s3:GetObject.

Dois-je ouvrir le port 22 ? Non. Session Manager vous donne un shell via l'agent SSM, sans aucun port entrant.

Pourquoi Odoo n'envoie-t-il pas d'e-mails depuis EC2 ? EC2 limite le port 25 par défaut. Envoyez par SES ou par votre fournisseur de messagerie sur le port 587.