News
How we designed the Duplicati Console so we can't read your backups
Your backup service can see your billing details and your job names. It can't see your files, your passphrase, or anything you type over a remote session — and here's the architecture that makes that true, limits included.
A backup service holds the most sensitive copy of your data there is: all of it, in one place. The usual answer to "can your staff read it?" is a policy document. Ours is an architecture: the Duplicati Console is built so that we can't, even if we wanted to, even if we were compromised, even if we were ordered to.
This post walks through the four design decisions that make that true, and the places where the design has limits. Duplicati is open source, so three of the four can be checked against the code rather than taken on trust; the fourth is a server-side choice, and we say so.
1. Your data is encrypted before it leaves your machine
Duplicati encrypts every backup volume on the client, with a passphrase only you hold, before a single byte goes to storage. This has been true since the first version, and the Console does not change it.
The important part is where the key lives. The passphrase is entered on the machine running the backup and stays there. It is never sent to the Console, never stored on our servers, and never recoverable by us. If you lose it, we cannot help you restore, and that is the point: a vendor who can recover your key is a vendor who can read your data.
Two consequences follow:
Your storage provider (S3, B2, OneDrive, a plain FTP server, whatever you chose) only ever receives encrypted volumes. They see sizes and timestamps, not content.
The Console only receives metadata about the backup job: status, timing, volume counts, errors. It never receives the volumes, and even if it did, it could not open them.
Encryption uses the AES Crypt format (AES-256) by default, with GnuPG as an alternative for teams that already manage GPG keys. Both implementations are in the open-source repository.
2. File paths are redacted before telemetry is sent
Encrypting the data is not enough on its own. A backup agent produces a stream of operational information: which files were skipped, which paths threw a permission error, which folders grew unexpectedly. Paths like C:\Users\Anna\Documents\Divorce\ or /home/dev/clients/acme-merger/ are themselves confidential, and a naive status feed would ship them to us by the thousands.
So the agent redacts paths before any report leaves the machine. Redaction is a client-side step, not a server-side filter: the Console never receives the raw string, so there is nothing for us to filter, log by accident, or be asked to hand over. What survives redaction is what we need to help you: the error type, the count, the backup it belongs to, and enough structure (depth, extension class, drive letter) to tell a "permission denied on one system folder" from a "half the dataset vanished."
The rule we apply is simple: if a field could identify a path, we redact it before it goes into telemetry. When you open a log in the Console, the detail you see is what the agent chose to send, and the agent's rules are in the source.
3. The remote tunnel is end-to-end encrypted; the relay sees only ciphertext
The Console lets you open the web UI of a machine that sits behind NAT, a corporate firewall, or a home router, without opening inbound ports. That requires a relay: the agent dials out to us, your browser dials out to us, and we join the two connections.
A relay is exactly the kind of component a vendor could abuse, so from Duplicati 2.4.0.1 the tunnel is end-to-end encrypted and the relay is blind. The agent and your browser establish an encrypted session with each other, keyed by material that only those two endpoints hold. The relay forwards opaque frames between them. It cannot read the UI you are looking at, the settings you change, or the passphrase you type into a restore dialog, because none of that is ever decrypted on our side.
Both ends dial out over TLS; inside that, a second layer of encryption runs end to end, so the relay in the middle only ever handles ciphertext.
Transport encryption (TLS to the relay) would protect you from the network. End-to-end encryption through the relay protects you from us. A relay that terminated TLS and re-encrypted would be a man-in-the-middle by design; ours is not able to be one.
What the relay does see is what it needs to route: which agent a session is for, when it was opened, and how many bytes flowed. That is the same metadata any proxy or VPN concentrator has.
4. Our own admins cannot impersonate you on the tunnel
Many SaaS products have a "log in as user" feature for support. It is convenient, and it is a backdoor: whoever holds admin credentials (or steals them) can do anything the user can do. For a backup console, "anything the user can do" includes opening a tunnel to a customer's machine and clicking Restore.
We blocked that path deliberately. The remote tunnel is only ever established for the user whose browser holds the session keys, and the Console has no impersonation mode that can mint those keys on an admin's behalf. A Duplicati staff account can see your organisation's subscription and your fleet's status. It cannot open a session to your agents, and there is no flag in the database that turns that on.
Unlike the other three properties, this one lives in the Console backend, which is not open source, so you cannot verify it by reading code. What you can verify is the client side: the agent only accepts a tunnel session keyed from your browser, and that code is public. The rest you have to take on our word, which is why we are putting it in writing.
This costs us something in support. When a customer has a problem on a machine, we cannot "just take a look"; we ask them to open the tunnel themselves and share their screen, or to send a redacted log. We think that trade is correct. A support shortcut that works for us also works for an attacker who phishes one of us, and for a small company the fewer such shortcuts exist, the less there is to defend.
What we can still see
A post like this is only credible if it is honest about the edges. Here is what the Console does know about you:
We see | We don't see |
|---|---|
Account email, organisation name, billing details | File contents, ever |
Which machines run an agent, their hostnames and OS | Your encryption passphrase |
Backup job names, schedules, success/failure, duration, volume counts | Full file paths (redacted before sending) |
Error categories and redacted log lines | Anything inside a tunnel session |
Tunnel session metadata: agent, time, bytes transferred | Your storage credentials (they stay on the agent) |
Two things are worth stating plainly. First, a backup job's name is chosen by you, and if you call it "Acme merger docs" we will see that string; name jobs with that in mind. Second, the agent runs on your machine with whatever rights you gave it, and an update we ship is code you run. That is the same trust you extend to every software vendor; what we have removed is the trust you would otherwise need to extend to our servers.
Don't trust us, read the code
The client-side mechanisms above live in the open-source Duplicati repository on GitHub: the encryption modules, the path redaction in the agent's reporting layer, and the tunnel client. The Console backend is not open source, but the design puts the properties that matter most on your side of the wire, where you can inspect them. The one exception, the absence of admin impersonation, is ours to uphold and yours to hold us to.
If you find a case where this post is wrong, where a path leaks, where the relay could learn more than routing metadata, we want to know. Our vulnerability disclosure policy is on this site, and we credit reporters.
Security marketing from a small vendor usually comes down to a page of logos. We would rather show you the design, tell you where it stops, and let you check.



