Data Processing Agreement

1. Who this applies to and how it takes effect

This Data Processing Agreement ("DPA") applies where you use Vibely as a business customer and personal data in your Projects is personal data you control. It forms part of our Terms of Service. You do not need to sign it or click anything: where you are a controller of EEA or UK personal data, it applies from the day you start using the Service.

If your procurement process requires a counter-signed copy, email [email protected] and we will execute one against this text. The signed copy adds nothing to what is on this page. This page is the operative version.

This DPA does not apply to a consumer account. If you signed up for yourself and you are not processing anyone else's personal data through Vibely, our Privacy Policy is the document that governs you.

Version 1.0.

2. Definitions

Capitalised terms not defined here — Service, Customer, Customer Content, Generated Output, Credits, Workspace, Project, Published App, Documentation, Order, Beta Feature — have the meaning given at /definitions, which is part of our Terms.

The terms below are the ones this DPA turns on:

• "Personal Data" means any information relating to an identified or identifiable natural person, and includes "personal data" under the GDPR and UK GDPR and "personal data" of a Data Principal under India's Digital Personal Data Protection Act, 2023.
• "Customer Personal Data" means Personal Data contained in Customer Content that Vibely processes on the Customer's documented instructions in the course of providing the Service — including Personal Data of the Customer's own end users that the Customer stores in a Project — and for which the Customer is the controller (or Data Fiduciary) and Vibely the processor (or Data Processor).
• "Service Data" means Personal Data that Vibely processes as controller (Data Fiduciary) in its own right to run and secure the Service: account and profile details, billing and payment records, credit ledger and usage metering, technical and diagnostic logs, support correspondence, and consented product analytics.
• "Sub-processor" means a third party engaged by Vibely to process Customer Personal Data on Vibely's behalf in providing the Service; the current list is published at /subprocessors and is the authoritative public list.
• "Data Protection Law" means, as applicable to the processing: the EU General Data Protection Regulation (2016/679) ("GDPR"), the UK GDPR and Data Protection Act 2018, India's Digital Personal Data Protection Act, 2023 ("DPDP Act"), and the US state privacy laws named in the "US state privacy laws" section below.
• "EU SCCs" means the standard contractual clauses annexed to European Commission Implementing Decision (EU) 2021/914. "UK Addendum" means the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner under s.119A of the Data Protection Act 2018. These are two different instruments and both apply where stated below.

3. Roles: what we are processor for, and what we are controller for

The split matters, because different obligations attach to each side of it.

Vibely is a processor for Customer Personal Data. That is the content of your Projects: prompts, uploaded files, generated source code, project databases, and the source and content of the apps you publish. You decide what goes in and why. We act on your instructions. What a form inside a Published App collects is not in this set: we host the build, not a backend for it, so those submissions go to the service you connected and never reach us.

Vibely is an independent controller for Service Data. Your account and profile, your billing and payment records, the credit ledger and usage metering, technical and diagnostic logs, support correspondence, and consented product analytics are processed for our own purposes — running, billing, securing and supporting the Service. Those purposes are described in our Privacy Policy, not in this DPA, and this DPA does not turn them into processor activities.

Under the DPDP Act, the same split reads as Data Fiduciary for Service Data and Data Processor for Customer Personal Data, and this DPA is the contract required by section 8(2) of that Act.

4. Documented instructions

Your documented instructions are: the Terms of Service, this DPA, the Documentation, and the actions you and your Workspace members take in the product. Within that, we process Customer Personal Data only to do the following:

• Run the agent loop that generates and edits your Project source code.
• Provision and operate the cloud sandbox each Project runs in, and its dev server.
• Store your Projects — source tree, message and version history, snapshots, uploaded files — in our database and object storage.
• Serve previews and Published Apps on vibelyagent.com subdomains and on custom domains you connect.
• Build and submit native mobile apps through the EAS pipeline to your own Apple and Google developer accounts, when you use that feature.
• Operate connectors against the third-party credentials you authorise.
• Meter Credits, bill you, and provide support you request.
• Detect, prevent and respond to security incidents, abuse and fraud.

5. When we will not follow an instruction

We will tell you if we believe an instruction of yours infringes Data Protection Law, and we may pause that processing until it is resolved. If law applying to us requires us to process Customer Personal Data beyond your instructions, we will tell you before we do it unless that law forbids the notice on important grounds of public interest.

6. What you are responsible for

You are the controller, so these are yours:

• Having a lawful basis for everything you put into Vibely, and giving your own end users the notices they are owed.
• The accuracy of Customer Personal Data, and the legality of collecting it.
• Configuring your Projects and Published Apps appropriately for the data they hold — including who can reach a preview or a Published App. Private, workspace-only and group-only publishing is a Business-plan capability; on Free and Pro, published apps are public.
• Managing your Workspace members and their roles (Owner, Admin, Editor, Viewer), and removing access when someone leaves.
• Keeping special category data and other high-risk data out of Vibely unless you have carried out your own assessment and are satisfied the Service is appropriate for it.
• Responding to your own end users' requests. They are your data subjects, not ours.

7. Our obligations under Article 28(3)

This section maps to GDPR Article 28(3)(a) to (h) in order, so a reviewer can tick it off against the text of the Regulation.

• (a) We process Customer Personal Data only on your documented instructions, including on transfers, except where law applying to us requires otherwise — in which case we tell you first unless that law forbids it.
• (b) Everyone we authorise to process Customer Personal Data is bound by a confidentiality obligation — see "Confidentiality of our people" below.
• (c) We apply the technical and organisational measures set out in Annex 2, in accordance with Article 32.
• (d) We engage Sub-processors only on the terms in "Sub-processors" below.
• (e) We assist you, by appropriate technical and organisational measures and so far as possible, to respond to data subject requests — see "Data subject requests".
• (f) We assist you with Articles 32 to 36 — security, breach notification to a supervisory authority and to data subjects, data protection impact assessments, and prior consultation — taking into account the nature of processing and the information available to us.
• (g) At your choice, we delete or return Customer Personal Data at the end of the Service, and delete existing copies unless law requires us to keep them — see "Deletion and return".
• (h) We make available the information needed to demonstrate compliance with Article 28, and allow and contribute to audits, on the terms in "Audit rights".

8. Confidentiality of our people

Access to Customer Personal Data is limited to the people who need it to operate or support the Service. They are bound by written confidentiality obligations that survive the end of their engagement, and the obligation applies equally to employees and to contractors. Access to production systems is limited to the people who operate the Service, over cloud accounts protected by multi-factor authentication.

9. Security measures

Data is encrypted in transit over HTTPS/TLS, and at rest by the default storage encryption our cloud providers apply. Access to production systems is limited to the small number of people who operate the Service, over cloud accounts protected by multi-factor authentication. Connector credentials and tokens are stored encrypted with per-tenant scoping. Workspaces and Projects are logically separated, with row-level security on shared databases. Generated code executes in an isolated cloud sandbox with its own filesystem, not on shared application infrastructure.

Annex 2 sets the measures out in full.

We do not hold a SOC 2 report or an ISO 27001 certificate, and no audit against either framework is under way. We are not naming a date for one. We will say so here and at /security on the day that changes. Nothing in this DPA should be read as a representation that we hold either today.

10. Sub-processors

You give us general authorisation to engage Sub-processors. The current list is published at /subprocessors, with each vendor's purpose and location. That page is the notice: it carries a dated last-reviewed line, and we update the date whenever the list changes. We post a change there at least 30 days before a new Sub-processor begins processing Customer Personal Data, and we email Workspace owners at the same time. If you would rather be notified by email only, tell us at [email protected] and we will add your address to the list.

Each Sub-processor is engaged under that vendor's own published data processing terms where it offers them. We do not hold a negotiated agreement with every vendor, and we do not claim that every vendor's terms are as protective as this DPA — for some they are not, and for some we have not verified it. We remain liable to you for a Sub-processor's performance as if the processing were our own. The current position, vendor by vendor, is available from [email protected].

You may object to a new Sub-processor on reasonable data protection grounds by emailing [email protected] within 20 business days of the notice. We will work with you to address the objection. If we cannot, you may terminate the affected Service by written notice and we will refund the unused prepaid portion of your fees on a pro-rata basis. That is your sole remedy for an objection under this section, and it is the only refund this DPA creates — everything else stays as set out under “Refunds and cancellation” in the Terms of Service at /terms-of-service.

11. Data subject requests

If a data subject contacts us directly about Customer Personal Data, we will not respond on the substance. We will tell them to contact you, and tell you within 5 business days at the email address on the Workspace owner's account. For requests you receive yourself, the product is the first line of assistance: you can export, edit and delete Project data directly. Where the product does not reach, email [email protected] and we will help you locate, correct, export or delete the data at no additional charge, unless the requests become manifestly excessive in volume.

12. Personal data breach notification

If we become aware of a personal data breach affecting Customer Personal Data, we will notify you without undue delay and in any event within 72 hours of becoming aware of it. Notice goes by email to the Workspace owner's account address; an in-product notice is a secondary channel only, because it depends on you signing in.

The notice will describe the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures we have taken or propose to take — to the extent we know them at the time. Where we cannot give all of it at once, we will give what we have and follow up.

We will help you meet your own Article 33 and 34 obligations. Notifying a supervisory authority or your data subjects remains your decision and your duty, not ours. Separately, we may have our own duties as an Indian entity — notification to the Data Protection Board of India and to affected Data Principals under the DPDP Act, and reporting of specified cyber incidents to CERT-In — and this DPA does not limit those.

13. Assistance with impact assessments

If you need to carry out a data protection impact assessment or a prior consultation with a supervisory authority under Articles 35 and 36, we will give you the information about our processing that you reasonably need and that we hold. Annex 1, Annex 2 and /subprocessors are the starting point and usually answer most of a DPIA questionnaire on their own. We do not complete the assessment for you.

14. Deletion and return

You can delete a Project at any time. Deletion is immediate and irreversible: the published site is torn down, the storage bucket and uploaded files are purged, and the Project record is removed in the same operation. There is no grace period and no restore, so export anything you need before deleting.

When your account closes, we delete your personal data within 30 days, except where retention is required by law (for example tax records and dispute resolution obligations). Before that, you can export your Projects through the product; if you need us to return data in another form, ask within those 30 days.

Copies of deleted data may persist in encrypted backups for a limited period after the purge, and are not restored into the live Service. We do not currently publish a backup retention period.

15. Audit rights

Article 28(3)(h) audits work as follows, and this is the whole of what we offer:

• Once a year, you may send a written security and data protection questionnaire to [email protected]. We answer within 30 days.
• We do not hold a SOC 2 report, an ISO 27001 certificate, or any other third-party audit report covering the Service today, so the questionnaire above is what we can offer. If that ever changes we will share the report under NDA in place of answering one.
• An on-site or hands-on audit is available only where a supervisory authority requires one or where a documented security incident makes it necessary, on 30 days' written notice, during business hours, no more than once a year, under NDA, without access to other customers' data or to our production systems, and at your cost.

16. International transfers

Say the awkward part first: Mana Intelligence Private Limited is incorporated in India, and India has no adequacy decision from the European Commission or the UK government. We are the data importer, not an exporter.

So the transfer from you to us is the leg that needs a mechanism. Where you are established in the EEA, or your transfer is otherwise subject to Chapter V of the GDPR, the EU SCCs are incorporated into this DPA and the parties are deemed to have entered into them: Module Two (controller to processor), with you as data exporter and Mana Intelligence Private Limited as data importer. Module Three (processor to processor) applies instead, with the same parties, where you are yourself a processor acting for your own customer. Annex 1 and Annex 2 of this page serve as Annexes I and II of the EU SCCs. The optional docking clause applies; the Clause 17 governing law and the Clause 18 forum are those of Ireland, and nothing in the "Precedence" section below changes that — the EU SCCs are not subject to the governing law of our Terms.

For the UK, the same EU SCCs apply as amended by the UK Addendum, with Tables 1 to 4 of the Addendum completed by Annex 1 of this page and the importer's ending option not selected. The UK Addendum is a different instrument from the standalone IDTA, and it is the Addendum that applies here.

Our own transfers onward — to AWS us-east-1 (United States), where application and sandbox infrastructure runs; to Supabase in ap-southeast-1 (Singapore), where the primary database, authentication and file storage run; and to the other Sub-processors at /subprocessors, several of which are in the United States and two of which are in China — are onward transfers under Clause 8.8 of the EU SCCs. We make them on the terms that clause permits and on each vendor's own data processing terms, which are not uniform. Where a particular onward transfer needs a named mechanism, ask us before you rely on it.

We do not claim a specific transfer mechanism for every Sub-processor. In particular, we do not hold European Commission SCCs with our China-based inference providers. If you require a named mechanism for a particular vendor before you use it, contact [email protected] first.

A transfer impact assessment covering the India leg and our onward transfers is available on request from [email protected]. We do not operate an EU or India hosting region today and we are not naming a date for one.

17. AI models and training

Vibely does not use your prompts, code, or project data to train models. Product-improvement data collection is off by default on every plan and collects usage metrics only — model, provider, token counts and cost — never prompts or code. The control is at Settings → Privacy & security → Data protection. Turning it on is a decision you make; it does not change what this section says about Customer Personal Data, because that telemetry contains none.

Vibely routes prompts to third-party AI model providers. OpenAI, Anthropic, Google and Fireworks each state in their own published API terms that API inputs are not used to train their models — that is their published commitment, not one we have negotiated or can audit. DeepSeek and Moonshot AI are used under their standard terms, which permit using inputs to improve their models, and process data in China. Providers receive only the input necessary to fulfil a turn and standard request metadata. The current list, with each provider's location, is at /subprocessors.

Generated Output is Customer Content. As between you and us it is yours, on the terms set out under "Your content and what you own" at /terms-of-service: we assign whatever rights we hold in it, and we do not warrant that it is accurate, original, free of third-party rights, or fit for any particular purpose. It remains subject to third-party rights in the underlying AI models, their training data, and any third-party or open-source component in it. If you need a route that avoids a particular provider, ask us at [email protected] before you rely on one — model routing is configured for the platform, not per Workspace.

18. US state privacy laws

Where you are subject to the California Consumer Privacy Act as amended, or to the comparable laws of Colorado, Connecticut, Virginia, Texas or another US state, Vibely is a service provider or processor and you are the business or controller. For Customer Personal Data we commit that:

• We do not sell it and we do not share it for cross-context behavioural advertising. There is no monetary or other valuable consideration involved, in either direction.
• We do not retain, use or disclose it for any purpose other than the business purposes set out in "Documented instructions", including not for our own commercial purposes.
• We do not combine it with personal information we receive from another source, except as a service provider is permitted to.
• We will tell you if we determine we can no longer meet these obligations, and you may stop and remediate the processing.
• We flow the same restrictions down to each Sub-processor by contract.
• We certify that we understand these restrictions and will comply with them.

19. Liability and precedence

This DPA forms part of the Terms of Service. Where this DPA and the Terms conflict, this DPA prevails — but only on data protection subject matter. On everything else the Terms govern, unchanged.

Two clauses of the Terms survive this DPA expressly and are not displaced by it. First, the limitation of liability: "The aggregate liability of Mana Intelligence Private Limited — us, the company that operates Vibely — arising out of or relating to the service will not exceed the greater of (a) the amounts you paid us in the 6 months before the date the claim first arose, or (b) USD 100." and "For claims related to our breach of confidentiality or data protection obligations, the liability cap is 2× the amount above." Each party's total liability under this DPA counts toward those caps; it does not sit on top of them. Second, governing law: "These Terms are governed by the laws of India, without regard to conflict-of-law principles. The courts at Hyderabad, Rangareddy district, Telangana, India have exclusive jurisdiction over any dispute arising out of or relating to these Terms or the service, and both of us submit to that jurisdiction."

The EU SCCs and the UK Addendum are the exception to both. Where they apply, their own governing law and forum clauses control, and any term of this DPA or the Terms that conflicts with them gives way. Nothing here limits a data subject's rights against either party under Article 82 of the GDPR.

Where an executed agreement between us — an Order or a counter-signed copy of this DPA with negotiated changes — says something different, that document governs for the customer it names.

20. Annex 1, Part A — Parties, roles and contact points

Annexes 1 and 2 of this page serve as Annexes I and II of the EU SCCs and complete Tables 1 to 3 of the UK Addendum.

• Data importer / processor: Mana Intelligence Private Limited, incorporated in India, operating the Vibely platform at vibely.sh and api.vibely.sh. Role: processor (Module Two) or sub-processor (Module Three).
• Data importer contact point: [email protected]. Questions, objections, data subject matters, transfer impact assessments and counter-signature requests all go to this address.
• Data exporter / controller: the Customer — the person or entity that creates the Workspace and agrees to the Terms. Role: controller (Module Two) or processor acting for its own customer (Module Three).
• Data exporter contact point: the email address on the Workspace owner's account, unless you give us a different one in writing at [email protected]. Keep it current — it is where breach notices go.
• Activities relevant to the transfer: providing the Service as described in "Documented instructions".
• Frequency: continuous, for as long as the Workspace is active.
• We have not appointed a representative under Article 27 of the GDPR or under the UK GDPR, and we do not have a statutory Data Protection Officer. Data subjects in the EEA and the UK can reach us at [email protected], and may lodge a complaint with their local data protection supervisory authority. For India, the Grievance Officer contact is published in our Privacy Policy.

21. Annex 1, Part B — Description of the processing

Categories of data subjects:

• The Customer's own personnel — Workspace members with Owner, Admin, Editor or Viewer roles, and anyone whose details appear in prompts, files or project content they supply.
• End users of the Customer's web Published Apps, on vibelyagent.com subdomains and on connected custom domains.
• End users of the Customer's native mobile Published Apps — iOS and Android builds produced through the EAS pipeline and submitted to the Apple App Store and Google Play under the Customer's own developer account.
• People who submit a form to a Published App.
• The Customer's own customers, contacts and records, where those appear in a Project database, an uploaded file, or data retrieved through a connector the Customer authorises.
• Any other individual the Customer chooses to include in Customer Content. The Customer decides; we do not select the categories.

22. Annex 1, Part B — Categories of personal data

What is in scope depends on what the Customer puts in. In practice it is:

• Identifiers and contact details appearing in prompts, uploaded files, project source code, project databases and generated content.
• Content the Customer's own end users put into a Published App and the Customer routes back into a Vibely Project. Submissions a Published App sends straight to a service the Customer connected are outside this DPA: we never receive them.
• Account identifiers and authentication data belonging to the Customer's own end users, where the Customer's app stores them.
• OAuth access tokens for third-party accounts the Customer authorises through connectors, and data retrieved through those connectors.
• Technical data generated by running the Service on the Customer's behalf: sandbox and build logs, deployment records, and error traces that may incidentally contain personal data the Customer placed in a Project.

23. Annex 1, Part B — Special categories, purposes and retention

Special categories of personal data: none are requested, required or expected. The Service is not designed for special category data as defined in Article 9, or for criminal conviction data under Article 10. If the Customer chooses to process it anyway, the Customer is responsible for the assessment that makes it lawful, and must apply the additional restrictions and safeguards its own assessment calls for. We apply no special handling beyond the measures in Annex 2.

Nature and purpose of processing: hosting, storing, transmitting, executing and generating Customer Content in order to provide the Service — running the agent loop, operating sandboxes, storing Projects, serving previews and Published Apps, building native mobile apps, operating connectors, metering and billing, providing support, and securing the platform against abuse.

Retention. The periods below are the real ones. Each is applied by an automated nightly purge.

• Active Projects: retained for as long as the Workspace is active. The Customer can delete a Project at any time.
• Deleted Projects: purged when you delete them. The published site is torn down, the storage prefix and the uploaded files are purged and the record is removed in one operation. There is no grace period and no restore, which is what "Deletion and return" above says and what the product does. The only 30-day window in this area is the one that applies to a Project we ourselves mark for removal in an administrative action.
• Submissions to forms on vibely.sh itself, such as our contact and sales forms: 730 days (2 years), then purged. Forms inside a Customer's Published App are not covered: we host the build, not a backend, so those submissions never reach us and we retain none of them.
• Audit logs: 91 days (13 weeks), then purged.
• Client error reports — browser failure beacons: 30 days, then purged.
• On account closure: personal data deleted within 30 days, except where retention is required by law. This matches what we publish in our Privacy Policy.
• Paused sandboxes are discarded after 72 hours of inactivity; a Project recovers from a snapshot or from its stored files.
• Sub-processor retention is governed by each vendor's own terms. See /subprocessors.

24. Annex 2 — Technical and organisational measures

These are the measures we apply, and they serve as Annex II of the EU SCCs.

• Encryption. HTTPS/TLS in transit. At rest, the default storage encryption our cloud providers apply to managed storage. We have not independently verified the cipher or key management each provider uses. Connector credentials and tokens are stored encrypted with per-tenant scoping.
• Access control. Access to production systems is limited to the people who operate the Service, over cloud accounts protected by multi-factor authentication, and the provider's own access logs record it. Access is granted on a need-to-know basis and reviewed when a role changes. Secrets and configuration live in AWS Systems Manager Parameter Store, not in code or in a repository.
• Tenant isolation. Workspaces and Projects are logically separated, with row-level security on shared databases. Generated code executes in an isolated cloud sandbox with its own filesystem, not on shared application infrastructure.
• Access control for the Customer. Workspace roles — Owner, Admin, Editor, Viewer — plus group-based publishing access and, on the Business plan, private, workspace-only and group-only visibility for Published Apps. SSO via SAML or Google Workspace and SCIM provisioning are available on the Business plan.
• Logging and audit. Workspace activity is recorded in an audit log retained for 91 days, available on the Business plan. Application errors are captured in our observability tooling.
• Pseudonymisation and minimisation. Product-improvement telemetry is off by default and carries usage metrics only — model, provider, token counts, cost — never prompts or code.
• Resilience and recovery. Data is held in managed infrastructure with the provider's own backups: AWS us-east-1 (United States) for application and sandbox infrastructure, and Supabase in ap-southeast-1 (Singapore) for the primary database, authentication and file storage. Projects recover from snapshots or stored files when a sandbox is recycled.
• Personnel. Written confidentiality obligations that survive the end of engagement, applying to employees and contractors alike.
• Sub-processor governance. Each vendor's own published data processing terms where it offers them — not a negotiated agreement with every vendor, and not a claim that every vendor's terms match this DPA; the public list at /subprocessors, with 30 days' notice before a new Sub-processor begins processing.
• Vulnerability handling. A published responsible disclosure process at /responsible-disclosure, with reports to [email protected].
• Certification status. We do not hold a SOC 2 report or an ISO 27001 certificate, and no audit against either framework is under way. /security carries the current position.

25. Contact

Questions about this DPA, a counter-signature request, a Sub-processor objection, a transfer impact assessment or an audit questionnaire all go to [email protected]. Vibely is operated by Mana Intelligence Private Limited, incorporated in India.