How Restow encrypts your data
Every chunk Restow writes to storage is encrypted with AES-256-GCM before it leaves the server, with a separate encryption key per organization. That is a structural property of the chunk store, not a setting to remember to turn on, and it applies the same way in every edition.
Who can actually read your data
On a self-hosted install (the normal way to run Community or Business), your organization's key never leaves your own infrastructure, and nobody outside it holds the key. On an instance a Service Provider operates for you under the Service Provider edition, that provider holds the installation's master key to operate the service, which is unavoidable for a service someone else runs, and can technically decrypt any tenant's data with it, including outside Restow entirely (for example with the offline standalone-restore tool and the chunk store directly, bypassing the running application). Reading and restoring inside Restow itself go through audited paths, landing in a tamper-evident, hash-chained log: who, when, for whom, and from which IP. That log cannot see access performed outside Restow with the master key directly. Choose a provider you trust for the same reason you would trust anyone holding a master key to your data, and have your data processing agreement (Art. 28 GDPR) cover this explicitly.
No phone-home
Restow does not call home: no telemetry, no license server contacted at runtime, no connection back to IT Systeme Flores UG. It connects only to what you configure: Microsoft 365, your IMAP servers, your chosen storage, and your mail transport. Beyond that, only when running in public mode, Let's Encrypt for your own TLS certificate; only if you switch the update check on, the update source you chose; and only if you enable the optional updater, the registry it pulls images from (ghcr.io by default). Endpoint agents talk only to your own Restow. A license key is verified offline against a signed Ed25519 signature, not by contacting a server at all.
The endpoint agent
The agent that backs up servers and clients (see server and client backup) connects outbound over HTTPS only and opens no port. It is append-only: it can add backups but never delete or overwrite them, and retention and pruning run only on the Restow server. It never holds the credentials of the storage target, only its own per-agent secret and the password of its own repository. Two limits are stated plainly. There is no mTLS yet: each agent authenticates with a per-agent secret over HTTPS, so a stolen secret (root on the machine) would allow writing new backups to that machine's repository and reading it, but not deleting anything. And the agent runs as root, because it has to read every file it backs up; pre and post hooks run as root as well, so whoever can change an endpoint's configuration in Restow can run commands as root on that machine. Treat administrator access accordingly. The install script and agent updates check SHA-256 checksums that come from your own Restow, which protects against corrupted downloads but not against a compromised instance; agent updates are not signed yet.
Signed releases
Every release image is built for amd64 and arm64, signed with cosign (keyless, through GitHub OIDC) and ships an SBOM in SPDX format, also attached as a cosign attestation. The release files are listed in a checksum file that is signed as well. How to check all of this is described in verify releases in the documentation.
Updates and the updater
The update check is off until an administrator turns it on. Once on, it only reads the release list of the source the operator chose (the public GitHub releases by default, or your own GitHub, Forgejo or Gitea repository), once a day or on request, and no request carries data about your installation. The optional updater is opt-in and a separate Compose profile that does nothing until you start it. It needs the Docker socket, which is root-equivalent access to the host: a documented trade-off, described in updates in the documentation, to read before you enable it.
The operator notice
The setup wizard starts with an operator notice that must be accepted before anything else: hardware and storage (redundancy, immutability or WORM), custody of the encryption keys, network and access security, and restore tests are the operator's responsibility, and the archive is designed for GoBD-compliant use. The acceptance (text version, time, client address) is stored and written to the audit log, and the server refuses the later setup steps until it exists. See the operator notice in the documentation.
The rest of the picture
Encryption is one piece of the sovereignty story; where the encrypted bytes physically live is the other, see storage and Your data is your data for the full picture together.
Frequently asked
How is my data encrypted in Restow?
Every chunk is encrypted with AES-256-GCM before it leaves the server, with a separate key per organization (tenant). Encryption is not optional or edition-dependent: it applies identically in Community, Business and Service Provider.
Can the operator of my Restow instance read my data?
On a self-hosted install (the normal way to run Community or Business), no one outside your organization holds the key. On a Service-Provider-operated instance, the provider holds the installation's master key and can technically decrypt tenant data with it, including outside the running Restow application (for example with the offline standalone-restore tool). Reading and restoring inside Restow itself go through audited, logged paths (who, when, for whom, from which IP) in a tamper-evident, hash-chained log; access outside Restow using the master key directly does not appear there. Choose a provider you trust, and cover this in your data processing agreement (Art. 28 GDPR).
Does Restow send telemetry or call home?
No. No telemetry, no license server contacted at runtime, no connection to IT Systeme Flores UG. It only connects to what you configure: Microsoft 365, your IMAP servers, your storage and your mail transport. In addition, only in public mode, Let's Encrypt for your own TLS certificate; only if you switch the update check on, the update source you chose; and only if you enable the optional updater, the registry it pulls images from (ghcr.io by default). Endpoint agents talk only to your own Restow.
What can the endpoint agent do on a machine, and what can it not do?
The agent connects outbound over HTTPS only and opens no port. It is append-only: it can add backups but never delete or overwrite them, and it never holds storage credentials. There is no mTLS yet, so each agent authenticates with a per-agent secret over HTTPS. The agent runs as root, and pre and post hooks run as root too, so whoever can change an endpoint's configuration in Restow can run commands as root on that machine.
Can I check that a release really comes from the Restow project?
Yes. Every release image is signed with cosign (keyless, through GitHub OIDC), ships an SBOM and is built for amd64 and arm64. The release files are covered by a signed checksum list. The documentation shows the verify command. Agent updates, by contrast, are checked against a SHA-256 checksum from your own Restow but are not signed yet.