Data processing agreement

1. What this agreement is, and when it applies#

This Data Processing Agreement (“DPA”) applies whenever Gheima processes personal data on your behalf, that is, whenever your application, your managed database or your object storage holds data about people. It forms part of the Terms of Service and is entered into by the same parties.

Two roles are in play at once, and confusing them is the usual source of trouble:

• For the personal data inside your workloads (your users, your customers, your rows and your files), you are the controller and Gheima is the processor. This DPA governs that.
• For the data about your Gheima account (your email, your billing details, your audit trail), Gheima is the controller. The Privacy Policy governs that, not this DPA.

2. Subject matter, duration, nature and purpose#

3. Processing only on your instructions#

We process the personal data in your workloads only to provide the platform, and only as instructed by you. Your configuration (which region you place a resource in, what you deploy, what you store) is your instruction. We will tell you if an instruction appears to breach applicable data-protection law, and we may refuse it.

If a law requires us to process or disclose your data, we will tell you before doing so unless that law forbids the notice. We do not access the contents of your databases, buckets or containers in the ordinary course of running the platform.

4. Confidentiality#

Everyone at Gheima with access to production is bound to confidentiality, and access is granted on the basis of what a role actually needs. Administrative actions, including any staff impersonation of an account for support, are written to the audit log.

5. Security measures#

The technical and organisational measures we apply are, in summary:

• Encryption in transit for all external traffic, with automatically issued and renewed certificates.
• Encryption at rest, AES-256-GCM under a per-account derived key, for environment variables, managed-database credentials, object-storage keys, connected Git tokens and two-factor secrets.
• Tenant isolation enforced as a column on every resource and a scope on every query, with cross-account and cross-region access refused at the boundary.
• Per-tenant network segmentation: managed databases are reachable on a private overlay and publish no ports to the internet.
• Builds executed in an isolated rootless build daemon, separate from cluster management.
• An append-only audit log enforced by a database trigger, with scheduled minimisation of the identifying fields.
• Two-factor authentication available to every user and requirable on team accounts.
• Automated backups, stored encrypted, with a scheduled restore drill that actually restores: a backup nobody has restored is a hypothesis.

We review these measures as the platform changes, and we will not lower them below the level described here for the duration of this DPA.

6. Sub-processors#

You give us general authorisation to use sub-processors. The current list, with each one's purpose and location, is published on our Sub-processors page and forms part of this DPA.

We will publish any addition or replacement on that page and notify account holders by email at least thirty days before the new sub-processor starts processing. If you object on reasonable data-protection grounds within that period, we will work with you to find an alternative; if there is none, you may terminate the affected service and we will refund the unused part of the period. Every sub-processor is bound by terms no less protective than these.

7. Helping you answer data subjects#

Requests from your users come to you, not to us. We have no relationship with them. Where you need our help to answer one, the platform gives you direct access to the data: your managed database is yours to query, your buckets are yours to list, and the account export produces your account-level records as JSON. If a request needs something those do not reach, write to hello@gheima.ma and we will assist at no charge.

Your own declarations to the CNDP. As controller, you declare your own processing to the CNDP (loi 09-08, art. 12), and any transfer of that data abroad (art. 43 and 44). On request we give you what those forms ask about the hosting: the region and country each resource sits in, our sub-processors and where they are, and the security measures in section 5.

If you are not established in Morocco. Loi 09-08 (art. 2) requires a controller established outside Morocco that processes data using means located in Morocco, such as a resource in the ma-1 region, to designate a representative established in Morocco. That obligation is yours; Gheima cannot act as your representative.

8. Personal data breaches#

If we become aware of a breach affecting personal data we process for you, we will notify you without undue delay and in any event within seventy-two hours of becoming aware, with what we know at the time: what happened, which data and roughly how many records are involved, the likely consequences, and what we are doing about it. We will keep updating you as we learn more rather than waiting until the picture is complete. Notifying your supervisory authority and your users, where that is required, is your decision as controller; we will give you what you need to make it.

9. Deletion and return#

Deleting a resource in the dashboard deprovisions the real thing, not just its record: the managed database role and database, the object-storage identity, the container and its volume. Closing an account soft-deletes it and destroys live credentials at once, holds it for a thirty-day restore window, and then hard-purges everything: managed databases, buckets, search and queue instances, volumes and the account record itself.

Export your data before you close the account; after the grace window it is gone. Encrypted backups may retain deleted data for up to fourteen further days before they age out, and we will not claim otherwise. At any point during the relationship you may ask us in writing to delete or return the data we process for you, and we will do so unless a law requires us to keep it.

10. Audits#

On reasonable written notice, and no more than once a year unless a supervisory authority or a breach makes more necessary, we will give you the information you need to demonstrate compliance with this DPA, and we will answer a security questionnaire. Any on-site or hands-on audit is at your cost, scheduled so it does not affect other customers, and conducted by someone bound to confidentiality.

11. International transfers#

Transfers to the European Union rely on the CNDP's list of adequate states (loi 09-08 art. 43; délibération 236-2015). Transfers to the United States (Resend, GitHub, Cloudflare) rely on art. 44 of loi 09-08: they are needed to perform our contract with you. Transfers to Google (Gemini API) happen only while our optional AI features are switched on, rely on the same article, and are declared to the CNDP before those features are switched on; full build logs from the ma-1 region never go to it. New resources on every plan are placed in ma-1 (Casablanca, Morocco) by default. Section 12 states exactly where data sits for each region we operate.

12. Data residency: exactly what it covers#

This is the section to read before you rely on the residency commitment, and it is written to be checkable rather than impressive.

The residency commitment belongs to the ma-1 region, in Casablanca, where every plan places new resources. For a resource in ma-1, these stay inside Morocco, on that region’s own hardware:

• the application containers themselves, pinned to nodes in the region;
• managed databases (Postgres, MySQL, MongoDB and Redis) and everything in them;
• object-storage buckets and their contents;
• snapshots and database dumps;
• build inputs, build logs and deployment logs;
• container logs and metrics, collected by the region's own logging and monitoring stack;
• container images, held in the region's own registry;
• backups, taken in the region and copied to a second location inside the same country.

These do not, today. They live in the control plane, which serves every account from one place, in Casablanca (see below):

• resource metadata: the names of your services, databases, domains and projects, and the repository URLs they build from;
• your environment variables, which are stored as ciphertext in the control database and are decryptable there;
• the audit log of actions taken in the dashboard and API;
• billing records: plans, invoices, usage meters;
• pseudonymised website-analytics rows: visitor hash, path, referring host, country, status, with no raw IP and no user agent;
• the dashboard process itself, which means that when you type a secret into the dashboard, it passes through the control plane in plaintext at that moment before being encrypted and stored.

Since 21 September 2026 the control plane runs in Casablanca, Morocco, in the ma-1 region, and its database and backups are stored there. The accurate statement of what residency gives you is therefore: your customer data at rest stays in its region's country, and the metadata about it and the operator interface are in Morocco. Since 22 September 2026 the key limit we previously recorded here is closed: the secrets belonging to a single workload (service environment variables, managed-database passwords and connection strings, and object-storage keys) are encrypted under a key held only by the region hosting that workload and by the control plane in Morocco. Our infrastructure in the European Union can no longer decrypt the configuration of a workload hosted elsewhere. What remains, stated plainly: secrets that belong to your account rather than to one workload (shared environment groups, Git provider tokens, notification and log-drain secrets, email signing keys, and search and queue credentials) remain under a single key held by every region's workers, because any region may run a job for your account. We will update this section, with a new version number, if that changes.

Two further limits, stated plainly. Job payloads for deployment and provisioning pass through the central queue; we have checked that they carry identifiers only: no secrets, no customer data. And a region is claimed as being in a country on the basis of our provider's own statement about where that region is; where we do not yet hold that statement in writing, the region carries no residency claim at all and is offered only as a preview.

13. Order of precedence, and liability#

Where this DPA and the Terms of Service conflict on the processing of personal data, this DPA wins. Everything else in the Terms, including the limitations of liability, applies to this DPA as if set out in it.

14. Signing it#

This DPA applies automatically to every account; you do not need to sign anything for it to be in force. If your procurement process needs a countersigned copy, or your own DPA template reviewed, write to hello@gheima.ma.