Data Processing Agreement

This Data Processing Agreement (“DPA”) is between you, the deBub customer (“Customer”), and Appmetize LTD, trading as deBub, company number 12896378, 112c High Street, Hadleigh, Suffolk IP7 5EL, United Kingdom (“deBub”, “we”). It forms part of our Terms of Service and applies automatically whenever we process Customer Personal Data. You do not need to sign anything; if you need a signed copy, email hello@debub.io.

For Customer Personal Data, the Customer is the controller (or a processor acting for its own controller) and deBub is the processor (or sub-processor). For personal data about the Customer itself, such as account and billing data, deBub is a controller and our Privacy & Cookie Policy applies instead.

If this DPA conflicts with the Terms, this DPA applies to the processing of Customer Personal Data. If the standard contractual clauses or the UK transfer terms referred to below apply and conflict with this DPA, they prevail.

• Data Protection Law: the UK GDPR and the Data Protection Act 2018, the EU General Data Protection Regulation 2016/679 (“EU GDPR”) and other data protection laws that apply to the processing.
• Customer Personal Data: personal data that we process on the Customer's behalf while providing the Service, as described in Details of the processing.
• Sub-processor: a third party we engage that processes Customer Personal Data.
• Personal Data Breach, data subject, processing and other terms have the meaning given in Data Protection Law.

Subject matter and purpose. Providing the Service the Customer uses: converting the Customer's Bubble app into a codebase, the hosted preview, the assistant, creating and filling the Customer's own database (“customer database”), and the launch steps, including invitation emails to the Customer's end users.

Nature of the processing. Receiving, reading, transforming, copying, transmitting and temporarily storing data, in particular:

• reading the .bubble export, screenshots of the app's public test version and files the Customer attaches to assistant messages;
• reading the Customer's Bubble data through the Bubble Data API, with a token the Customer provides, and writing it into a Supabase project in the Customer's own Supabase account. The data passes through our processing server in memory; we do not keep a copy in our database;
• creating end-user accounts (without passwords) in the Customer's Supabase project;
• running the generated app in the hosted preview against the Customer's database;
• sending invitation emails to end users through the Customer's own email provider account, only after the Customer has sent a test email and confirmed the number of recipients, and keeping a list of invited users so nobody is invited twice; and
• sending content to AI models to answer the Customer's assistant requests.

Categories of data subjects. End users of the Customer's app, and any other people whose data the Customer has stored in its Bubble app or includes in files it gives us.

Types of personal data. Whatever the Customer has stored in its Bubble app, typically: names, email addresses, user IDs, profile fields, content users created, uploaded files and records linked to users, and timestamps. Bubble does not export user passwords, and we do not process them.

Special category data. We do not ask for special category data (such as health data). If the Customer's app holds it, the Customer is responsible for having a lawful basis to process and move it and must tell us before using the customer database.

Duration. For as long as the Customer uses the Service, and until deletion under Deletion and return.

• The Customer confirms it has a lawful basis for the processing it instructs, including copying end-user data into a new database and emailing end users, and that it has given end users the information required by Data Protection Law.
• The Customer is responsible for its own accounts with Supabase, Vercel, GitHub, its email provider and Bubble, including their security settings, regions and contracts. Those providers are the Customer's own providers, not our sub-processors.
• The Customer should only give us the Bubble Data API token for the app it wants copied, and should delete the token in Bubble when it no longer needs it.

We will:

1. process Customer Personal Data only on the Customer's documented instructions, which are the Terms, this DPA and the Customer's use and settings of the Service, unless the law requires otherwise, in which case we will tell the Customer first unless the law forbids it. We will tell the Customer if we think an instruction breaks Data Protection Law;
2. ensure that anyone we authorise to process Customer Personal Data is bound by confidentiality;
3. implement the technical and organisational measures in Security measures;
4. only use sub-processors as described in Sub-processors;
5. taking into account the nature of the processing, help the Customer respond to requests from data subjects exercising their rights, and pass on any such request we receive directly;
6. help the Customer meet its obligations on security, breach notification, data protection impact assessments and prior consultation, taking into account the information available to us;
7. delete or return Customer Personal Data as described in Deletion and return; and
8. make available the information needed to demonstrate compliance with Article 28 of the UK GDPR and EU GDPR, and allow audits as described in Information and audits.

We do not sell Customer Personal Data and do not use it to train AI models or for our own purposes.

The Customer gives general authorisation for us to use the sub-processors listed on our sub-processors page. We impose data protection obligations on each sub-processor that are substantially the same as those in this DPA, and we remain responsible to the Customer for their performance.

We will tell the Customer by email at least 14 days before a new sub-processor starts processing Customer Personal Data, and update the list. The Customer may object on reasonable data protection grounds within that period. If we cannot reasonably accommodate the objection, the Customer may stop using the affected part of the Service and, for any prepaid subscription period, receive a pro rata refund of fees for the part it can no longer use.

We are established in the United Kingdom. Our processing server is in Germany and our database is in Ireland. Some sub-processors process data in the United States. Customer Personal Data in the Customer's own Supabase project stays in the region the Customer chooses.

• From the EEA to the UK, transfers rely on the European Commission's adequacy decision for the UK.
• From the UK or EEA to a country without adequacy, we rely on the EU standard contractual clauses (Commission Implementing Decision (EU) 2021/914), Module 3 (processor to processor) for onward transfers to sub-processors, together with the UK International Data Transfer Addendum, or the UK International Data Transfer Agreement, issued by the Information Commissioner.
• Where a sub-processor is certified under the EU–US Data Privacy Framework (and its UK extension), we may rely on that certification instead.
• If the Customer is in the EEA and the processing is a restricted transfer to us that is not covered by an adequacy decision, the EU standard contractual clauses, Module 2 (controller to processor) or Module 3 (processor to processor), are incorporated into this DPA by reference, with Ireland as the governing law and courts for those clauses, and the annexes completed with the information in this DPA.

We carry out transfer risk assessments where required and will provide copies of the safeguards on request.

We implement and keep up to date the following measures:

• Encryption in transit. TLS on all connections to debub.io, our processing server and the hosted preview, and on our connections to providers.
• Encryption at rest. Access tokens and keys the Customer gives us (Supabase and GitHub authorisations, the Bubble Data API token, the email provider key) are encrypted in our database with AES-256-GCM, with keys held separately from the data. Our database and storage providers also encrypt data at rest. Tokens needed for a running job are held in a short-lived job store that expires within two hours.
• Sandboxing. Generated code, builds, the hosted preview and the assistant's commands run in isolated sandboxes on our server: separate namespaces per project, a read-only system, only the project's own folder writable, no access to our server's secrets, firewall rules that block our internal network, cloud metadata and outgoing mail ports, and limits on memory, CPU and processes.
• Least privilege. We only request the access we need: our GitHub App only gets the repository it creates, with tokens that last one hour; the Bubble Data API token is only used to read; tables holding tokens can only be read by our server-side code; files are kept in private storage and shared through short-lived signed links; the hosted preview is only reachable with a signed, expiring link.
• Access control. Only the people who need it can access production systems. Our server runs the Service under a dedicated non-root account and is reached with SSH keys only. Provider accounts are protected with strong authentication.
• Data minimisation. We never ask for Bubble login details or end-user passwords. During a data copy, records pass through memory and are not written to our disk or database. We do not log job data, prompts or database records, and our logs redact keys, tokens and email addresses. Server logs are rotated and kept for up to 14 days.
• Confirmation before contact. Invitation emails to end users are only sent after a test email and an explicit confirmation of the number of recipients by the Customer.
• Resilience. Monitoring and alerts on our services; where we keep backups, they are encrypted on our server before they leave it, with the decryption key kept offline.
• Deletion on request. See Deletion and return.

We will notify the Customer without undue delay, and where possible within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. We will give the information the Customer reasonably needs to meet its own notification duties, as it becomes available, and take reasonable steps to contain the breach and reduce its effects. Notifying a breach is not an admission of fault.

The Customer can disconnect its customer database, Supabase account and GitHub account at any time; we then delete the related tokens. The data copied into the Customer's own Supabase project stays there, under the Customer's control.

When the Customer asks us to delete a project or close its account, or when the Service ends, we delete Customer Personal Data we hold within 30 days, unless the law requires us to keep it. Copies in encrypted backups are deleted in the normal backup cycle, within 12 months, and are not used in the meantime except to restore the Service. The Customer can download its code and has its data in its own Supabase project, so return happens through those means.

On request, we will answer reasonable written questions about our processing and security. If that is not enough to show compliance, or a supervisory authority requires it, the Customer may audit our compliance with this DPA, on at least 30 days' notice, no more than once a year, during business hours, in a way that does not disrupt the Service or breach confidentiality owed to other customers, and at the Customer's cost.

Each party's liability under this DPA is subject to the limitations in the Terms, except where Data Protection Law does not allow that. This DPA lasts as long as we process Customer Personal Data. It is governed by the law of England and Wales, except where the standard contractual clauses require another law.