Mantener su servidor DQE One Standalone autoalojado

Este artículo es para quien instala y administra su propio servidor DQE One Standalone (basado en Docker, autoalojado) — cubre actualizaciones, copias de seguridad, logs, almacenamiento y los pocos ajustes que conviene revisar tras la configuración inicial. Si usted es un usuario final de la aplicación en lugar de quien administra el servidor, consulte en su lugar Maintain your data and processes in DQE One Standalone.

Actualizar a una nueva versión

No hay un script de actualización independiente que ejecutar. Las migraciones de base de datos se aplican automáticamente cada vez que la aplicación arranca, así que actualizar consiste simplemente en: obtener la nueva imagen proporcionada por DQE y reiniciar sus contenedores (docker compose up -d, o el equivalente de su despliegue). Esto también cubre el endpoint de integración MCP — se ejecuta dentro del mismo proceso de la aplicación, así que no hay nada independiente que actualizar o reiniciar para él.

Algunas guías de instalación antiguas mencionan variables como RUN_COLLECTSTATIC o una familia de ajustes WAIT_HOSTS. Compruebe con Soporte si todavía se aplican a su despliegue antes de confiar en ellas — no se encontró que tuvieran ningún efecto en la versión comprobada para este artículo.

Copiar y restaurar sus datos

No existe ninguna función de copia de seguridad integrada — trátelo como cualquier otro despliegue de PostgreSQL. Haga una copia de la base de datos con un pg_dump estándar, por ejemplo:

docker compose exec postgres pg_dump -U <DB_USER> -d <DB_NAME> > backup.sql

Restáurela de la misma forma, con psql:

docker compose exec -T postgres psql -U <DB_USER> -d <DB_NAME> < backup.sql

Programe usted mismo estas copias de forma regular (o haga una copia directa del volumen Docker de la base de datos) — nada en la aplicación lo hace por usted.

Logs

El propio archivo de log de la aplicación rota y se limpia automáticamente (rotación diaria, conservando 7 días de historial) — en general no necesita gestionarlo.

El log de ejecución detallado de un run tampoco se conserva como archivo independiente: una vez que un run termina con normalidad, su contenido se guarda cifrado en la base de datos y el archivo de log en bruto se elimina. Los usuarios lo descargan desde la propia aplicación (Export Run Logs, véase Monitor and manage a run in DQE One Standalone).

Si la salida de consola de su contenedor crece con el tiempo, compruebe la configuración de su driver de logs de Docker — el nuestro la limita en nuestra configuración de referencia, pero la suya puede estar configurada de otra forma.

Vigilar el almacenamiento

La variable de entorno DB_MAX_CAPACITY (en bytes) es la única protección de almacenamiento integrada: cuando el tamaño de su base de datos se acerca a ella, las nuevas subidas de archivos muestran un aviso y se envía un correo. Esto solo se comprueba en el momento de la subida, no de forma continua, y esta protección no hace nada si la variable no está definida en absoluto.

Vigile usted mismo el tamaño real de PostgreSQL y el uso de disco del host con herramientas estándar, y aumente DB_MAX_CAPACITY a medida que crecen sus datos — no confíe en ella para avisarle de forma proactiva.

Reiniciar y comprobar que funciona

No hay un endpoint de comprobación de salud integrado ni una política de reinicio configurada por defecto — si el contenedor se detiene, se queda detenido a menos que haya definido su propia política de reinicio (por ejemplo restart: unless-stopped en su archivo compose) o una herramienta de monitorización externa. Una forma rápida de confirmar que la aplicación responde es solicitar su URL y esperar una redirección a la página de inicio de sesión.

Ajustes que conviene revisar con el tiempo

• Su clave de licencia (DQE_CLIENT_LICENCE) se comprueba en cada inicio de sesión — renuévela antes de que caduque, no después de que los usuarios empiecen a quedar bloqueados.
• DB_MAX_CAPACITY — auméntela a medida que crecen sus datos (véase más arriba).

Nunca pierda ni deje que se regenere SECRET_ENCRYPTION_KEY una vez definida: si en algún momento queda sin definir, se genera automáticamente una nueva la próxima vez que arranque el servidor, lo que impide permanentemente descifrar todo lo que ya estaba almacenado (Credentials, secretos de Webhook, logs de run) con la clave anterior. Guarde una copia segura de ella fuera del contenedor.

Límites

• Redis no es solo una caché aquí: reiniciarlo o vaciarlo hace perder los jobs en curso o en cola, así como el índice de búsqueda usado por los procesos Index Records (reconstruible volviendo a ejecutar ese proceso si ocurre). También se almacenan allí códigos de inicio de sesión de corta duración, pero perderlos solo implica repetir un paso de inicio de sesión.
• El servidor no gestiona el HTTPS por sí mismo — manténgalo detrás de su propio reverse proxy con un certificado válido, de la misma forma en que fue necesario configurarlo inicialmente.