How to Self-Host Duplicati in 2026: Encrypted Backups, Mounts and Restore Tests

If you already tried to self-host Duplicati, the frustrating state is probably familiar: the UI appears, but the container sees an empty path because host sources were mounted elsewhere. Recreating the container rarely fixes a disagreement between URLs, state and dependencies.

This walkthrough uses one concrete completion criterion — back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path. Every configuration choice is evaluated against that criterion rather than against a green container badge.

Ports, processes and private services

A useful Duplicati diagram shows the public route, private port 8200, state boundary and every supporting requirement. Mark which arrows carry credentials and which are ordinary user traffic. The network contract for Duplicati is read-only source mounts plus reachable backup destination storage. Keep private endpoints on internal DNS, permit only required outbound calls and give Duplicati a scoped service credential.

Prove the diagram with one real action: back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path. The likely pressure comes from source file count, compression, encryption, destination latency and the overlap between scheduled jobs; monitor that path rather than treating all HTTP requests as equal.

Diagnose a healthy-looking Duplicati

Build dashboards around source file count, compression, encryption, destination latency and the overlap between scheduled jobs. A CPU graph without that workload context cannot explain why Duplicati is slow. Add a synthetic or scheduled check that tries to back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path using harmless test data.

Before upgrading, account for this application-specific hazard: Duplicati's configuration database and backup format changes should be tested without rewriting the only remote backup set. Restore a recent backup into an isolated deployment, run migrations there and compare behavior. If the container sees an empty path because host sources were mounted elsewhere, inspect the boundary involved — public origin, storage or dependency — before touching unrelated settings.

What must pass before real Duplicati data arrives

The release record for Duplicati needs facts, not “looks good.” Store the selected image digest, configuration checksum, public hostname and a timestamped result for: back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path. Use non-production sample data so the check can run after every deployment.

Prove two lifecycle events separately. A container replacement must preserve normal operation; a clean recovery must show that a fresh Duplicati instance can import the configuration and restore selected files with verified hashes. While the checks run, measure source file count, compression, encryption, destination latency and the overlap between scheduled jobs and retain the result as the expected envelope for this version.

Test a denied or invalid condition as well: temporarily deny the test identity access to read-only source mounts plus reachable backup destination storage. Duplicati should fail in a diagnosable way and should not overwrite healthy state. Return the valid condition, rerun the sample and attach the relevant redacted logs. Those artifacts give a future rollback decision concrete evidence.

Turn the local command into an inspectable service

The following command makes the container boundary visible without pretending to provision every external service.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Before opening ingress, inspect the resolved environment, mounts and listener. Add the reviewed connection settings for read-only source mounts plus reachable backup destination storage; use private names for private services. A successful launch ends when you can back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path, not when docker ps prints Up.

Make Duplicati recovery measurable

List the state before the first real record is created: the Duplicati configuration database and separately verified backup sets. Mount /config before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Confirm the mount by writing harmless data, replacing Duplicati and reading it back.

Snapshots are valuable for quick rollback, but an independent backup is needed when the host or volume disappears. Restore into an empty environment with the pinned image and verify that a fresh Duplicati instance can import the configuration and restore selected files with verified hashes. Use persistent volumes and snapshots to keep those two recovery mechanisms distinct.

TLS is easy; generated URLs are not

Expose one HTTPS hostname for Duplicati; keep raw port 8200 private. Keep the management UI private or strongly authenticated behind HTTPS. This prevents browsers and API clients from learning two competing addresses.

From a clean client, run the known-good transaction and inspect the first failing request. Use the custom-domain guide when DNS or TLS is wrong. Treat “the container sees an empty path because host sources were mounted elsewhere” as a separate application diagnosis once the route is proven.

Lock down Duplicati after bootstrap

Bootstrap credentials are temporary; the trust model is permanent. With Duplicati, watch for mounting backup sources read-write or losing the encryption passphrase, and mount sources read-only, keep the management UI private and store the backup passphrase outside the server.

Generate SETTINGS_ENCRYPTION_KEY once, keep it out of Git and preserve it with the recovery manifest because changing it can invalidate encrypted or signed application state. Run the image without unnecessary Linux capabilities and expose only the public application route. Keep administrator activity visible without recording secret values.

Use Dockup for the platform layer

For Duplicati, Dockup can create the route and TLS certificate, preserve mounts, deliver secrets and place read-only source mounts plus reachable backup destination storage on private networking while deploying to either Dockup or attached servers.

The release gate is still the concrete Duplicati transaction: back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path. Also verify the restore condition — a fresh Duplicati instance can import the configuration and restore selected files with verified hashes. Those two checks show whether the deployment works and whether it can be recovered.

Frequently asked questions

What does Duplicati need for a production deployment?

Route the Duplicati container on port 8200 through one HTTPS origin. The supporting network requirement is read-only source mounts plus reachable backup destination storage. Do not call Duplicati ready until you can back up a test directory to the chosen destination, delete a source file and restore it into a clean alternate path.

Which Duplicati data belongs in a backup?

Persist /config and include the Duplicati configuration database and separately verified backup sets in the same recovery manifest. A clean Duplicati restore passes only when a fresh Duplicati instance can import the configuration and restore selected files with verified hashes.

Does Duplicati require HTTPS behind a reverse proxy?

Use HTTPS for the public Duplicati origin and keep port 8200 on the internal route. Apply the Duplicati setting correctly: keep the management UI private or strongly authenticated behind HTTPS. For Duplicati, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Duplicati upgrade be tested?

Restore current Duplicati state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Duplicati's configuration database and backup format changes should be tested without rewriting the only remote backup set. Keep the previous Duplicati image until its data-migration and rollback boundary are understood.