patchpilot
Sign in

Data processing agreement

Under Article 28 GDPR. PatchPilot processes your servers' data on your behalf; a workspace accepts this agreement in the dashboard before its first server, and it applies from then on for as long as the workspace exists.

1. The parties

The controller is the customer whose workspace accepted this agreement. The processor is Max Nowack, Schillerstr. 1, 37120 Bovenden, Germany, [email protected], who provides PatchPilot under its terms of use.

2. Subject, nature and purpose

The processor shows the patch status of the controller's servers, installs their pending updates at the controller's direction, and notifies the workspace's members. For that it processes what the PatchPilot agent reports from each connected server, what a member enters, and the results of the runs the agent performs.

3. Data and data subjects

  • Data: hostnames; distribution, release, architecture and kernel; a hash of the machine ID; the installed packages and their versions, pending updates and held packages; whether a reboot is waiting; when the machine last started; when packages were last upgraded; whether Ubuntu Pro is attached; the output of runs; the IP addresses the agents connect from; the addresses of the workspace's webhooks and their signing secrets, if any are set.
  • Data subjects: whoever these data identify — typically the controller's staff, where a hostname or a package names a person.

The members' own accounts — their email addresses and sign-ins — are the processor's own processing, described in the privacy notice.

4. Instructions

The processor processes the data only on the controller's documented instructions: what the controller does in PatchPilot — connecting and removing servers, "Update now", maintenance windows, notifications — and this agreement. It tells the controller if it thinks an instruction breaks data protection law.

5. Confidentiality and security

Only the processor himself has access to the data; nobody else works on PatchPilot. The technical and organisational measures are in the annex below. They may develop, but never below the level described there.

6. Subprocessors

The controller agrees to these subprocessors:

  • Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany — the servers PatchPilot runs on and its backups, in Germany.
  • Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA — the network in front of patchpilot.cc, which every request passes through; a transfer to the USA under the EU–US Data Privacy Framework and the standard contractual clauses.
  • Sendinblue SAS (Brevo), 17 rue Salneuve, 75017 Paris, France — delivery of notification email, which names servers, packages and CVEs.

A webhook — Slack, Discord, Microsoft Teams or an address of the controller's own — is the controller's own choice, and its operator the controller's own processor. To name the CVEs of pending security updates and installed packages, the processor asks osv.dev (Google LLC) about a package name, a version and a release; to say how likely a CVE is to be exploited, it asks FIRST.org about the CVE's name; to know a CVE's severity and age, and which source files a kernel CVE is in, it asks CVE.org (The MITRE Corporation) about the CVE's name; CISA's catalogue of exploited vulnerabilities is fetched whole — nothing that identifies the controller, a server or a person. The processor announces a new subprocessor by email four weeks ahead; the controller can object and end the agreement.

7. Deletion

Removing a server deletes its data, its runs included; deleting the workspace deletes everything of it. The database is backed up every hour, and the backups are thinned out as they age: the last 72 hourly, 30 daily, 13 weekly and 12 monthly backups are kept, and one backup of every year without a time limit. Deleted data therefore stays in the backups taken before its deletion until they are thinned out, and in a yearly backup for good; backups are only read to restore the service. When this agreement ends, the processor deletes the controller's data in the same way, or hands it over first if the controller asks before the deletion.

8. Assistance

The processor helps the controller answer data subjects and meet its duties under Articles 32 to 36 GDPR, as far as it can from what it holds. It tells the controller of a personal data breach that concerns its data without undue delay, at the latest within 48 hours of becoming aware of it.

9. Evidence and audits

The processor makes available what the controller needs to see that this agreement is kept — documentation of the measures below, the open-source agent's code — and allows audits by the controller or an auditor it mandates, announced two weeks ahead, at the controller's cost.

10. Liability and the rest

Liability follows the terms of use and Article 82 GDPR. German law applies. Where this agreement and the terms differ, this agreement prevails for the processing of personal data.

Annex — technical and organisational measures

  • Access: production and its backups are reachable only with the processor's own credentials; there are no other staff. Members reach a workspace only by signing in with a single-use link to their email address, and see only the workspaces they belong to; every access is checked twice, at the page and in the data layer.
  • In transit: browsers and agents connect over TLS, through Cloudflare, which connects to the servers over TLS again.
  • Secrets: agent credentials, sign-in links and invitation links are kept only as digests; the enrollment token, the webhooks' addresses and their signing secrets are kept encrypted; no secret is written to a log.
  • On the controller's servers: the agent runs as its own unprivileged user in a systemd sandbox, connects outbound only, and reads the package and system state listed in section 3 and nothing else; the only part that runs as root installs updates with fixed commands and cannot be changed by the agent. Agent releases are signed, and the agent installs only signed releases.
  • Integrity and availability: the database is backed up every hour to a separate Hetzner storage box; every change to the service passes automated tests and dependency audits before it is deployed.
  • Records: sign-ins, invitations, membership changes, enrolled and removed servers and started runs are recorded in an audit trail.

Version 2026-11-04.