Cómo alojar Directus por tu cuenta en 2026: base de datos, cargas y URL pública

Trata Directus como un sistema pequeño, no como una imagen de Docker. El objetivo de cara al usuario para Directus es claro: una API REST y GraphQL, además de una interfaz de administración sobre tus datos; el despliegue solo es válido cuando puedes inicializar el administrador, crear una colección y un rol, escribir mediante REST, consultar mediante GraphQL y subir un archivo.

Esta distinción permite detectar el modo de fallo con el que se encuentran los operadores después de las pruebas locales: el cliente de base de datos es incorrecto o el almacenamiento de cargas no permite escribir. También hace que el plan de copias de seguridad y actualizaciones sea lo bastante específico como para probarlo.

Comprueba que Directus sobrevive a un reemplazo

Una imagen de contenedor se puede volver a descargar; la base de datos, las cargas, las extensiones, los flows y las instantáneas del esquema no. Monta /directus/database antes de la inicialización, escribe datos de muestra inocuos y reemplaza 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 del runtime puede escribir donde Directus 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 simulacro solo se supera cuando vuelven el esquema, los roles, los flows, los elementos, las extensiones y las cargas, y las comprobaciones de REST y GraphQL tienen éxito. Para el estado respaldado por la base de datos, combina las instantáneas del almacenamiento con exports coherentes con la aplicación, tal como se describe en recuperación a un punto en el tiempo frente a instantáneas.

La arquitectura de Directus en producción

Dibuja tres límites alrededor de Directus: la entrada al puerto 8055, el estado duradero y los requisitos de soporte. El contenedor se puede reemplazar, pero los otros dos elementos necesitan responsables explícitos. El contrato de red de Directus es Postgres, además de Redis y almacenamiento de objetos opcionales para despliegues escalados. Mantén los endpoints privados en DNS interno, permite únicamente las llamadas salientes necesarias y proporciona a Directus una credencial de servicio con permisos limitados.

El diagrama está completo cuando un cliente limpio puede inicializar el administrador, crear una colección y un rol, escribir mediante REST, consultar mediante GraphQL y subir un archivo. Captura datos de tiempos y recursos para el pool de conexiones de la base de datos, la concurrencia de solicitudes de la API, los workers de Flow, la generación de miniaturas y el almacenamiento de cargas. 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 de soporte.

Comprueba el despliegue de Directus de extremo a extremo

Crea un fixture de Directus pequeño y desechable, y consérvalo para cada release. El fixture debe probar el workflow real: inicializar el administrador, crear una colección y un rol, escribir mediante REST, consultar mediante GraphQL y subir un archivo. Registra el digest de la imagen, el hostname externo, la dirección de la dependencia y el resultado esperado para que otro operador pueda repetir la prueba más adelante sin tener que interpretar esta guía.

Ejecuta el fixture tres veces. Primero, utiliza el despliegue nuevo. Segundo, reemplaza el contenedor sin tocar el estado duradero. Tercero, restaura la copia de seguridad en un entorno vacío. La tercera ejecución solo se supera cuando vuelven el esquema, los roles, los flows, los elementos, las extensiones y las cargas, y las comprobaciones de REST y GraphQL tienen éxito. Durante cada ejecución, captura la latencia y el uso de recursos del pool de conexiones de la base de datos, la concurrencia de solicitudes de la API, los workers de Flow, la generación de miniaturas y el almacenamiento de cargas; esto se convierte en la línea base de las alertas, en lugar de un porcentaje de CPU arbitrario.

Por último, prueba deliberadamente la ruta negativa: deniega temporalmente al identity de prueba el acceso a Postgres, Redis y el almacenamiento de objetos opcionales para despliegues escalados. Confirma que Directus falla de forma visible sin corromper el estado, restaura la condición correcta y repite la transacción correcta. Un registro del release que contenga esos cuatro resultados ofrece pruebas más sólidas que las capturas de un dashboard o una respuesta puntual de curl.

Inicia Directus con valores predeterminados observables

Inicia Directus de forma que la ruta permanezca privada hasta completar la inicialización.

docker run -d \
  --name directus \
  --restart unless-stopped \
  -p 127.0.0.1:8055:8055 \
  -v directus-data:/directus/database \
  -v directus-uploads:/directus/uploads \
  -v directus-extensions:/directus/extensions \
  -e SECRET=replace-with-a-long-random-value \
  -e KEY=replace-with-a-second-long-random-value \
  -e ADMIN_EMAIL=admin@example.com \
  -e ADMIN_PASSWORD=replace-with-a-strong-bootstrap-password \
  -e DB_CLIENT=sqlite3 \
  -e DB_FILENAME=/directus/database/data.db \
  -e PUBLIC_URL=https://app.example.com \
  directus/directus:latest

Si el proceso entra en un bucle, compara el usuario esperado por la imagen con el propietario de cada ruta montada. Si permanece activo, prueba localmente el puerto 8055 y pasa directamente al workflow: inicializa el administrador, crea una colección y un rol, escribe mediante REST, consulta mediante GraphQL y sube un archivo. Fija la versión de la imagen solo después de superar esa comprobación de extremo a extremo y registra la configuración exacta junto al servicio.

Credenciales, roles y superficies expuestas

Cierra la ventana de inicialización en cuanto exista el primer administrador de confianza. El error concreto en Directus consiste en seguir usando la contraseña del administrador de inicialización después del primer login o rotar SECRET a ciegas; el límite más seguro es sustituir las credenciales de inicialización, usar roles con los mínimos privilegios y mantener SECRET estable porque protege las sesiones y los tokens de la aplicación.

Genera SECRET una sola vez, no lo guardes en Git y consérvalo junto al manifiesto de recuperación, porque cambiarlo puede invalidar el estado cifrado o firmado de la aplicación. La red privada debe transportar las credenciales de las dependencias, y los roles dentro de Directus deben conceder la acción útil más pequeña posible. Evita que los cuerpos de las solicitudes sensibles y las respuestas de los proveedores aparezcan en los logs habituales.

Haz que el origen público no deje lugar a dudas

Evita usar orígenes públicos temporales y permanentes para Directus. En su lugar, establece PUBLIC_URL como la dirección HTTPS canónica, apunta el nombre DNS elegido a la ruta de la plataforma y usa el proxy únicamente hacia el puerto 8055.

Ejecuta esta acción desde fuera del host: inicializa el administrador, crea una colección y un rol, escribe mediante REST, consulta mediante GraphQL y sube un archivo. Si la entrada falla, la guía de solución de problemas de 502 cubre los errores de puerto y listener. Si Directus recibe la solicitud, pero el cliente de base de datos es incorrecto o el almacenamiento de cargas no permite escribir, las pruebas ya apuntan más allá del proxy.

Simulacros de fallos para Directus

En Directus, monitoriza una transacción en lugar de un proceso: inicializa el administrador, crea una colección y un rol, escribe mediante REST, consulta mediante GraphQL y sube un archivo. Combina su latencia y tasa de errores con el pool de conexiones de la base de datos, la concurrencia de solicitudes de la API, los workers de Flow, la generación de miniaturas y el almacenamiento de cargas para que una alerta identifique el componente limitado.

El ensayo de actualización debe cubrir que las migraciones del esquema de Directus, las extensiones y la compatibilidad con el proveedor de base de datos deben comprobarse como una unidad. Restaura, migra y ejecuta la transacción antes de reemplazar producción. Si el cliente de base de datos es incorrecto o el almacenamiento de cargas no permite escribir, no borres los datos para que el arranque aparezca en verde; compara la versión, las variables, los mounts y la conectividad con las dependencias, en ese orden.

Qué debería automatizar Dockup para Directus

La capa de plataforma para Directus consta del puerto 8055, la entrada, TLS, la configuración del runtime, el almacenamiento y la conectividad con las dependencias. Dockup puede reproducir esos elementos para su propia infraestructura o para un servidor que conecte el cliente.

Después, el operador completa la capa de producto: establece PUBLIC_URL como la dirección HTTPS canónica; aplica esta regla de acceso — sustituye las credenciales de inicialización, usa roles con los mínimos privilegios y mantén SECRET estable porque protege las sesiones y los tokens de la aplicación—; y ejecuta «inicializar el administrador, crear una colección y un rol, escribir mediante REST, consultar mediante GraphQL y subir un archivo». Registrar esa prueba junto al despliegue evita confundir el aprovisionamiento automatizado con la disponibilidad de la aplicación.

Preguntas frecuentes

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

Enruta el contenedor de Directus en el puerto 8055 a través de un único origen HTTPS. El requisito de red de soporte es Postgres, además de Redis y almacenamiento de objetos opcionales para despliegues escalados. No des por listo Directus hasta que puedas inicializar el administrador, crear una colección y un rol, escribir mediante REST, consultar mediante GraphQL y subir un archivo.

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

Haz persistente /directus/database e incluye la base de datos, las cargas, las extensiones, los flows y las instantáneas del esquema en el mismo manifiesto de recuperación. Una restauración limpia de Directus solo se supera cuando vuelven el esquema, los roles, los flows, los elementos, las extensiones y las cargas, y las comprobaciones de REST y GraphQL tienen éxito.

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

Usa HTTPS para el origen público de Directus y mantén el puerto 8055 en la ruta interna. Aplica correctamente el ajuste de Directus: establece PUBLIC_URL como la dirección HTTPS canónica. En Directus, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de Directus?

Restaura el estado actual de Directus en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las migraciones del esquema de Directus, las extensiones y la compatibilidad con el proveedor de base de datos deben comprobarse como una unidad. Conserva la imagen anterior de Directus hasta comprender los límites de migración de datos y rollback.