Data processing agreement
Version 2026-11-10.a7056505
Last updated: 2 November 2026
1. About this agreement
1.1 This agreement is between you, the customer under our terms of service, and Zer0Paper OÜ, registry code 16797271, Ahtri tn 12, 15551 Tallinn, Estonia ("we"), which runs Clusterz. It forms part of the terms, and you accept it when you accept them. Made electronically, it counts as made in writing under Article 28(9) of the GDPR.
1.2 It covers the personal data in the apps you run on Clusterz, which we process for you. In this agreement we call that data "your data". It contains what Article 28 of the EU General Data Protection Regulation (GDPR) and section 29 of the Nigeria Data Protection Act 2023 (NDPA) require.
1.3 Words such as controller, processor, processing and personal data breach have the meanings the GDPR gives them.
1.4 If this agreement and the terms differ about your data, this agreement applies. If the standard contractual clauses in section 11 apply and differ from this agreement, the clauses apply.
1.5 Our contact for data protection is contact@clusterz.eu.
2. Roles
2.1 For your data, you are the controller and we are your processor.
2.2 If you process the data for someone else, as their processor, you confirm that they allow you to use us. We are then your subprocessor, and you pass their instructions to us.
2.3 For the data we collect to run your account, such as the names and email addresses of your team members, the tokens that connect a member's account to your repositories, billing records and audit records, we are the controller. We are also the controller of the addresses of detected attackers that our security software sends to CrowdSec SAS. Our privacy policy covers that data, not this agreement.
2.4 If you are outside the European Economic Area, we keep our duties as a processor under the GDPR. Using us does not by itself make the GDPR apply to you.
3. What we process, and for how long
3.1 Annex 1 sets out the subject, nature and purpose of the processing, the kinds of personal data and of people concerned, and how long we keep each kind.
3.2 We process your data for as long as we provide Clusterz to you, and afterwards until we have deleted it under section 14.
4. Your instructions
4.1 We process your data only on your documented instructions. Your instructions are the terms, this agreement, and what you do in Clusterz, such as installing, deploying, restoring or deleting an app. Any other instruction must reach us by email, or through our help form, from an owner or admin of your team. Please keep personal data from your apps out of that message.
4.2 We do not use your data for any purpose of our own, except the security use in section 2.3.
4.3 If EU law, or the law of an EU member state, requires us to process your data in another way, we tell you before we do, unless that law forbids it on important grounds of public interest.
4.4 If we think an instruction breaks the GDPR or another data protection law, we tell you at once.
4.5 You are responsible for having a lawful basis for your data, and for meeting any condition the law sets for special categories of data, such as health data.
5. Confidentiality
5.1 Everyone we allow to process your data is bound to keep it confidential, by contract or by law.
5.2 Our staff open your apps or read your data only as section 10 of the terms allows.
6. Security
6.1 We take the technical and organisational measures in Annex 2.
6.2 We may change these measures, but not in a way that protects your data less.
6.3 You are responsible for the security of what you build and set up, such as your own code, the users and passwords in your apps, sign-in or access control on every service your app offers, and who you let into your team.
7. Subprocessors
7.1 You allow us to use the subprocessors listed on our subprocessors page.
7.2 We email the owners and admins of your team at least 30 days before we add or replace a subprocessor, or change where one keeps your data or what it does for us, and we update that page.
7.3 You can object by email to contact@clusterz.eu before the change applies, giving your reasons. We then look for a solution with you. If we find none, you can end the contract before the change applies, and we refund your unused credit, as section 5.3 of the terms says.
7.4 We bind each subprocessor by contract to data protection duties that match those in this agreement. We remain fully liable to you for the work of each subprocessor.
7.5 Let's Encrypt and CrowdSec SAS are not our subprocessors. They receive data for their own purposes, as section 3 of the subprocessors page explains.
7.6 The apps we offer work as their makers designed them, and some contact their makers or other services by themselves. Those companies are not our subprocessors either. Section 5 of the subprocessors page explains this, and you choose whether to install each app.
8. Helping you with people's requests
8.1 If a person asks us to act on their rights over your data, we pass the request to you without undue delay. We do not answer it ourselves unless you ask us to.
8.2 We help you answer such requests under Articles 15 to 22 of the GDPR, as far as the nature of the processing allows. You can read, correct and delete most of your data yourself, in your apps.
9. Helping you with security, assessments and authorities
We help you meet your duties under Articles 32 to 36 of the GDPR: security, notice of personal data breaches, data protection impact assessments, and prior consultation with a supervisory authority. We do so with the information we have.
10. Personal data breaches
10.1 We tell you without undue delay after we become aware of a personal data breach that affects your data. We tell you by email to the owners and admins of your team.
10.2 We tell you what we know, and more as we learn it: what happened; the kinds and approximate numbers of people and records concerned; the likely consequences; what we have done and will do about it; and whom to contact. You need this to report the breach to your supervisory authority within 72 hours where the law requires it.
11. Transfers outside the European Economic Area
11.1 We keep your data in Germany, as Annex 1 says. It leaves the European Economic Area only on your instructions, or as the subprocessors page shows. That page gives the safeguard for each subprocessor that moves data out of the European Economic Area. Let's Encrypt in the United States receives domain names only. What apps do by themselves is covered by section 7.6.
11.2 If you are outside the European Economic Area and act as a controller, sending your data to you is a transfer from us to you. For it, Module Four (processor to controller) of the standard contractual clauses adopted by the European Commission in Implementing Decision (EU) 2021/914 forms part of this agreement. In those clauses:
- we are the data exporter and you are the data importer, with your details in your account and ours in section 1.1;
- the transfer is continuous, for as long as you use Clusterz;
- the optional docking clause (Clause 7) does not apply;
- Clauses 14 and 15 apply only where we combine the personal data you send us with data we collect in the European Union, as that module says;
- Estonian law governs them (Clause 17), and the courts of Estonia settle disputes about them (Clause 18);
- Annex 1 of this agreement gives the details their Annex I asks for.
11.3 Those clauses are for customers that act as controllers. If you are outside the European Economic Area and act as a processor for someone else, tell us before you put that data on Clusterz.
12. Requests from public authorities
12.1 If a public authority asks us for your data, we ask it to contact you where we can.
12.2 We give your data to an authority only where EU law, or the law of an EU member state, requires it. An order from an authority outside the EU counts only under an international agreement, as Article 48 of the GDPR says.
12.3 We tell you about the request before we answer it, unless the law forbids it.
12.4 If we report a suspected threat to life or safety under Article 18 of the EU Digital Services Act, the report may include your data. We tell you afterwards, unless the law forbids it.
13. Information and audits
13.1 We give you the information you need to show that we meet Article 28 of the GDPR.
13.2 We allow audits, including inspections, by you or by an auditor you choose, and we help with them. We agree the date and scope with you in advance. The auditor must keep what they learn confidential, and an audit must not give access to other customers' data.
14. Deleting and returning data
14.1 You can delete your apps at any time, as section 14 of the terms describes.
14.2 When our service to you ends, you choose whether we return your data or delete it. To return it, we help you take it, as section 14.5 of the terms describes. Then we delete it.
14.3 Deletion works like this:
- Deleting an app stops its services and deletes its settings and domains at once. After 7 days we delete its record, with its build history, its images and the key that unlocks its backups.
- We erase the data a deleted app stored on our servers, any team database or bucket Clusterz set up for it, and its database backups when you ask us to by email to contact@clusterz.eu.
- We delete your whole team, with its apps, the data they stored, any team database and buckets, and their backups, when its owner asks us to by email to contact@clusterz.eu, or your organisation does under section 3.4 of the terms.
- If your team's apps stop for lack of credit, your data stays until the team is deleted.
- We complete a deletion you ask for within one month.
- Copies of your data in our log store expire within 30 days, in any backup of our own databases within 40 days, in our metrics within 90 days and in our error reports within 100 days. The servers' own log files are overwritten in turn as they fill.
14.4 After that, we keep a copy of your data only where EU law, or the law of an EU member state, requires us to.
15. Nigeria
15.1 If the NDPA applies to your data, we also meet the duties it sets for processors.
15.2 Our notice of a breach under section 10 includes the nature of the breach and the kinds and approximate numbers of people and records affected, so that you can report it to the Nigeria Data Protection Commission within 72 hours.
15.3 You are responsible for the legal basis for sending data from Nigeria to us in Germany under sections 41 to 43 of the NDPA, and for recording it. We give you the information you need for it.
16. Liability
Section 15 of the terms applies to this agreement, including to claims between you and us under Article 82(5) of the GDPR. It does not limit what either of us owes to people under Article 82.
17. Term, changes and law
17.1 This agreement lasts as long as we process your data.
17.2 We change it only as section 16 of the terms describes, with at least 30 days' notice by email, unless the law makes us change it sooner.
17.3 Estonian law governs this agreement, and section 17 of the terms applies to disputes about it. Section 11.2 sets the law and courts for the standard contractual clauses.
Annex 1. Details of the processing
Subject: hosting and running the apps you install or deploy on Clusterz, with their databases, files and logs.
Nature: storing, running, copying into backups, restoring, logging, monitoring, sending over networks and deleting, on our servers and those of our subprocessors.
Purpose: providing Clusterz to you, as the terms describe.
Duration: as section 3.2 says.
People concerned: you decide. Depending on your apps, they can include your staff and team members; your patients, clients, members and borrowers; people who use or visit your apps; and people named in the code we build for you.
Kinds of data: you decide. Depending on your apps, they can include:
- names, contact details and other identifying details;
- health records, for example in the apps of the Healthcare records bundle;
- financial, savings and loan records, for example in the apps of the Microfinance bank bundle;
- files, messages and stored passwords, for example in the apps of the Healthcare office bundle;
- anything your own code keeps in a team database or bucket Clusterz set up for it.
For every app we also process records of the requests made to it (the visitor's IP address, the address and path requested, the method, the response and the time) and whatever the app writes to its logs. For apps built from your code, we process each commit's ID, message, branch and author name, and a short extract of each build log.
Special categories: your apps may hold health data or other special categories of personal data. You decide this, and you are responsible for the condition the law sets for it.
Where: in Germany. Your apps and their data run on servers of Hetzner Online GmbH in Germany. Backups, images and logs are stored in Hetzner's object storage in Falkenstein, Germany. So are the files of an app that keeps them there, which today is Nextcloud, with a nightly copy in Hetzner's object storage in Nuremberg, Germany. The keys that protect backups are held by Google Cloud's key service in Frankfurt, Germany. What you type into the assistant goes to Anthropic, PBC in the United States, which runs the assistant's AI model. The subprocessors page lists everything else.
How long we keep it:
| Data | How long |
|---|---|
| Data in your apps, and any team database or bucket Clusterz set up for your code | Until you delete it in the app, or we erase it at your request |
| Database backups | While an app runs, every copy for 7 days, then one copy a week until the end of the backup period shown on the app's page, or a longer one you buy there. We also keep the newest copy, and the copy that a restore to the start of the period needs. A deleted app's backups stay until we erase them at your request. |
| Records of requests to your apps, and your apps' logs | 30 days in our log store. The servers' own log files are overwritten in turn as they fill. |
| Metrics | 90 days |
| Error reports from our services, including failed builds and deploys of your apps | 90 days. The entry that groups repeated errors goes within 7 days after that. |
| Build log extract | 24 hours for a successful build. For a failed or cancelled build, until the app's record is deleted. A build's output may also stay in our log store for 30 days. |
| Commit details, and images built from your code | Until the app's record is deleted |
| The record of a deleted app | 7 days |
| Your apps' settings and build records, in any backup of our own databases | Up to 40 days |
| Emails you send us, and messages you send through our help form | While the account exists. We delete them within 30 days after it closes. |
| What you type into the assistant | 30 days |
Annex 2. Security measures
1. Access
- People sign in through Google, Apple, GitHub, GitLab or Bitbucket. Clusterz keeps no passwords for them.
- A dashboard sign-in lasts 15 minutes and renews itself for up to 7 days, through cookies that scripts cannot read and that are sent only over HTTPS. The command-line tool keeps its own tokens on the user's computer.
- Each member of a team has one role: owner, admin, developer or viewer. Only owners and admins can delete apps, restore backups, add credit or manage members. Only the owner can reveal or reset an app's admin password, and we record each reveal and reset.
- An invitation lasts 7 days and works only for the verified email address it was made for.
- Secret settings are masked in the dashboard.
2. Networks and containers
- The databases and internal services of the apps you install from us sit on a private, encrypted network of their team's own. No other team's apps are on it.
- Apps receive traffic from the internet only through our router, and expose no ports of their own.
- Apps are not on the networks of our API, our own databases, our job system, our monitoring or our image registry.
- Our deploy and build services reach the container engine through restricted proxies.
- Apps you install from us run with every special system permission removed except those an app needs, and most of their services run with a read-only file system.
- Apps run with limits on memory and processing power.
- Your code is built in containers used once, which cannot gain new privileges, have limits on memory, processing power and processes, and do not reach our networks.
3. Encryption
- The dashboard, the API and your apps' web addresses are served over HTTPS, with certificates from Let's Encrypt.
- Backups are encrypted before they leave our servers, with a random key for each app. Google Cloud's key service in Frankfurt protects those keys. Google handles a key when it wraps or unwraps it, and never receives the backups.
- Secret settings, repository access tokens, and each app's database and storage credentials are stored encrypted with AES-256-GCM in our database. Tokens for our image registry are stored only as hashes.
- Our emails to you leave our servers only over an encrypted connection.
4. Backups and restore
- For each running app you installed from us that has a database, we back up that database.
- A PostgreSQL database sends its latest changes to its backup at least every 60 seconds, and we take a full copy of it each night. The dashboard offers a restore to any minute from 2 minutes ago back to the start of its backup period, or back to its last restore if that is later.
- A MariaDB database is copied in full each night, and the dashboard offers a restore to one of those nightly copies.
- While an app runs, we keep every copy for 7 days, then one copy a week until the end of the backup period shown on the app's page, or a longer one you buy there.
- Owners and admins can ask for a restore. The app is stopped while it is restored. A restore first checks that its backup still exists, and fails without stopping the app if it does not. Each restore ends by taking a fresh full copy.
- Backups are stored in Hetzner's object storage, apart from the servers that run the apps.
5. Logging and monitoring
- Builds, deploys, rollbacks and changes to a team's apps, settings, domains and members, and installs of bundles, are recorded in the team's audit log with the member, the time, and the member's IP address and browser. The changes our staff make in our admin tools are recorded too.
- The output of every app and service is kept in our log store for 30 days, labelled by team and app. Your team can read only its own apps' logs.
- Our router logs every request to your apps, with the visitor's IP address, the address and path, the method, the response and the time, and keeps these records in the same logs.
- We check the public address of each app you installed from us every minute and alert our staff to an outage. status.clusterz.eu checks our API, dashboard, webhooks and image registry every minute.
- CrowdSec software runs on our servers. It is set up to read our router's logs, detect attacks on Clusterz and your apps and, where we enable it, block the addresses they come from. We do this for you as a security measure. For each attack it detects, it sends the address, its location when available, the kind of attack and the time to CrowdSec SAS, which receives them for its own purposes and not as our subprocessor. It sends no logs.
- We run Velociraptor so that our staff can investigate an incident.
- Errors in our services go to our own error-tracking service, on our own servers, where we keep them for 90 days. Alerts about failures in our own systems, with team and app identifiers and the cause, go to our staff chat at Google.
6. Staff access
- Our staff open your apps or read your data only as section 10 of the terms allows.
- Our admin tools show teams, members and apps, not the data inside the apps.
- Everyone we allow to process your data is bound to keep it confidential.
7. Data centre
- Your apps run in Hetzner's data centres in Germany. Hetzner runs the data centres and their physical security.
8. Software and changes
- We scan the images we build for the apps we offer for known vulnerabilities and secrets, record what each contains, and sign them.
- We remove URL credentials, authorisation headers and our registry and clone tokens from saved build logs.
- Changes to Clusterz pass automated tests in our pipeline before they are released.
9. Testing
- Every night we check the integrity of each PostgreSQL database's backups. A failed check or a failed backup alerts our staff.
Annex 3. Subprocessors
The subprocessors page lists our subprocessors, what each does, what data it handles, and where.