EmDash CMS – Referencia de despliegue self-hosted con Node

Ejecuta EmDash en tu propia infraestructura con un camino arquitectónico progresivo de SQLite a PostgreSQL y almacenamiento de objetos.

Cuándo el self-hosting es la opción adecuada

Elige self-hosting cuando tus restricciones sean operativas, legales o arquitectónicas:

  • requisitos estrictos de residencia de datos
  • ya ejecutas servicios de plataforma compartidos internamente
  • necesitas control total sobre tiempo de ejecución, modelo de proceso y rutas de red
  • quieres evitar acoplamiento a la nube gestionada en etapas tempranas

El self-hosting no es automáticamente más barato. Suele ser más controlable.

Modelo de progresión recomendado

No empieces con la máxima complejidad. Despliega por fases:

  1. Node.js + SQLite + almacenamiento de archivos local
  2. PostgreSQL para seguridad multi-instancia y mayor durabilidad
  3. Almacenamiento de objetos compatible con S3 para portabilidad de medios
  4. Supervisión de procesos y endurecimiento de observabilidad

Esta secuencia minimiza el choque de migración manteniendo un camino de producción limpio.

Arquitectura base (fase 1)

Para producción de un solo nodo o lanzamiento temprano:

  • tiempo de ejecución de la app: adaptador Node (standalone)
  • base de datos: archivo SQLite en disco persistente
  • medios: directorio de subidas local
  • proxy inverso: Nginx o Caddy

Es suficiente para cargas editoriales bajas a moderadas con una instancia de tiempo de ejecución.

# Build y ejecución en producción
npm install
npm run build
npm run start

Criterios de mejora fase 2 (pasar a PostgreSQL)

Mejora la base de datos cuando aparezca cualquiera de estos casos:

  • contención de escritura concurrente frecuente
  • objetivos de recuperación de copias de seguridad que superan la estrategia de copiar archivos
  • necesitas un despliegue multi-instancia más seguro

Usa PostgreSQL antes de escalar horizontalmente la aplicación. Escalar nodos de app sobre SQLite crea riesgo operativo rápidamente.

Estrategia de almacenamiento: archivos locales vs. objeto

Archivos locales (empieza aquí)

Bueno para entornos de una instancia con crecimiento de almacenamiento predecible.

Almacenamiento de objetos compatible con S3 (escala)

Úsalo cuando:

  • varias instancias de app necesitan acceso compartido a medios
  • copia de seguridad y recuperación ante desastres deben estandarizarse
  • la estrategia de CDN y caché en el borde depende de URLs de objeto estables

MinIO puede usarse en infraestructura privada para comportamiento compatible con S3.

Proceso de tiempo de ejecución y proxy base

Gestión de procesos

Una de:

  • systemd para control de servicio nativo en Linux
  • pm2 para equipos que quieren métricas de proceso y reinicios rápidos

Proxy inverso

Termina TLS en el proxy y reenvía a la app Node:

  • preserva cabeceras Host y X-Forwarded-*
  • configura ruta de comprobación de salud
  • establece límites de tamaño de cuerpo alineados con la política de subida

Política de copia de seguridad y recuperación

Trata la política de backup como bloqueante para el lanzamiento, no como tarea posterior.

Línea base mínima:

  • instantáneas de base de datos según calendario
  • copias de seguridad o replicación del almacenamiento de medios
  • al menos un ensayo de restauración antes del lanzamiento público

Una copia de seguridad que nunca se ha restaurado en pruebas es un rumor, no un control.

Lista de comprobación de preparación operativa

Antes del corte a producción, confirma:

  • el reinicio en frío funciona sin ediciones manuales
  • los logs de aplicación están centralizados y son buscables
  • la alerta de 5xx está activa
  • el uso de disco y el crecimiento del almacenamiento están monitorizados
  • el proceso de rotación de secretos está documentado

Notas de migración desde un entorno orientado a Cloudflare

Si el proyecto empezó con supuestos de Cloudflare:

  • elimina enlaces solo de nube de la configuración de tiempo de ejecución
  • sustituye adaptadores D1/R2 por adaptadores de base de datos y almacenamiento compatibles con Node
  • revalida la autenticación y las URLs de callback detrás del proxy inverso

El riesgo de migración está sobre todo en supuestos del entorno, no en el código a nivel de página.

Marco de decisión para equipos

Regla:

  • si necesitas velocidad y operaciones mínimas, prefiere la ruta de nube gestionada
  • si necesitas control e integración con infra existente, prefiere self-hosting

Elige una ruta por defecto por entorno. Los modelos híbridos son posibles pero aumentan la carga cognitiva y el soporte.