Cómo autoalojar Ghost en 2026: MySQL, newsletters y copias de seguridad del contenido

Un despliegue de Ghost fallido no siempre se cae. Puede mostrar una página de inicio de sesión mientras el valor de url es HTTP o se ha sustituido el volumen de contenido. En su lugar, empieza con una comprobación de extremo a extremo: completa la configuración del propietario, publica una entrada con una imagen, suscribe a un miembro y envía una newsletter de prueba mediante el correo configurado.

Esta comprobación coincide con la finalidad catalogada de Ghost: una plataforma de publicación con membresías y newsletters. También revela antes que una comprobación de uptime las dependencias que faltan, las suposiciones incorrectas sobre el proxy y los datos efímeros.

Delimita el entorno de ejecución de Ghost

Dibuja tres límites alrededor de Ghost: la entrada al puerto 2368, el estado persistente y los requisitos auxiliares. El contenedor se puede sustituir, pero los otros dos necesitan responsables explícitos. El contrato de red de Ghost requiere MySQL 8, SMTP y, opcionalmente, object storage para sitios con muchos archivos multimedia. Mantén los endpoints privados en DNS interno, permite únicamente las llamadas salientes necesarias y proporciona a Ghost una credencial de servicio con permisos limitados.

El diagrama está completo cuando un cliente limpio puede completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado. Registra los tiempos y los datos de recursos de las consultas de MySQL, el almacenamiento de imágenes, el renderizado del tema, el número de miembros y los límites del proveedor de envíos masivos. Si la transacción falla, el primer límite que no se comporte como está documentado indica si debes investigar el routing, la capacidad local o un servicio auxiliar.

Demuestra que Ghost sobrevive a una sustitución

Una imagen de contenedor se puede descargar de nuevo; la base de datos de MySQL, junto con los temas, las imágenes y los archivos de contenido, no. Monta /var/lib/ghost/content antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Inspecciona el mount efectivo en lugar de confiar en el nombre de un archivo de Compose y comprueba que el usuario de runtime puede escribir donde Ghost lo necesita.

Elige una política de retención y un destino externo al host, y después ensaya la recuperación sin tocar producción. El ejercicio solo se supera cuando vuelven las entradas, los miembros, las newsletters, los temas y las imágenes, y un miembro de prueba puede abrir la publicación restaurada. Para el estado respaldado por una base de datos, combina snapshots de almacenamiento con exportaciones coherentes con la aplicación, tal como se describe en recuperación point-in-time frente a snapshots.

Credenciales, roles y superficies expuestas

El riesgo de seguridad específico de la aplicación consiste en usar SQLite en una topología de producción no compatible o filtrar las credenciales de correo. La respuesta operativa es proteger Ghost Admin, mantener las credenciales del correo y de la base de datos en el servidor y establecer la URL HTTPS definitiva antes de publicar. Completa el bootstrap mediante una ruta restringida y elimina inmediatamente después el acceso temporal de configuración.

url es configuración, no un secreto; mantén su valor explícito mientras proteges las credenciales independientes que utiliza Ghost. Concede al proceso de Ghost únicamente los mounts y las rutas de dependencias documentados; evita el acceso a la raíz del host y al socket de Docker. Registra los errores de autenticación y de configuración, pero oculta los tokens, las cadenas de conexión y el contenido de los usuarios.

Demuestra el despliegue de Ghost de extremo a extremo

El registro de una release de Ghost necesita datos concretos, no un “parece correcto”. Guarda el digest de imagen seleccionado, la suma de comprobación de la configuración, el hostname público y un resultado con marca de tiempo para: completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado. Usa datos de ejemplo que no sean de producción para que la comprobación pueda ejecutarse después de cada despliegue.

Demuestra por separado dos eventos del ciclo de vida. Una sustitución del contenedor debe conservar el funcionamiento normal; una recuperación limpia debe demostrar que vuelven las entradas, los miembros, las newsletters, los temas y las imágenes, y que un miembro de prueba puede abrir la publicación restaurada. Mientras se ejecutan las comprobaciones, mide las consultas de MySQL, el almacenamiento de imágenes, el renderizado del tema, el número de miembros y los límites del proveedor de envíos masivos, y conserva el resultado como el envelope esperado para esta versión.

Prueba también una condición denegada o no válida: deniega temporalmente a la identidad de prueba el acceso a MySQL 8, SMTP y al object storage opcional para sitios con muchos archivos multimedia. Ghost debe fallar de forma diagnosticable y no debe sobrescribir un estado correcto. Restablece la condición válida, vuelve a ejecutar el ejemplo y adjunta los logs relevantes con los datos confidenciales ocultos. Estos artefactos proporcionan evidencias concretas para una futura decisión de rollback.

Una base de Docker para Ghost

Mantén la invocación inicial de Ghost suficientemente reproducible como para revisarla en un pull request.

docker run -d \
  --name ghost \
  --restart unless-stopped \
  -p 127.0.0.1:2368:2368 \
  -v ghost-data:/var/lib/ghost/content \
  -e url=https://app.example.com \
  -e database__client=mysql \
  -e database__connection__host=mysql.internal \
  -e database__connection__user=ghost \
  -e database__connection__password=replace-with-a-strong-database-password \
  -e database__connection__database=ghost \
  ghost:latest

No dependas de latest cuando ya existan datos reales. Registra el digest funcional, el usuario del contenedor y la propiedad del mount. Sigue el log de la aplicación durante una prueba completa —completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado— y anota cualquier migración antes de poner la ruta detrás del tráfico de producción.

TLS es fácil; las URL generadas no

Establece url en el dominio HTTPS definitivo antes de publicar. Envía el hostname elegido al puerto 2368 del contenedor, reenvía el host original y el esquema HTTPS, y evita publicar un segundo origin directo.

Prueba Ghost desde un cliente externo limpio. Separa los fallos de ingress del límite conocido de la aplicación: el valor de url es HTTP o se ha sustituido el volumen de contenido. Un error de certificado, DNS o 502 pertenece al routing; una solicitud que llega a Ghost y falla después pertenece al estado de la aplicación, la capacidad o uno de sus requisitos auxiliares. La guía de TLS para dominios personalizados cubre el primer grupo.

Comprobaciones de capacidad y upgrades

Las pruebas de capacidad deben ejercitar las consultas de MySQL, el almacenamiento de imágenes, el renderizado del tema, el número de miembros y los límites del proveedor de envíos masivos, no repetir una solicitud a /. Ejecuta el escenario “completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado” con una concurrencia realista, y registra la latencia, la tasa de errores y el crecimiento del almacenamiento.

La planificación de upgrades debe tener en cuenta este riesgo: las migraciones de Ghost, las expectativas del runtime de Node y los temas personalizados deben probarse en un sitio clonado. Prueba la nueva release con datos representativos, repite después la transacción de aceptación y compara el resultado. Si el valor de url es HTTP o se ha sustituido el volumen de contenido, registra la transacción fallida e inspecciona el primer límite implicado en lugar de asumir que el ingress es el responsable.

Traslada a Dockup el trabajo de infraestructura repetible

El routing, los certificados, la sustitución de servicios y el almacenamiento asociado son objetivos razonables para la automatización. Dockup se encarga de ellos para Ghost y puede aprovisionar la base de datos gestionada relacionada o conectarse a servicios en el propio servidor del cliente.

Lo que no debe inventar es la política de confianza de Ghost. Después del despliegue, establece url en el dominio HTTPS definitivo antes de publicar, aplica este límite —protege Ghost Admin, mantén las credenciales del correo y de la base de datos en el servidor y establece la URL HTTPS definitiva antes de publicar— y verifica el resultado de este escenario: completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado. El resultado es una infraestructura de un clic con una prueba de aceptación específica de la aplicación.

Preguntas frecuentes

¿Qué necesita Ghost para un despliegue de producción?

Enruta el contenedor de Ghost en el puerto 2368 a través de un único origin HTTPS. El requisito de red auxiliar es MySQL 8, SMTP y, opcionalmente, object storage para sitios con muchos archivos multimedia. No consideres que Ghost está listo hasta que puedas completar la configuración del propietario, publicar una entrada con una imagen, suscribir a un miembro y enviar una newsletter de prueba mediante el correo configurado.

¿Qué datos de Ghost deben incluirse en una copia de seguridad?

Haz persistir /var/lib/ghost/content e incluye la base de datos de MySQL, además de los temas, las imágenes y los archivos de contenido, en el mismo manifiesto de recuperación. Una restauración limpia de Ghost solo se supera cuando vuelven las entradas, los miembros, las newsletters, los temas y las imágenes, y un miembro de prueba puede abrir la publicación restaurada.

¿Ghost necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origin público de Ghost y mantén el puerto 2368 en la ruta interna. Aplica correctamente el ajuste de Ghost: establece url en el dominio HTTPS definitivo antes de publicar. En Ghost, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origin.

¿Cómo debe probarse un upgrade de Ghost?

Restaura el estado actual de Ghost en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de Ghost, las expectativas del runtime de Node y los temas personalizados deben probarse en un sitio clonado. Conserva la imagen anterior de Ghost hasta comprender sus límites de migración de datos y rollback.