Privacy Policy
What personal data we hold, why we hold it, where it sits, how long it stays and what you can ask us to do with it.
Version 0.1 · Last updated September 19, 2026
These documents are a first published draft. They describe what the platform actually does today, but they have not yet been reviewed by a lawyer. We are publishing them because billing customers with no terms at all is worse; expect the wording to change once counsel has been through it.
1. Scope, and who is responsible#
This policy covers the personal data Gheima handles as a controller: the data about you and your team that exists because you have a Gheima account. Gheima is operated by Omar BAABOUJ, an auto-entrepreneur registered in Morocco under Loi 114-13 in the Registre National de l'Auto-Entrepreneur, ICE / RNAE no. 003706803000143. An auto-entrepreneur is a natural person, not a company, and is not entered in the Registre de Commerce — so there is no RC number to quote. A postal address for formal notice is available on request at hello@gheima.ma.
It does not cover personal data inside your own application — the rows in your managed database, the files in your buckets, the users of the service you deploy. For that data you are the controller and we are your processor, on the terms in the Data Processing Agreement.
2. What we collect#
| Data | Where it comes from |
|---|---|
| Email address, name, avatar | You, or the Git or SSO provider you sign in with. The email is your login identifier. |
| Git identity — GitHub or GitLab username and id, and an access token | The connection you authorise, so we can read the repositories you select and report build status back |
| Two-factor secret and recovery codes | Generated when you enable two-factor authentication |
| Billing email, invoices, payment status | You, and our payment provider. We never receive or store your card number. |
| Sessions | Created when you sign in. Each records an IP address and a user-agent string so you can review and revoke your own sessions. |
| Audit log | Your actions in the dashboard and API: what was done, to which resource, when, from which IP and user agent |
| Sent-email log | Our own record of the transactional email we sent you: recipient, subject, delivery status |
| Deployment records | Your Git history — commit hash, message and author, as the repository reports them |
| Website analytics | Visits to your deployed sites, if you leave analytics on. See section 6. |
| Support correspondence | What you write to us |
We do not run advertising trackers, we do not sell personal data, and we do not use your code or your data to train machine-learning models.
3. Why we hold it, and on what basis#
| Purpose | Basis |
|---|---|
| Creating your account, running your services, taking payment | Performance of our contract with you |
| Keeping the platform secure: audit trail, abuse detection, rate limiting | Our legitimate interest in a platform that is not used to harm people, balanced against your interest in not being over-monitored — which is why audit records are minimised over time rather than kept whole forever |
| Invoices, tax records | A legal obligation |
| Service notices — incidents, billing, security | Performance of our contract; you cannot opt out of these while you hold an account |
| Product news and marketing email | Your consent, withdrawable at any time |
4. Where your data is#
Gheima runs in regions. Each region is a self-contained cluster with its own compute, managed databases, object storage, container registry, logs and metrics.
| Region | Where it is | What it holds |
|---|---|---|
| eu-1 (default) | European Union, on infrastructure rented from Hostinger | Tenant workloads placed in it, and — today — the control plane for the whole platform |
| ma-1 (private preview) | Casablanca, Morocco, on Oracle Cloud af-casablanca-1 | Tenant workloads placed in it, and their managed databases, buckets, snapshots, builds, images, logs, metrics and backups |
The control plane — the dashboard you log into, the platform database holding resource metadata, encrypted configuration and the audit log, and the job queue — runs centrally, in the European Union. This is true for every account regardless of which region its workloads are in, and it is the honest limit of our residency claim. We intend to move the control plane to Morocco; until we have, this page will say the European Union.
Analytics for websites you deploy are computed from the receiving region's own access logs and stored in the platform database. Backups of a region's data are taken inside that region and copied to a second location inside the same country.
5. How it is protected#
- Everything is served over TLS; certificates are issued automatically and renewed on their own.
- Environment variables, database credentials, storage keys, connected Git tokens, two-factor secrets and recovery codes are encrypted at rest with AES-256-GCM under a key derived per account. They are shown back to you only through role-gated endpoints, and every reveal is written to the audit log.
- Every resource carries the account it belongs to as a column, and every query is scoped by it. Cross-account and cross-region access is refused at the boundary rather than filtered afterwards.
- Builds of your code run in an isolated rootless build daemon, not on a cluster manager.
- The audit log is append-only at the database level: a trigger rejects any update or delete other than the scheduled minimisation described below.
6. Website analytics, and what they do not contain#
If analytics are enabled for a service, we record one row per request to it: a visitor hash, the path, the referring host, the visitor's country, and the response status. The visitor hash is derived and rotating — it lets us count returning visitors without identifying them.
We do not store the raw IP address and we do not store the user-agent string. Country is resolved locally from an offline database; no request data is sent to a third-party analytics service. You can turn analytics off per service.
7. How long we keep it#
| Data | Retention |
|---|---|
| Sessions | 7 days, sliding; revoked immediately when you sign out or close the account |
| IP address and user agent on audit records | 365 days, then erased in place. The record itself — action, resource, time — is kept as accountability evidence. |
| Operational records: webhook and channel deliveries, alert events, cron runs, sent-email log, notifications | 90 days |
| Expired authentication and verification tokens | Deleted once expired |
| Deployment history | Life of the resource — it is product state, not telemetry |
| Backups | 14 days, then pruned |
| A closed account | 30-day restore window, then hard-purged |
| Invoices and tax records | As long as tax law requires, after the account is gone |
Erasure is not instantaneous across backups. After we delete your data from the live system, encrypted backups may still contain it for up to fourteen days until they age out. We are telling you this rather than implying a cleaner promise than we can keep.
8. Who else processes it#
We use a small number of sub-processors — infrastructure, email, payments and Git. Each one is named, with what it does and where, on our Sub-processors page. We will update that page before adding a new one.
9. Your rights#
You can ask us to give you a copy of your data, correct it, delete it, restrict what we do with it, or object to processing we do on the basis of legitimate interest. Two of these you can exercise yourself, without asking:
- Export — the dashboard produces a JSON export of your account and your own user record: projects, services, databases, buckets, domains, invoices, members, invitations, the sent-email log, your own sessions and your own audit entries. It deliberately excludes secrets, and it is scoped to you, so an administrator cannot export a colleague's sessions or audit trail.
- Deletion — closing the account starts the process described in section 7.
For anything else, write to hello@gheima.ma. We will answer within thirty days. We may ask you to confirm you control the account's email address before acting on a request — not as an obstacle, but because acting on an unverified erasure request is itself a data breach.
If you are in Morocco you may complain to the CNDP (Commission Nationale de contrôle de la protection des Données à caractère Personnel). If you are in the European Union or the United Kingdom, you may complain to your national supervisory authority. We would rather you came to us first, but that is your right and not conditional on it.
10. Cookies#
We set three cookies, and none of them are for advertising: a session cookie that keeps you signed in, a language cookie that remembers whether you chose Arabic, French or English, and a theme cookie. They are strictly necessary or set on your own action, so we do not show a consent banner for them. Cookies set by the applications you deploy are yours, and your own policy covers them.
11. International transfers#
Because the control plane is in the European Union and our infrastructure and service providers are in several countries, your account data crosses borders. Where a transfer leaves the country you are in, we rely on the transfer mechanism that applies to it — standard contractual clauses with our processors, or your explicit instruction when you choose a region. Section 4 tells you where each category actually sits, which is the part that matters more than the label.
12. Children#
Gheima is for developers and organisations, not for children. We do not knowingly collect data from anyone under sixteen. School accounts exist for institutions, and it is the institution's responsibility to have the standing to enrol the students it adds.
13. Changes, and how to reach us#
This policy carries a version and a date. We will notify account holders by email before a change that materially affects what we do with personal data. For anything in this policy, write to hello@gheima.ma.