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.16 · Last updated November 14, 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.
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 (listed below). 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 |
|---|---|---|
| ma-1 (default for every plan) | Casablanca, Morocco, on Oracle Cloud af-casablanca-1 | Tenant workloads placed in it, and their managed databases, object-storage buckets, snapshots, builds, images, logs, metrics and backups; and, since 21 September 2026, the control plane for the whole platform |
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 Casablanca, Morocco, in the ma-1 region, since 21 September 2026. Its database and its backups are stored there. This is true for every account regardless of which region its workloads are in. Since 22 September 2026, the secrets that belong to a single workload (your service environment variables, your managed-database passwords and connection strings, and your object-storage keys) are encrypted under a key belonging to the region that hosts that workload. Only that region's infrastructure and the control plane in Morocco hold it, so our infrastructure in the European Union can no longer decrypt the configuration of a workload hosted anywhere else. One limit 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) are still encrypted under a single key that every region's workers hold, because any region may run a job for your account. We will update this page if that changes.
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 in the same jurisdiction: in Morocco for the Casablanca region (ma-1).
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. Three 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.
- Correction: you can change your name yourself in Settings. The email address you sign in with is your identity on the platform, so to change it, write to us from that address.
- Deletion: closing the account starts the process described in section 7.
For anything else, write to hello@gheima.ma. We answer a request for access to your data without delay, and correct inaccurate data within ten clear days of your request (loi 09-08, art. 7 and 8). We answer any other request 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#
Every cookie gheima.ma sets is listed below. None is used for advertising, audience measurement or profiling, none is shared with anyone, and we do not follow you across other sites. Each one is either strictly necessary to provide the service you asked for, or set only when you take the action it serves, so we do not ask for your consent before setting them and do not show a consent banner. The names are those used in production.
| Cookie | What it does | How long it lasts | Why no consent is needed |
|---|---|---|---|
| __Host-gheima.session_token | Keeps you signed in after you sign in. | 7 days, renewed while you use the dashboard; deleted when you sign out. | Strictly necessary: without it you cannot use your account. |
| __Host-gheima.session_data | A short-lived copy of your session, so that each page does not have to look it up again. | 5 minutes. | Strictly necessary, as part of the sign-in above. |
| __Host-gheima.oauth_state | Protects a sign-in with GitHub against forgery while you are on GitHub's page. | 10 minutes. | Set only when you choose to sign in with GitHub; strictly necessary for security. |
| gh_2fa | Records that this session has passed the two-factor check, so you are not asked for a code on every page. | 7 days. | Set only when you enter a two-factor code; strictly necessary for security. |
| __Host-gheima_sso | Protects a single sign-on (SSO) round trip with your organisation's identity provider. | 10 minutes. | Set only when you start a single sign-on; strictly necessary for security. |
| gheima.active_account | Remembers which account or team you are working in. | 30 days. | Set only when you switch account; necessary for the service you asked for. |
| gh_join | Carries a school's join code through sign-up when you open a join link while signed out. | 1 hour. | Set only when you open a join link; necessary for the sign-up you started. |
| NEXT_LOCALE | Remembers the language you chose: Arabic, French or English. | 1 year. | Set only when you choose or open a language other than your browser's; it serves a choice you made. |
Your light or dark theme, the notices you have dismissed and your recent commands and queries are kept in your browser's local storage, not in cookies. They stay on your device and are never sent to us.
When you pay by card, the card form and the payment pages are provided by our payment provider. That provider may set its own cookies, under its own policy; we neither set nor read them.
Cookies set by the applications you deploy are yours, and your own policy covers them.
11. International transfers#
Because our infrastructure and service providers are in several countries (the control plane and every region in Morocco, some of our providers in the European Union and the United States), your account data crosses borders. 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. 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.