Maintain your self-hosted DQE One Standalone server

This article is for whoever installed and runs your own DQE One Standalone server (Docker-based, self-hosted) — it covers updating, backing up, logs, storage and the handful of settings worth revisiting after the initial setup. If you're an end user of the app rather than the person running the server, see Maintain your data and processes in DQE One Standalone instead.

Updating to a new version

There's no separate upgrade script to run. Database migrations are applied automatically every time the application starts, so updating is just: pull the new image DQE provides, and restart your containers (docker compose up -d, or the equivalent for your deployment). This also covers the MCP integration endpoint — it runs inside the same application process, so there's nothing separate to update or restart for it.

Some older setup guides mention variables such as RUN_COLLECTSTATIC or a WAIT_HOSTS family of settings. Check with Support whether these still apply to your deployment before relying on them — they weren't found to do anything in the version this article was checked against.

Backing up and restoring your data

There's no built-in backup feature — treat this like any other PostgreSQL deployment. Back up the database with a standard pg_dump, for example:

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

Restore it the same way, with psql:

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

Schedule these dumps yourself on a regular basis (or back up the database's Docker volume directly) — nothing in the app does this for you.

Logs

The application's own log file rotates and cleans up after itself automatically (daily, keeping 7 days of history) — you generally don't need to manage this.

A process run's detailed execution log isn't kept as a standalone file either: once a run finishes normally, its content is stored encrypted in the database and the raw log file is removed. Users download it from within the app itself (Export Run Logs, see Monitor and manage a run in DQE One Standalone).

If your container's own console output grows large over time, check your Docker logging driver settings — ours caps it in our reference setup, but yours may be configured differently.

Keeping an eye on storage

The DB_MAX_CAPACITY environment variable (set in bytes) is the only built-in storage guard: once your database size approaches it, new file uploads start showing a warning, and an email is sent. This is only checked at upload time, not continuously, and the guard does nothing if the variable isn't set at all.

Monitor your actual PostgreSQL size and host disk usage yourself with standard tools, and raise DB_MAX_CAPACITY as your data grows — don't rely on it to warn you proactively.

Restarting and checking it's running

There's no built-in health-check endpoint and no restart policy configured by default — if the container stops, it stays stopped unless you've set your own restart policy (for example restart: unless-stopped in your compose file) or an external monitoring tool. A quick way to confirm the app is responding is to request its URL and expect a redirect to the login page.

Settings worth revisiting over time

• Your licence key (DQE_CLIENT_LICENCE) is checked on every login — renew it before it expires rather than after users start being blocked.
• DB_MAX_CAPACITY — raise it as your data grows (see above).

Never lose or let SECRET_ENCRYPTION_KEY be regenerated once it's set: if it's ever left unset, a new one is generated automatically the next time the server starts, and this permanently prevents decrypting everything that was already stored (Credentials, Webhook secrets, run logs) with the previous key. Keep a secure copy of it outside the container.

Limits

• Redis isn't just a cache here: restarting or clearing it loses in-progress or queued jobs, and the search index used by Index Records processes (rebuild it by re-running that process if this happens). Short-lived sign-in codes are also stored there, but losing those just means retrying a login step.
• The server doesn't handle HTTPS itself — keep it behind your own reverse proxy with a valid certificate, the same way it needed to be set up initially.