How Restow encrypts your data

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

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.

Database roles

Since 0.3.5, sign-in (sessions, passwords, passkeys and two-factor secrets) runs on a database role of its own. The application's role keeps to tenant data under PostgreSQL row-level security and may only add jobs to the queue. The database migration creates the sign-in role and keeps it up to date; no change to the .env file is needed, and DATABASE_AUTH_URL is optional for installations that manage their database roles themselves.

This is a hardening, and no exploit is known. Up to 0.3.4 the application's role could also read and write the tables outside row-level security, among them the sign-in tables, the installation settings, the license and the job queue, so a flaw in tenant-scoped query code could have reached data beyond its tenant. The change limits what such a flaw can reach; it does not mean there is none.

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. Since 0.4.5 a key can also carry an update period: whether a release is covered is decided from the key and from the release date that the release's image carries, not by a call to a server, and the installed version keeps working with all its modules.

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 the machine decides whether it runs them: they are off on a new machine, only root on the machine can allow them (named scripts only, or any command), and Restow can neither change that setting nor set a hook the machine would not run. Where any command is allowed, whoever can change that endpoint's configuration in Restow can run commands as root on the machine; treat administrator access accordingly.

The agent is installed in a folder only root can change, and every agent release is signed by the maintainer with an Ed25519 key that is compiled into the agent and written into the install script. The installer and the agent's self-update check that signature and the SHA-256 of every file before they run anything, so a compromised instance cannot make an installed agent run a binary of its own. One limit remains: the first installation trusts the install script the instance serves, as any curl | sh does. Compare the release key fingerprint the script prints with the published one, SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (Ed25519, also in the release notes).

Signed releases

Every release comes as two builds: the full images restow and restow-web, and the Community images restow-community and restow-web-community. Each of the four images 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, and agent releases carry the maintainer's own signature (see above). 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. Before it pulls an image, it verifies the image's cosign signature against the identity of the release workflow and refuses an image it cannot verify. Changing the update source and announcing an update ask for a recent sign-in. The updater 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.

Since 0.3.6, a change that takes effect only after a restart shows a "Restart required" notice under Installation, Updates, with the reason and the command to copy, and provider admins see a notice above every page. With the updater running, the owner of the provider team also gets a "Restart now" button. It goes through the updater and restarts the API, the worker or the scheduler only, no other service. It never runs while an update is announced or running, it asks for a confirmation first, and the audit log records who asked. Nothing restarts without a click. The button needs the updater of 0.3.6; an older updater shows the command instead. Nothing records a restart request yet: the notice and the button are in place for updates that need them.

Since 0.4.2, an update can also be planned for a chosen date and time, up to 30 days ahead, in the installation's time zone. Nothing pauses before it: the server confirms the plan the countdown before the chosen time exactly as if an administrator had confirmed it then, with the same checks, and everyone signed in sees a notice from a day before. After the server runs the new release, Proxmox VE nodes and agents install it too, only while idle, through the same signed download as their own self-update (the agent checks the signed SHA256SUMS with the key built into it, then every file with its signed hash), and new runs wait until they have, 15 minutes at most. restow-agent update does it by hand on a machine, like restow-pve update on a node; while a backup runs it refuses.

Since 0.3.6, running the installer (install.sh) again on an existing installation also updates an old docker-compose.yml to the release named in .env. The installer checks the file against the release's signed SHA256SUMS, keeps the old file as docker-compose.yml.bak-<timestamp> and leaves .env as it is.

Immutable backups and ransomware detection

Encryption protects what an attacker can read; it does not stop deletion. Since 0.4.0, two further layers do. Every repository can be made immutable: on S3 with Object Lock, the storage itself refuses to delete or overwrite locked backup data before its date, whoever asks; a directory only gets a deletion delay that Restow keeps, which is not immutability. It is off until an administrator turns it on, and lowering it needs the provider owner with a recent sign-in. What is locked and what is not, and what it does not protect against, is on the storage page. Ransomware detection judges every new restore point, marks the suspicious ones, alerts once per attack and pauses retention of the object until an administrator resolves the finding. It is a tripwire, not a virus scanner, and it was tested with simulated attacks only; see ransomware detection.

S3 endpoints over HTTPS

Since 0.4.0, a new or changed S3 endpoint over plain http:// is refused, for provider administrators and the installation default too, except to the machine itself. Endpoints saved before keep working and say in red that they should move to HTTPS.

The mounter and file shares

File share backup (see file shares) runs in short-lived runner containers that the mounter starts, and the mounter holds the Docker socket, which is root-equivalent access to the host. New installations start it by default; install.sh --no-mounter leaves it off, and the mounter's security notes are worth reading first. A runner has no network except an internal one to the API, mounts the share read-only, and writes with a credential that is valid for one run and append-only. Tenant administrators can add file shares themselves; a share on a private or loopback address needs a provider administrator's approval or the installation switch "Tenants may use private networks".

Database dumps, updates and file restore

Before an update, the updater keeps a dump of the database. The Updates tab lists these dumps, and the provider owner can download one, through a one-time link, after a recent sign-in, with an audit entry, or delete it. A dump holds the whole database, the encrypted secrets included: keep a downloaded dump as carefully as the master key. When an update is confirmed, its dialog counts what still runs in every tenant and asks whether to stop the runs cleanly, wait for them or not wait; from the confirmation until the update is over no new run starts. Since 0.4.2 an administrator can also stop a running backup from the web app (Proxmox VE guests, machines and file share runs); every stop asks first and is written to the audit log, and the run ends as cancelled.

Restore operators, who see and restore backups without administering them, can now also open Servers & clients, File restore: they browse restore points, download files as a ZIP and restore files onto a machine, and for Proxmox VE browse and download files of container and VM restore points. Settings, tokens, jobs, backing up, restoring a whole guest and the repository password stay with the administrators. Every read, download and restore is written to the audit log with the operator as the actor. A prepared download of Proxmox VE files can be started once, within ten minutes, by the administrator who prepared it, and the files of a VM are read by the server in a restricted child process, without mounting anything.

The operator notice

The setup wizard first asks for a one-time setup token, which only someone with access to the server's log (or its configuration) can read. Then it shows an operator notice that must be accepted before anything else is set up: 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. Data is only immutable if the storage makes it so: without Object Lock on the storage location, anyone who can reach it can change or delete the backups. Since 0.4.0 Restow can lock backup data on S3 with Object Lock, and a directory gets only a deletion delay (see above). The acceptance (text version, time, client address) is stored and written to the audit log, and the server refuses to complete the setup without it. 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).

Which database permissions does the Restow application have?

Since 0.3.5, sign-in (sessions, passwords, passkeys, two-factor secrets) runs on a database role of its own, and the application's role keeps to tenant data under row-level security and may only add jobs to the queue. Up to 0.3.4 the application's role could also read and write the tables outside row-level security, such as the sign-in tables, the installation settings, the license and the job queue. That was a hardening, not a fix for a known exploit.

Does Restow restart its services on its own?

No. When a change takes effect only after a restart, Restow shows a "Restart required" notice with the reason and the command to run on the server and, with the updater running, a "Restart now" button for the owner of the provider team. The button goes through the updater, covers the API, the worker or the scheduler only, never runs while an update is announced or running, and asks for a confirmation first. Nothing restarts without a click. Nothing records a restart request yet; the notice and the button are in place for updates that need them.

Can backups be locked so that nobody can delete them?

Per repository, since 0.4.0. On an S3 bucket created with Object Lock, Restow locks backup data in compliance or governance mode for 1 to 3650 days, and the storage itself refuses to delete or overwrite it before the date. A directory gets only a deletion delay that Restow enforces itself, which is not immutability. Immutability is off until an administrator turns it on, and it does not help if someone who controls Restow stops the locks; what is locked stays locked until its date. It was tested against a simulated S3, not yet against a real S3 service with Object Lock.

Does Restow detect ransomware?

It judges every new restore point for signs of it (the amount of change, deletions, renamed extensions, known names, sampled files that look encrypted, data that neither compresses nor deduplicates), marks suspicious ones, alerts once per attack and pauses retention of that object until an administrator resolves the finding. It is a tripwire, not a virus scanner, it never blocks a backup, and it was tested with simulated attacks, not with live ransomware.

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. Pre and post hooks run as root too, so the machine decides: they are off until root on the machine allows them (only named scripts, or any command), and Restow cannot change that setting.

Can I check that a release really comes from the Restow project?

Yes. Every release comes as two builds in four images (restow and restow-web, the full build; restow-community and restow-web-community, the Community build), each signed with cosign (keyless, through GitHub OIDC), with an SBOM, and built for amd64 and arm64. The release files are covered by a signed checksum list. The documentation shows the verify command. Every agent release is signed by the maintainer with an Ed25519 key; the installer and the agent check that signature before they run anything. The first install trusts the install script your instance serves: compare the release key fingerprint it prints with the published one, SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (also in the release notes).

How tenant isolation works →

Ransomware detection: how every restore point is judged →