Security at Gheima
What we do to protect your data, and where the limits are, gathered in one place for vendor review.
Everything on this page is a summary of documents we already publish. It is not a contract: where the two differ, the linked document is what applies.
Where your data is
Tenant workloads run in the European Union by default, on infrastructure rented from Hostinger. The control plane, which is the dashboard, the platform database and its backups, runs in Casablanca, Morocco, in the ma-1 region, for every account.
The data-residency add-on places your workloads in Casablanca. That claim is country-level and about data at rest: your application containers, managed databases, buckets, snapshots and build inputs stay in Morocco, and nothing we run moves your stored data out of the country on its own.
Our infrastructure provider commits in its data processing agreement to keep the data in the region we ordered. Its own documentation names the city, not the building, and it may access data from outside Morocco in order to support and recover the service.
Source:Data residencyData processing agreementPrivacy policy
Encryption
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.
Per-region encryption keys
The secrets that belong 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 cannot decrypt the configuration of a workload hosted elsewhere.
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.
Two-factor authentication and roles
Two-factor authentication is available to every user, and on team accounts an owner can require it.
Accounts have roles. Owners and admins can see billing, manage members, reveal environment variables and delete resources.
Audit log
The audit log records your actions in the dashboard and API: what was done, to which resource, when, from which IP and user agent. It is append-only at the database level: a trigger rejects any update or delete other than the scheduled minimisation, which erases the IP address and user agent after 365 days and keeps the record itself as accountability evidence.
Administrative actions, including any staff impersonation of an account for support, are written to the audit log.
The account export produces your account-level records as JSON, including your own audit entries. It deliberately excludes secrets.
Tenant isolation
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.
Managed databases are reachable on a private overlay and publish no ports to the internet.
Builds of your code run in an isolated rootless build daemon, separate from cluster management.
Source:Data processing agreement
Backups
Backups are automated and stored encrypted, with a scheduled restore drill that actually restores: a backup nobody has restored is a hypothesis.
A region's backups are taken inside that region and copied to a second location: inside the same country for a residency region, and inside the European Union for the European region. They are kept for 14 days, then pruned.
They are our insurance, not yours. Keep your own copies of anything you cannot afford to lose.
Availability
We publish live platform health on our status page.
We aim for high availability and we design for it, but we do not currently offer a contractual uptime SLA with service credits.
Source:Terms of serviceStatus
If something goes wrong
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, and keep updating you as we learn more.
Source:Data processing agreement
Who else processes data
Every third party that may process personal data for Gheima is named on our sub-processors page, with what it does and where. Account holders are notified by email at least thirty days before a new sub-processor starts processing.
Source:Sub-processors
Vendor review
On reasonable written notice we will give you the information you need to demonstrate compliance with the data processing agreement, and we will answer a security questionnaire. If your procurement needs a countersigned copy of the agreement, write to us.