Odoo en AWS: cómo alojarlo bien

La respuesta corta

Para alojar Odoo en AWS, hazlo correr en una instancia EC2 con un disco EBS gp3. Pon Postgres en la misma instancia o en Amazon RDS. Abre solo los puertos 80 y 443, y entra con Systems Manager en lugar de SSH. Envía las copias de la base de datos y de los archivos a un bucket de S3 en el que la instancia puede escribir, pero no leer ni borrar. No uses instancias burstable en producción, y prueba una restauración antes de salir en vivo.

Muchas empresas ya tienen una cuenta de AWS, así que Odoo también va allí. AWS tiene una región cerca de casi cualquiera. También tiene muchas formas de dejar Odoo un poco mal configurado. Esta guía te da los comandos exactos para cada paso en AWS.

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

Puedes ejecutar cada comando aws de abajo desde tu propio equipo con la AWS CLI, o desde AWS CloudShell en la consola. Cambia los IDs en mayúsculas por los tuyos.

Qué instancia EC2 elegir

Dos cosas importan más para Odoo:

• Memoria. El mínimo para empezar es 2 vCPU, 4 GB de memoria y un disco de 50 GB. Con eso corren Odoo y Postgres en una sola instancia para un equipo pequeño. Cada worker necesita su parte de memoria, y Postgres quiere la suya. Para más usuarios, importaciones grandes o RDS, nuestra guía sobre cuántos workers de Odoo necesitas muestra cómo calcularlo.
• CPU estable. Odoo trabaja todo el día mientras la gente lo usa.

Por qué no una instancia T

Las instancias T (por ejemplo t3 o t4g) son "burstable". Ganan créditos de CPU cuando están tranquilas y los gastan cuando están ocupadas. Las nuevas instancias T3, T3a y T4g arrancan en modo "unlimited". En ese modo la instancia nunca va más lenta, pero si su CPU media se queda por encima de una base fija durante 24 horas, AWS cobra el extra. Las propias cuentas de AWS dicen que una T3 a tope cuesta más que una M5 del mismo tamaño. Un Odoo que se usa todo el día suele vivir por encima de esa base.

Así que para producción, elige una familia de rendimiento fijo:

• Familia M (uso general), por ejemplo m7i.large o m7g.large. Una buena opción por defecto.
• Familia R (más memoria por CPU), por ejemplo r7i.large. Buena cuando Postgres corre en la misma instancia y la base de datos es grande.

Las instancias T están bien para una copia de prueba que usa poca gente.

Graviton (ARM) está bien, si los PDF se imprimen

Las instancias con una "g" en el nombre, como m7g, usan chips AWS Graviton (arm64). Odoo y Postgres funcionan bien en ellas. La única parte que hay que revisar es wkhtmltopdf, que Odoo usa para imprimir los PDF. Sus paquetes oficiales para arm64 existen para Ubuntu 22.04 (jammy) y Debian 12 (bookworm). Elige uno de esos, instala el paquete arm64 que corresponde, e imprime una factura antes de salir en vivo. Si tu sistema operativo no está en esa lista, usa una instancia Intel o AMD (por ejemplo m7i o m7a). Si quizá nos dejes el trabajo de Odoo más adelante, elige también Intel o AMD: nuestro software bring your own server solo funciona en servidores x86.

Disco: EBS gp3

Guarda todos los datos en EBS, no en discos instance store. El instance store se borra cuando la instancia se detiene.

Usa el tipo de volumen gp3. Da 3000 IOPS y 125 MiB/s estables a cualquier tamaño, y puedes subir los dos más tarde sin un disco más grande. Deja sitio para el filestore y tres días de copias locales.

Región

Elige la región con cuidado. Tus datos viven en la región que elijas. Pon la instancia, la base de datos y el bucket de copias en la misma región, salvo que quieras las copias en una segunda región a propósito.

Dónde va Postgres

Tienes dos buenas opciones:

• En la misma instancia EC2. Simple, y está bien para muchos equipos. Sigue la guía del VPS tal como está.
• En Amazon RDS for PostgreSQL. AWS se encarga del servidor de base de datos, los parches y la recuperación a un momento dado. Los pasos están abajo.

Prepara RDS para Odoo

RDS necesita un "DB subnet group": al menos dos subredes en dos Availability Zones distintas, en la misma VPC que tu instancia EC2. Busca tus subredes y luego crea el grupo:

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 de datos también necesita su propio security group. Créalo ahora con los comandos de la sección siguiente (odoo-db). Luego crea la base de datos:

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

Qué hacen estas opciones:

• --manage-master-user-password deja que RDS cree la contraseña de admin y la guarde en Secrets Manager. Nunca queda en el historial de tu shell.
• --no-publicly-accessible mantiene la base de datos fuera de internet.
• --backup-retention-period 14 guarda 14 días de copias de RDS. Desde la CLI, el valor por defecto es solo 1 día.
• --deletion-protection impide que alguien borre la base de datos por error.
• Añade --multi-az si quieres una copia en espera en una segunda zona.
• Añade --engine-version para elegir una versión de Postgres. aws rds describe-db-engine-versions --engine postgres las muestra.

Crea el usuario de base de datos odoo

Odoo necesita su propio usuario que pueda crear bases de datos. No uses el usuario admin de RDS en el día a día.

Obtén la contraseña de admin y la dirección de la base de datos:

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

En la instancia de Odoo, conéctate con psql y crea el usuario:

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

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

El usuario admin de RDS no es un superusuario completo de Postgres, pero puede crear roles como este.

Apunta Odoo a RDS

En odoo.conf:

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

Desde Postgres 15, RDS activa rds.force_ssl por defecto. Rechaza las conexiones sin SSL. db_sslmode = require hace que Odoo lo use siempre.

Usa la misma versión del cliente de Postgres

pg_dump no hace copia de un servidor con una versión mayor más nueva que la suya. Si RDS corre Postgres 17, la instancia de Odoo necesita el cliente de la versión 17. Instálalo desde el repositorio 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

Las copias de RDS no cubren el filestore

RDS hace copia de la base de datos y puede restaurarla a cualquier segundo dentro del periodo de retención. No hace copia del filestore. Los adjuntos y las imágenes viven en el disco de EC2, en /var/lib/odoo/filestore. Sigues necesitando la copia en S3 de abajo, para que la base de datos y los archivos se guarden juntos.

Red y security groups

Security groups

Crea un grupo para la instancia de Odoo y otro para la base de datos:

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

No hay regla para el puerto 22. Entrarás con Systems Manager.

Si usas RDS, deja que solo la instancia de Odoo llegue a Postgres. La regla apunta al grupo odoo-web, no a una dirección 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

Los puertos propios de Odoo (8069 y 8072) siguen cerrados. Solo nginx, en la instancia, habla con ellos.

Un rol de IAM para la instancia

La instancia necesita una identidad en AWS. Le permite usar Systems Manager, enviar métricas de disco y, más tarde, escribir las copias. Guarda esto como ec2-trust.json:

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

Luego crea el rol y su 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

Una instancia EC2 no recibe un rol directamente. Recibe un "instance profile" que contiene el rol. Si creas el rol en la consola de IAM, la consola crea el profile por ti, con el mismo nombre.

Lanza la instancia

En la consola de EC2, ve a Instances > Launch instances y configura:

• AMI: Ubuntu Server 22.04 LTS o Debian 12 (mira la nota sobre Graviton más arriba)
• Instance type: por ejemplo m7i.large o m7g.large
• Key pair: no hace falta, porque no usarás SSH
• Network settings: tu VPC, una subred pública y el grupo existente odoo-web
• Storage: gp3, con tamaño para el filestore más las copias
• Advanced details > IAM instance profile: odoo-server

Si la instancia ya está corriendo, conecta el profile con:

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

Una dirección fija

Dale a la instancia una Elastic IP, para que su dirección no cambie cuando se detiene y arranca:

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

Apunta el registro DNS de tu dominio a esa dirección antes de pedir un certificado a Let's Encrypt.

Entra con Session Manager, no con SSH

AWS Systems Manager Session Manager te da una shell sin puerto abierto y sin clave SSH. Las AMI de Ubuntu Server traen el SSM Agent. La política AmazonSSMManagedInstanceCore del rol hace el resto. La instancia solo necesita HTTPS de salida, que los security groups permiten por defecto.

Para conectarte, abre la instancia en la consola de EC2 y elige Connect > Session Manager. O, desde tu equipo, instala el plugin de Session Manager para la AWS CLI y ejecuta:

aws ssm start-session --target INSTANCE_ID

Entras como ssm-user, que puede usar sudo.

Copias de seguridad en S3

Crea el bucket

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

En us-east-1, quita la línea --create-bucket-configuration. Los nombres de bucket se comparten entre todos los clientes de AWS, así que añade algo único al tuyo.

Bloquea el acceso público. Los buckets nuevos ya lo bloquean, y esto lo deja explícito:

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

Activa el versionado. Si un archivo de copia se sobrescribe o se borra, la copia anterior se queda como una versión vieja:

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

Borra las copias viejas de forma programada

Guarda esto como 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

Las copias de más de 30 días se eliminan. Con el versionado activo, "eliminada" primero significa "oculta". La copia oculta se queda 30 días más y luego se va para siempre. La última línea limpia las subidas que se cortaron a medias. Este comando sustituye cualquier regla de ciclo de vida que tuviera el bucket.

Deja que la instancia escriba, y solo escriba

Esta es la política del rol. Permite una sola acción, s3:PutObject, en un solo bucket. Guárdala como 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 también cubre los archivos grandes, que la CLI envía por partes. La instancia no puede listar, leer ni borrar nada del bucket. Si alguien entra en el servidor, no puede borrar tus copias. Con el versionado, incluso una sobrescritura deja la copia anterior en su sitio.

Si tus normas piden más, S3 Object Lock puede bloquear los borrados durante un número fijo de días, incluso para un admin. Una vez activado en un bucket, no se puede desactivar. Pruébalo antes en un bucket de sobra.

Instala la AWS CLI en la instancia

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

En Graviton, usa awscli-exe-linux-aarch64.zip. La CLI toma sola las credenciales del rol. Nunca guardas una access key en el servidor.

El script de copia

Primero crea la carpeta local:

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

Guarda esto como /usr/local/bin/odoo-backup.sh y ejecuta sudo chmod 755 sobre él:

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

Con RDS, pg_dump debe conectarse por la red. Cambia la línea de pg_dump por:

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

Luego dale al usuario odoo su contraseña en un archivo .pgpass, en su carpeta personal:

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

El * hace que la misma línea sirva para todas las bases de datos, también la de la prueba de restauración.

Ejecútalo cada noche

Crea /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

Y /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

Actívalo, luego ejecútalo una vez a mano y revisa el resultado:

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

Desde tu propio equipo, comprueba que los archivos llegaron:

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

Prueba una restauración

La instancia de producción no puede leer el bucket. Es a propósito. Así que la prueba de restauración se hace en una segunda instancia con su propio rol de solo lectura. Instala Odoo en ella con la guía del VPS y luego guarda esto como 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/*"
    }
  ]
}

Crea el rol igual que antes, con el mismo 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

En la instancia de prueba, como usuario odoo, descarga la copia de una noche y restáurala:

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 copia de prueba usa RDS, añade -h YOUR_RDS_ENDPOINT -U odoo a createdb y a pg_restore.

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.

Luego entra en yourdb_restored y abre algunos adjuntos. Nuestra guía sobre cómo saber si una copia de Odoo se restaurará cubre la prueba completa.

Recibe una alerta antes de que el disco se llene

Los logs, el filestore y las copias locales crecen. AWS no ve lo lleno que está tu disco si no le envías ese dato. El agente de CloudWatch lo hace.

Instálalo en la instancia (en Graviton, usa arm64 en la dirección):

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

Guarda esto como /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
      }
    }
  }
}

Arranca el agente con él:

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 métrica aparece en CloudWatch como disk_used_percent, en el namespace CWAgent. Una alarma solo salta si nombra exactamente las mismas dimensiones. Así que primero lístalas, desde tu equipo:

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

Crea un topic de correo, y confirma el correo que te envía AWS:

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

Luego crea la alarma. Copia las dimensiones de la salida de list-metrics. En Ubuntu, suelen ser estas:

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 también te avisa si el agente deja de enviar datos.

Correo saliente

Por defecto, EC2 limita el correo enviado por el puerto 25. El correo de Odoo enviado así dará timeout o se perderá. Envía a través de un servicio SMTP en el puerto 587. Tu proveedor de correo actual sirve. Amazon SES también:

1. En la consola de SES, verifica tu dominio. SES te da registros DNS para añadir.
2. Ve a SMTP settings > Create SMTP credentials. El usuario y la contraseña SMTP no son tus claves de AWS, y solo funcionan en una región.
3. Las cuentas nuevas de SES solo pueden enviar a direcciones que has verificado, hasta 200 correos al día. Pide acceso de producción desde el Account dashboard de SES. AWS responde en unos 4 días.
4. En Odoo, activa el modo desarrollador. Ve a Settings > Technical > Outgoing Mail Servers. Pon el servidor email-smtp.YOUR_REGION.amazonaws.com, el puerto 587, el cifrado TLS (STARTTLS), y el usuario y la contraseña SMTP.

Pide a AWS que quite el límite del puerto 25 solo si tienes que enviar por el puerto 25.

Trampas de Odoo en cualquier servidor, AWS incluido

Websocket. Desde Odoo 16, el chat y las actualizaciones en vivo usan el puerto 8072. nginx debe enviar /websocket allí, con las cabeceras de upgrade.

Proxy mode. Odoo solo confía en las cabeceras reenviadas cuando proxy_mode = True y la petición trae X-Forwarded-Host. Sin las dos cosas, tus enlaces salen con http://.

Gestor de bases de datos. Pon list_db = False y un admin_passwd fuerte.

Workers. Pon workers por encima de 0, ajustado a la memoria. Así Odoo arranca el worker del chat en gevent_port.

En odoo.conf:

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

En nginx, junto a tu bloque 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;
}

El bloque map va en la sección http, fuera de server.

Detrás de un Application Load Balancer

No necesitas un balanceador de carga para una sola instancia. Si usas uno de todos modos:

• El ALB gestiona los websockets por su cuenta. Deja nginx detrás de él, para que /websocket siga yendo al 8072.
• El ALB envía X-Forwarded-Proto y X-Forwarded-For, pero no X-Forwarded-Host. Sin ella, Odoo ignora las otras. Así que nginx debe añadirla.
• El ALB termina el HTTPS, así que nginx ve HTTP plano. Pasa el protocolo del ALB, no el de nginx.

En los dos bloques location de nginx, usa:

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

Luego abre el puerto 80 de odoo-web solo al security group del ALB, no a todo internet.

Antes de salir en vivo

• La instancia es de tipo M o R (no T), con un disco gp3
• Odoo corre con workers por encima de 0, ajustado a la memoria del servidor
• /websocket va al puerto 8072, y el chat funciona
• proxy_mode = True, y los enlaces de los correos empiezan por https://
• list_db = False y un admin_passwd fuerte
• Solo están abiertos los puertos 80 y 443, y entras con Session Manager
• Con RDS: db_sslmode = require, y solo odoo-web puede llegar al puerto 5432
• El certificado SSL se renueva solo
• Los PDF se imprimen (wkhtmltopdf funciona, también en Graviton)
• Los correos de prueba llegan, enviados por el puerto 587
• Los logs rotan, y el correo de la alarma de disco está confirmado
• El timer de la copia se ejecutó, y los archivos están en S3
• Una copia se ha restaurado en otra instancia, y los adjuntos se abren

Quédate con AWS, déjanos el trabajo de Odoo

Puedes mantener Odoo en tu cuenta de AWS y aun así no gestionarlo tú mismo. Con bring your own server, la instancia sigue en tu cuenta y en la región que elijas. Nosotros hacemos funcionar Odoo en ella: despliegues desde Git, staging, copias de seguridad, actualizaciones y ayuda de expertos en Odoo. Tú mantienes la instancia en marcha y con el tamaño suficiente. Nuestro software se conecta desde tu instancia 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

¿Puede Odoo correr en AWS? Sí. Usa una instancia EC2 con un disco EBS, Postgres en la instancia o en RDS, y copias de seguridad en S3.

¿Puedo usar Amazon RDS para Odoo? Sí. Crea para Odoo un usuario de base de datos que pueda crear bases. RDS no hace copia del filestore, así que cópialo también.

¿Qué instancia EC2 es la mejor para Odoo? Una con suficiente memoria para tus workers y Postgres, y una CPU estable. Evita las instancias burstable en producción.

¿Puede Odoo correr en instancias Graviton (ARM)? Sí. Comprueba que wkhtmltopdf tiene un paquete arm64 para tu sistema operativo. Lo tiene para Ubuntu 22.04 y Debian 12. Luego imprime un PDF antes de salir en vivo. Para nuestro bring your own server, elige Intel o AMD, ya que solo funciona en x86.

¿Qué permisos de IAM necesita el servidor de Odoo para las copias? Solo s3:PutObject en tu bucket de copias. Las restauraciones usan otro rol, en otra instancia, con s3:ListBucket y s3:GetObject.

¿Tengo que abrir el puerto 22? No. Session Manager te da una shell a través del SSM Agent, sin ningún puerto de entrada.

¿Por qué Odoo no envía correo desde EC2? EC2 limita el puerto 25 por defecto. Envía a través de SES o de tu proveedor de correo en el puerto 587.