Data Processing Agreement

Last updated November 9, 2026

This English version of the agreement under Art. 28 GDPR is for information; if it differs from the German version, the German version prevails.

Parties

Controller: the company that uses devboxes for its Organization (the “Customer”):

Company: ______________________
Address: ______________________
Organization in devboxes: ______________________

Processor: Firat Özcan, sole proprietor, operator of devboxes, Leonhardstraße 44b, 38102 Braunschweig, Germany, privacy@devboxes.ai (“devboxes”).

§ 1 Subject matter and duration

devboxes processes personal data on the Customer’s behalf to provide the devboxes service under the Terms of Service (the “Main Agreement”).
Annex 1 describes the nature and purpose of the processing, the types of personal data and the categories of data subjects.
This agreement applies for as long as devboxes processes the Customer’s personal data, and at least for the term of the Main Agreement.
Data that devboxes processes as a controller in its own right is outside this agreement. That includes account sign-in data (passwords, sessions and sign-in logs; Annex 1 covers the members' identifiers in the Organization), billing data, server logs kept for the security of the service, and the data the Privacy Policy describes.

§ 2 Instructions

devboxes processes the data only on the Customer’s documented instructions, including for transfers to a third country, unless Union or German law requires the processing. In that case devboxes informs the Customer of that requirement before processing, unless the law prohibits it.
The Customer’s instructions are the Main Agreement, this agreement, and the settings that the Organization’s owners and admins make in devboxes, including connected repositories, tools, model providers, Runners, egress rules and erasures. The Customer gives further instructions in text form to privacy@devboxes.ai.
devboxes informs the Customer without undue delay if it considers an instruction unlawful, and may suspend it until the Customer confirms it.

§ 3 Confidentiality

devboxes is a sole proprietorship. Only its owner has administrative access to the Customer’s data. If devboxes engages other persons, it first commits them to confidentiality unless a statutory duty of confidentiality already binds them.

§ 4 Technical and organisational measures

devboxes implements the measures under Art. 32 GDPR that Annex 2 describes.
devboxes may develop the measures further if the level of protection does not decrease. It documents material changes and shares them with the Customer on request.

§ 5 Subprocessors

The Customer authorises the subprocessors listed in Annex 3.
The Customer gives devboxes general authorisation to engage further subprocessors or replace existing ones. devboxes informs the Organization’s owners by email at least 30 days in advance. Within that period the Customer may object in text form for an important data protection reason. If the parties cannot agree, either party may terminate the Main Agreement with effect from the change.
devboxes binds every subprocessor by contract to the obligations of this agreement and remains responsible to the Customer for the subprocessor’s performance. No such contract is concluded yet with Monid, or with OpenAI for System Sessions (Annex 3). devboxes concludes one, or stops using these subprocessors for the Customer’s data.
Services that the Customer chooses and has its own agreement with are not devboxes’ subprocessors. That covers the model provider the Organization connects, repository hosts, chat and issue tools, and the other services in Annex 3, Part B. devboxes transfers data to them on the Customer’s instruction.

§ 6 Transfers to third countries

devboxes transfers personal data to a country outside the European Economic Area only when Art. 44 to 49 GDPR are met, in particular on the basis of an adequacy decision, such as the EU-US Data Privacy Framework, or of the European Commission’s Standard Contractual Clauses. Annex 3 names the basis for each subprocessor. Monid, and OpenAI for System Sessions, are exceptions for now: no such basis is agreed yet for their transfers to the USA (§ 5(3)).

§ 7 Assistance

Data subject rights: devboxes assists the Customer with appropriate measures in answering requests under Art. 15 to 22 GDPR. Owners and admins erase Sessions themselves, except System Sessions. A person deletes their own Chat message in their chat app, and devboxes then deletes its copy, except on Telegram (Annex 2, item 10). devboxes handles other requests sent to privacy@devboxes.ai. If a data subject contacts devboxes directly, devboxes forwards the request to the Customer.
Art. 32 to 36 GDPR: devboxes assists the Customer with the security of processing, breach notifications, data protection impact assessments and prior consultation, as far as the nature of the processing and the information available to devboxes allow.

§ 8 Personal data breaches

devboxes notifies the Customer of a personal data breach without undue delay, and no later than 48 hours after becoming aware of it, by email to the Organization’s owners. The notice contains the information under Art. 33(3) GDPR as far as it is known. devboxes takes measures without undue delay to contain the breach and mitigate its consequences.

§ 9 Deletion and return

After the Main Agreement ends, devboxes deletes the Customer’s data within 30 days unless the law requires it to be kept. Until then the Customer can retrieve its data through the CLI and the API, or request an export from privacy@devboxes.ai. Media that Langfuse extracts from traces is the exception: devboxes does not delete it (Annex 2, item 10).
devboxes does not delete individual records from backups. Backups expire after at most 38 days (Annex 2, item 9).
devboxes confirms the deletion in text form on request.

§ 10 Evidence and audits

devboxes gives the Customer, on request, the information needed to demonstrate compliance with Art. 28 GDPR.
The Customer, or an auditor it appoints who is bound to confidentiality, may audit compliance with this agreement. The Customer announces an on-site audit at least four weeks in advance. It takes place at most once per calendar year during business hours, unless a specific incident justifies another. The Customer bears the cost of its audit. The Customer audits subprocessors’ data centres through their certifications and reports.

§ 11 Liability

Art. 82 GDPR governs liability. Otherwise the liability terms of the Main Agreement apply.

§ 12 Conclusion and final provisions

The agreement is concluded when the Customer sends it signed to privacy@devboxes.ai, or accepts it there in text form by email.
Where they conflict on the protection of personal data, this agreement prevails over the Main Agreement.
Amendments require text form.
German law applies.
If a provision is invalid, the rest remains in force.

Place, date: ______________________
Customer: ______________________
devboxes (Firat Özcan): ______________________

Annex 1: Subject matter of the processing

Nature and purpose

devboxes is an agent the Customer hands work to from its chat and issue tools, the CLI or MCP. For each task an agent works in an isolated workspace, either on devboxes’ servers in Germany or on a Customer machine (a Runner). devboxes processes the data to:

read the Customer’s repositories, load code into agent sessions and open pull requests;
send instructions and context to the model provider the Organization connects;
run, for every new Project on managed servers, an onboarding Session and a calibration Session (System Sessions) on devboxes’ own model, which read the repository;
read messages and issues in connected tools and reply there;
run agents’ web searches;
store Session transcripts, events, artifacts, Chat conversations and Organization memory so members can follow and resume work;
keep the Organization’s secrets and credentials and use them only for its work;
fix errors and operate the service.

Types of personal data

identifiers of the Organization’s members: name, email address, role, linked GitHub or Google accounts
repository content, including the names and email addresses in commits and any personal data in the code
tasks, instructions, Session transcripts, commands, tool output, diffs and artifacts
messages and threads from connected chat tools, and issues and comments from connected issue tools, including messages from people without a devboxes account
Organization memory entries
secrets and credentials the Organization stores
agents’ search queries
metadata of the Customer’s Runners

Special categories under Art. 9 GDPR are not the subject of the processing. If the Customer puts them into tasks, repositories or tools, devboxes processes them like the other data.

Categories of data subjects

members of the Customer’s Organization
people whose messages or issues are in connected tools
people whose data is in the repositories and systems of the Customer that agents work with

Annex 2: Technical and organisational measures

1. Location

All devboxes servers are in Germany: a dedicated server in Hetzner’s Falkenstein data centre (FSN1-DC18) and Hetzner Cloud servers in Falkenstein. Managed tasks run only on these servers.
Session artifacts and backups are in Cloudflare R2 in the EU jurisdiction.

2. Physical access control

devboxes runs no premises with servers. Hetzner’s measures under its data processing agreement with devboxes govern access to the data centres (Annex 3).

3. System access control

Servers: SSH sign-in by key only, with passwords disabled.
Operator access to Production goes through Cloudflare Access and reaches the Kubernetes API, Prometheus and the PostgreSQL replicas. Prometheus and the replicas are read-only for every credential. The operations agents’ credential only reads the Kubernetes API, without Secrets.
Users sign in with email and password (at least 12 characters, verified email address), with a code sent by email, or through GitHub or Google.
Each person can turn on two-factor authentication (TOTP). With it on, devboxes refuses sign-in by email code. It does not guard GitHub or Google sign-in.
Write actions in the admin area require a sign-in within the last five minutes.

4. Data access control

Sessions and results are visible only to the members of their Organization, and a copied link does not widen access. There are two exceptions: devboxes’ posts in a trusted channel can carry a revocable token that only reads, and a member can open a question session for a Session, in which for up to 12 hours anyone with its link and its password reads the Session and answers its questions.
Roles: owner, admin and member. Only owners and admins add credentials and erase Sessions.
devboxes’ owner is the superuser. Only the superuser can open the admin area. It answers everyone else like an unknown path, has no impersonation, and records every write with its reason.
An agent on a managed task sees passwords and keys only as placeholders. devboxes inserts the real value only when a request leaves for an allowed service. A task on the Customer’s Runner receives the real values.

5. Separation

Each managed task runs in its own sandbox under gVisor, in a separate Kubernetes cluster on separate virtual machines from the platform.
Each task gets its own network policy. It reaches package registries, GitHub, its model’s hosts, devboxes’ hosts and the hosts the Organization allows. Everything else is refused.
A sandbox ends at most twelve hours after it starts.
Each Organization’s credentials are encrypted under its own key.

6. Encryption

In transit: Cloudflare connects to devboxes’ servers only over TLS with full certificate validation, TLS 1.2 or later, and with Authenticated Origin Pulls. PostgreSQL refuses every connection without TLS.
Every drive of the dedicated server is encrypted with LUKS2, except the boot partition that holds the kernel and the boot environment. A drive that leaves the server, for example after a failure or a swap, holds no readable data.
The disks of the cloud servers that run managed tasks are not encrypted. They hold a task’s workspace until its sandbox ends.
Stored credentials (model sign-ins, repository and tool tokens) are also encrypted under each Organization’s own key. When devboxes deletes an Organization’s key, its credentials become unreadable, in backups too.
The Organization’s secrets are in Infisical, which encrypts every value.
Kubernetes Secrets are encrypted in the cluster datastore.
Backups are encrypted before they leave the server: PostgreSQL with AES-256, ClickHouse and the Kubernetes datastore with age. Cloudflare also encrypts every R2 object with AES-256.

7. Transfer control

devboxes sends managed Sessions’ web searches with the query text only, without account name, email address or network address.
Error reports go to a self-hosted Sentry instance. devboxes first removes exception messages, query strings and known secrets.
Traces of Runs and Chat turns go to a self-hosted Langfuse instance. Its key reaches no sandbox and no Runner.

8. Input control

The API writes security-relevant actions to an append-only log. Entries expire after 180 days.
The Session transcript records the instructions, commands, tool events and diffs of every task.
Production’s cluster configuration changes through reviewed commits that Flux applies. The owner changes hosts, virtual machines and datastores with runbooks from the same repository, and Cloudflare and Infisical settings through their APIs.

9. Availability and recoverability

The dedicated server mirrors its two NVMe drives (RAID1). An alert pages the owner when a drive fails or a filesystem is nearly full.
PostgreSQL runs with a synchronous standby. Both run on the same virtual machine.
All platform services run on one server in one data centre. There is no second site.
Backups: PostgreSQL in full every Sunday and differential on the other days, with a WAL archive for recovery to any point in the last 30 days; ClickHouse daily; the Kubernetes datastore every six hours. Alerts report stale backups.
A PostgreSQL backup stays until the next full backup is older than 30 days, at most 38 days. ClickHouse chunks expire after at most 32 days, the other backups after 30 days.
Scripted restore drills: PostgreSQL point-in-time recovery and ClickHouse restore on 22 October 2026, and restore of all datastores, most recently on 2 November 2026, each passed.
Cloudflare protects the public addresses from DDoS attacks.

10. Deletion

Owners and admins erase a Session with all its Runs, transcript, events and artifacts. They cannot erase the System Sessions devboxes starts for a Project’s onboarding and calibration; those never expire and are erased with the Organization.
Chat conversations and their messages stay until the Organization is deleted. When a person deletes their message in Slack, Google Chat, Microsoft Teams or Discord, devboxes deletes its copy. Telegram reports no deletion, so devboxes keeps its copy of a Telegram message.
An owner deletes their Organization once its Sessions are erased.
devboxes deletes an account on request to privacy@devboxes.ai.
Erased data remains in backups until they expire, at most 38 days.
Langfuse traces expire after 30 days. Media that Langfuse extracts from traces is not deleted.
Error reports in Sentry expire after 90 days.

11. Regular review

Every code change is reviewed before it reaches Production.
The restore drills in item 9 are repeated and their results recorded.

12. Processor control

devboxes engages subprocessors under a contract per Art. 28(4) GDPR. The contracts with Monid and with OpenAI for System Sessions are still outstanding (Annex 3).
devboxes is a sole proprietorship with fewer than 20 persons regularly processing personal data, so § 38 BDSG requires no data protection officer. The contact is the owner at privacy@devboxes.ai.

Annex 3: Subprocessors

Part A: devboxes’ subprocessors

Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany: servers for all services and for managed tasks, in Falkenstein, Germany. Data processing agreement in place since 28 October 2026.
Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA: DNS, proxy and DDoS protection on Cloudflare’s global network; storage of Session artifacts and encrypted backups in R2 in the EU jurisdiction; email delivery; read-only operator access. Basis: EU-US Data Privacy Framework, with Standard Contractual Clauses as fallback.
Monid Inc, a Delaware corporation, San Francisco, CA, USA: agents’ web search in managed Sessions, through its search provider TinyFish, in the USA. No agreement with Standard Contractual Clauses is concluded yet.
OpenAI Ireland Ltd, 1st Floor, The Liffey Trust Centre, 117-126 Sheriff Street Upper, Dublin 1, D01 YC43, Ireland, which provides ChatGPT in the EEA, through a ChatGPT account of devboxes: devboxes’ own model for the System Sessions that read a new Project’s repository, in the USA. No agreement with Standard Contractual Clauses is concluded yet.
Google Cloud EMEA Ltd, Dublin, Ireland, and Google LLC, USA: delivery of Google Chat events through Pub/Sub, only when the Organization connects Google Chat, in a Google Cloud region that no storage policy restricts to the EU. Basis: EU-US Data Privacy Framework, Standard Contractual Clauses.

Part B: services the Customer chooses

These services are not devboxes’ subprocessors (§ 5(4)). devboxes transfers data to them when the Organization connects them or a person chooses them:

the model provider the Organization connects
GitHub and GitLab for repositories, GitHub and Google for sign-in
Slack, Google Chat, Microsoft Teams, Linear, Jira, Discord and Telegram
Stripe (Link) as the seller for purchases through Stripe Managed Payments
Exa, which receives an agent’s web searches on a Runner from the Customer’s machine