Desplegar Strapi en un VPS: la guía completa

Strapi Cloud o autoalojamiento: lo que pierde, lo que gana

Ventajas de autoalojar Strapi en un VPS

• Propiedad de los datos — su base PostgreSQL y sus archivos subidos permanecen en su VPS, bajo su control exclusivo
• Ningún cupo de plan — el número de entradas, de tipos de contenido y de cuentas de administrador ya no lo fija una suscripción, sino los recursos de su VPS
• Plugins de la comunidad — cualquier plugin npm se instala libremente, sin validación ni lista blanca de la plataforma
• API en su dominio — REST y GraphQL expuestos en cms.mondomaine.com, sin intermediario ni límite de tasa impuesto
• Pila unificada — Strapi y un frontend Nuxt o Next.js conviven en el mismo VPS, detrás de un único reverse proxy
• Localización de los datos — esencial para el cumplimiento del RGPD y los requisitos contractuales de sus clientes
• Coste previsible — el VPS tiene una tarifa fija mensual, independiente del volumen de contenido o del tráfico de la API
• Control de las migraciones — usted elige cuándo y cómo aplicar las actualizaciones de Strapi

Requisitos previos: hardware, software y dominio

Preparar el proyecto antes de tocar el servidor

1. 01

   Generar el proyecto Strapi

   En su equipo, genere el proyecto con el comando oficial npx create-strapi-app@latest mon-cms --dbclient=postgres. Elija TypeScript si su equipo lo domina. Inicialice el repositorio Git, súbalo a su forja y luego clónelo en el VPS en /srv/mon-cms. Todo lo que sigue se prepara en ese repositorio y no en el servidor: el VPS solo debe recibir código ya versionado.

2. 02

   Conectar la configuración de base de datos a PostgreSQL

   En config/database.js — o config/database.ts en TypeScript —, la función exportada recibe env y devuelve un objeto connection. Declare client: 'postgres' y, a continuación, seis claves leídas desde el entorno en el subobjeto connection: host: env('DATABASE_HOST', '127.0.0.1'), port: env.int('DATABASE_PORT', 5432), database: env('DATABASE_NAME', 'strapi'), user: env('DATABASE_USERNAME', 'strapi'), password: env('DATABASE_PASSWORD', '') y ssl: env.bool('DATABASE_SSL', false). El segundo argumento de env() no es más que un valor de reserva para el desarrollo: ningún valor real debe figurar en este archivo, que acaba en Git.

3. 03

   Generar los cinco secretos de producción

   Strapi se niega a arrancar en producción sin APP_KEYS, API_TOKEN_SALT, ADMIN_JWT_SECRET, JWT_SECRET y TRANSFER_TOKEN_SALT. Genere cada uno con openssl rand -base64 32; APP_KEYS espera varias, separadas por comas, así que produzca al menos dos. Escríbalos en /srv/mon-cms/.env en el VPS — nunca en Git — junto con DATABASE_HOST, DATABASE_NAME, DATABASE_USERNAME, DATABASE_PASSWORD, NODE_ENV=production y URL=https://cms.mondomaine.com. Una clave que falte se traduce en un rechazo de arranque, no en una advertencia.

4. 04

   Escribir el Dockerfile multietapa

   Dos etapas bastan para mantener ligera la imagen de producción. La etapa builder parte de node:20-alpine, fija WORKDIR /app, copia package*.json, lanza npm ci, copia el resto del código y luego compila el admin con NODE_ENV=production npm run build. La etapa runner parte de la misma imagen base y solo copia de builder tres cosas: la carpeta de build, node_modules y package.json. Termine con EXPOSE 1337 y un CMD que llame a npm run start — es el script de arranque que Strapi instala, no intente lanzar un archivo de servidor a mano. Si el build muere por OOM, ponga NODE_OPTIONS=--max-old-space-size=4096 antes de npm run build.

Desplegar la pila en el VPS

1. 05

   Describir los servicios en docker-compose.yml

   El archivo declara dos servicios y un volumen con nombre. El servicio postgres utiliza la imagen postgres:16-alpine, recibe POSTGRES_DB, POSTGRES_USER y POSTGRES_PASSWORD en su bloque environment, monta el volumen pgdata en /var/lib/postgresql/data y pasa a restart: unless-stopped. El servicio strapi se construye desde el Dockerfile local con build: ., lee sus variables mediante env_file: .env, declara depends_on: postgres, monta ./public/uploads en /app/public/uploads y publica su puerto con ports: 127.0.0.1:1337:1337. Esta vinculación al bucle local es el punto importante: Nginx se convierte en el único punto de entrada público, el puerto 1337 nunca se expone al exterior. Un servicio redis sigue siendo opcional, para la caché de sesiones o las colas de procesamiento.

2. 06

   Construir la imagen y arrancar la pila

   Lance docker compose build y luego docker compose up -d. Siga el arranque con docker compose logs -f strapi. Strapi aplica sus migraciones de esquema en el primer arranque en cuanto NODE_ENV=production está puesto. Cuente de dos a cinco minutos: la construcción del admin React es con diferencia la etapa más lenta. Espere la línea Strapi started successfully antes de continuar.

3. 07

   Poner Nginx como reverse proxy

   Cree el vhost /etc/nginx/sites-available/cms.mondomaine.com. Escucha en listen 80 sobre server_name cms.mondomaine.com, lleva un client_max_body_size 50M — imprescindible para las subidas de medios — y un único bloque location / que hace proxy_pass http://127.0.0.1:1337. Añádale las cuatro cabeceras que Strapi espera detrás de un proxy: Host, X-Real-IP, X-Forwarded-For y X-Forwarded-Proto, cada una puesta por una directiva proxy_set_header. Active el vhost con un enlace simbólico hacia sites-enabled, y luego valide y recargue con nginx -t && systemctl reload nginx.

4. 08

   Activar HTTPS y fijar la variable URL

   Obtenga el certificado con certbot --nginx -d cms.mondomaine.com: Certbot reescribe el vhost para redirigir HTTP hacia HTTPS. Compruebe después que URL=https://cms.mondomaine.com figura correctamente en el .env, sin barra final. Es esta variable la que Strapi utiliza para construir los enlaces de los medios y las redirecciones del admin; sin ella, los archivos subidos salen con direcciones falsas y el panel de administración se comporta mal detrás del proxy. Reinicie el contenedor tras cualquier modificación del .env: las variables se leen al arrancar.

5. 09

   Comprobar que la instancia responde de verdad

   Abra https://cms.mondomaine.com/admin y cree la primera cuenta de administrador — Strapi la pide en el primer acceso y no volverá a pedirla. Controle después tres puntos: docker compose ps muestra los dos contenedores en estado running, la API pública responde en /api, y el envío de un archivo de prueba desde la mediateca funciona. Un 502 Bad Gateway en esta fase indica casi siempre un contenedor strapi detenido o todavía en construcción: relea docker compose logs strapi antes de tocar Nginx.

Sacar los medios del disco: el provider S3

Automatizar la copia de seguridad de la base

1. 10

   Crear la carpeta de destino

   En el VPS, mkdir -p /srv/backups/strapi. Mantenga esta carpeta fuera del repositorio Git y fuera de cualquier ruta montada en un contenedor: un volcado nunca debe acabar en una imagen ni en una release.

2. 11

   Localizar el nombre real del contenedor PostgreSQL

   docker compose ps da el nombre exacto, de la forma mon-cms-postgres-1. Deriva del nombre de la carpeta del proyecto: no lo copie de una guía, léalo en su máquina. Un script de copia de seguridad que apunta a un contenedor inexistente falla en silencio una vez colocado en el cron.

3. 12

   Escribir el comando de volcado

   Basta con una sola línea: docker exec mon-cms-postgres-1 pg_dump -U strapi strapi | gzip > /srv/backups/strapi/strapi-$(date +%Y%m%d).sql.gz. El pg_dump se ejecuta en el contenedor; la compresión y la escritura se hacen en el host. Láncelo una primera vez a mano y compruebe el tamaño del archivo producido: un volcado de unos pocos bytes indica un error de autenticación tragado por la tubería.

4. 13

   Purgar los volcados demasiado antiguos

   Añada a continuación find /srv/backups/strapi -name '*.sql.gz' -mtime +7 -delete. Sin esta línea, el disco se llena en unas semanas: es la avería más banal de una copia de seguridad diaria — la base cae porque la copia ha saturado el volumen.

5. 14

   Planificar y luego sacar los volcados del servidor

   Ponga los dos comandos en un script /etc/cron.daily/strapi-backup, con #!/bin/bash en la primera línea y un chmod +x para hacerlo ejecutable. Añádale un rsync hacia un almacenamiento externo, o un envío al mismo bucket S3 que los medios. Una copia de seguridad que se queda en la máquina que respalda no protege de nada; pruebe una restauración completa al menos una vez antes de depender de ella.

Actualizar Strapi sin romper las migraciones

Solución de problemas: los errores más frecuentes

Strapi y un frontend Nuxt o Next.js en el mismo VPS