Legal

Data processing agreement

Last updated Oct 5, 2026

Draft for legal review

This agreement awaits legal review and is not yet offered for signature. It shows the terms we intend to offer. To be told when it is ready, write to legal@deployyourcode.com.

These are the terms on which we intend to process personal data for you. Questions about your own personal data go to privacy@deployyourcode.com.

1. Who this applies to

This Data Processing Agreement (the "DPA") forms part of the Terms of Service between Commonman LLC ("we", "us") and the customer that accepts it ("you"). It applies when we process personal data on your behalf in providing DeployYourCode (the "Service").

"Data protection law" means the laws that apply to that processing, including Regulation (EU) 2016/679 and its UK equivalent where they apply. "Personal data", "processing", "controller", "processor", "data subject" and "personal data breach" have the meanings those laws give them. "Customer personal data" is personal data we process on your behalf: what your apps, databases and builds hold, and what your team gives us to provide the Service.

2. Roles

You are the controller of customer personal data, or a processor acting for your own customer. We are your processor, or your subprocessor. Annex I describes the processing.

We are the controller of the account and billing data we need to run our own business, such as who your team members are and what you owe. Our Privacy Policy covers that data.

3. Processing on your instructions

We process customer personal data only to provide the Service and only on your documented instructions. Your instructions are the Terms of Service, this DPA, how you configure and use the Service, and anything further we agree in writing. If we believe an instruction breaks data protection law, we will tell you.

Our staff and contractors who can reach customer personal data are bound to keep it confidential.

4. Security

We maintain the technical and organisational measures in Annex II, and may improve them. We will not reduce the overall level of protection they give during the term of the Terms of Service.

5. Subprocessors

You authorize us to use the subprocessors listed in Annex III. We bind each to data protection obligations no less protective than this DPA, and we remain responsible to you for their work.

Before a new subprocessor starts to process customer personal data, we will update the subprocessor list and email the owners of each organization at least 14 days in advance. You may object on reasonable data protection grounds; if we cannot address the objection, you may end the affected part of the Service and we will refund any fees you prepaid for it.

6. Helping you meet your obligations

The Service lets an organization owner export the organization's data and lets a person delete their account. Where those features are not enough, we will help you, at reasonable cost, to answer data subject requests, to carry out data protection impact assessments, and to consult a supervisory authority, taking into account the nature of the processing and the information available to us.

If we receive a request from a data subject about customer personal data, we will pass it to you and will not answer it ourselves unless you ask us to or the law requires it.

7. Personal data breaches

We will tell you without undue delay after we become aware of a personal data breach affecting customer personal data. We will give you what we know about its nature, the data and data subjects likely affected, its likely consequences and what we are doing about it, and add to that as we learn more. Telling you is not an admission of fault.

8. Information and audits

We will make available the information reasonably needed to show that we meet this DPA, including a description of our controls. If that information is not enough, or a supervisory authority requires it, you may audit our compliance once a year, at your own cost, on at least 30 days' notice, during business hours, and without access to other customers' data. You will keep what you learn confidential.

9. International transfers

Our providers process data in the United States and elsewhere. Where customer personal data leaves the European Economic Area, the United Kingdom or Switzerland for a country without an adequacy decision, the standard contractual clauses adopted by the European Commission (Decision 2021/914) apply — Module Two where you are a controller and Module Three where you are a processor — with the UK's International Data Transfer Addendum and the Swiss amendments where those laws apply. They form part of this DPA, and they prevail if they conflict with it.

10. Deleting customer personal data

When the Terms of Service end, or when you delete an organization, we delete the customer personal data we hold for it, except where the law requires us to keep it. Copies in backups, restore points and archives are deleted on their own schedules, which our Privacy Policy states, and are not used for anything else in the meantime. Before deleting an organization, an owner can export its data.

11. Liability and precedence

Each party's liability under this DPA is subject to the limits in the Terms of Service. If this DPA conflicts with the Terms of Service on the processing of personal data, this DPA prevails.

Annex I — The processing

Subject matter: Building, deploying, running, storing and backing up your applications and databases.
Duration: The term of the Terms of Service, then until deletion as described above.
Nature and purpose: Hosting, storage, backup, monitoring, logging, support and billing, to provide the Service.
Data subjects: The users of your applications, and the members of your organization.
Personal data: Whatever your applications and databases hold, which you decide; and your team members' names, email addresses, and the network addresses and browser details in our logs.
Special categories: None intended. Our Terms of Service do not allow health information on the Service, and you should not send us other special categories of personal data.
Frequency: Continuous, for as long as your applications run.

Annex II — Security measures

The measures in place today, as listed on our security page. A measure a provider operates is described under that provider's name.

Network and edge

Every public app address is served over HTTPS, and plain HTTP is redirected to it.
Fly.io, which runs every app on the platform, works with upstream traffic providers to mitigate DDoS attacks at the network level.
A service can be private: it gets no public address at all, and is reachable only over the platform's private network.
Our own site sends a Content Security Policy and HSTS, and every deploy of it checks that both are present.

Your apps and data

Each organization's data is kept apart in the application, and every table in the database carries row-level security policies that are checked on every deploy of the platform.
Each environment is created on a private network of its own, shared only by that environment's services and databases.
Managed databases never get a public address, and each one has its own long random password.
Environment variables and database passwords are encrypted at rest with AES-256-GCM, each bound to the record it belongs to, and the product never shows them back.
You can keep a secret in your own vault — Azure Key Vault, AWS Secrets Manager, Google Secret Manager or HashiCorp Vault — and we store only a reference to it, read when your app deploys.
Fly.io encrypts the volumes your databases live on with Linux LUKS block-storage encryption.
Supabase, which hosts our own database, encrypts it at rest with AES-256 and in transit with TLS.
Managed databases keep daily restore points for as many days as your plan includes, up to 60, and roll back in place — and a rollback can itself be undone.
A release runs the exact image its build produced: new builds are pinned by content digest, and an image whose tag moved is refused.
Builds run without the platform's credentials, and fetch your source with a read-only token for that one repository, revoked as soon as the download finishes.
Build caches are never shared between builds: each Dockerfile build gets its own BuildKit instance, and other builds use cache keys unique to the build.

Your team's access

Two-factor authentication is required for organization owners and admins, and for our own staff accounts.
Signing in with GitHub or Google asks for the second factor too.
Passkeys and authenticator apps work on every account.
Custom roles grant members exactly the permissions they need; a member without a role holds none.
API keys are scoped to what they may do, can expire, and are rate-limited.
Security-relevant actions in your organization are recorded in its audit log and kept for 12 months.
A record in your organization's audit log each time our staff sign in as one of your users.
An organization-wide requirement for every member to use two-factor authentication.
Exporting the audit log, and streaming it to an endpoint of yours.

Testing and response

Automated checks of access control, encryption and isolation run before every deploy of the platform.
Adversarial probes test tenant isolation, cryptography, server-side request forgery, authorization and resilience against our own code.
Our repository is scanned for known-vulnerable dependencies and leaked secrets on every push and pull request, and weekly.
A vulnerability disclosure policy, with a safe harbour for good-faith research, and a security.txt.
Anyone can report abuse of an app we host, through a form or by email.
A written procedure for responding to a security incident and telling the customers it affects.

Annex III — Subprocessors

The providers on our subprocessor list, which says what each one does and receives: Fly.io, Supabase, Cloudflare, Tigris Data, Stripe, Resend, Google, Anthropic, GitHub, Sentry.