Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
GitLab is an end to end DevSecOps platform combining source control, code review, CI/CD, container and package registries, security scanning, observability and project management. It is available as GitLab SaaS (gitlab.com), as the free, open source Community Edition that anyone can self host, and as the Enterprise Edition or GitLab Dedicated tier with EU data residency. The privacy posture depends heavily on the deployment model.
GitLab is an open core DevSecOps platform developed by GitLab Inc., a company headquartered in San Francisco with a fully remote workforce. It is one of the largest source code and CI/CD platforms in the world, alongside GitHub and Bitbucket, and is unique in combining the full software lifecycle in a single application. GitLab is available in three flavours: GitLab SaaS on gitlab.com, GitLab Self Managed (Community Edition and Enterprise Edition installed on the customer infrastructure) and GitLab Dedicated, a single tenant cloud offering with regional data residency including EU.
In the logged in area, GitLab sets the _gitlab_session cookie, a remember_user_token cookie when the user opts in, and _gitlab_ci_session for CI/CD specific contexts. These are strictly necessary for authentication. On the public marketing pages of gitlab.com, GitLab may load Google Analytics, Drift, Marketo and Snowplow tags with the corresponding cookies once the visitor accepts the cookie banner. Stored data includes source code, issues, merge requests, container images and packages, CI logs and audit events.
The application session cookies are strictly necessary for sign in and exempt from the consent requirement. Source code, issues and CI artefacts can contain personal data, in which case GitLab Inc. acts as a processor under Article 28 GDPR for the customer''s repositories. For GitLab SaaS, the standard mechanism is the GitLab DPA with SCCs and DPF for the US transfer; for Dedicated, the EU region keeps customer data inside the EU. Self hosted GitLab does not transfer data to GitLab Inc. unless Service Ping is explicitly enabled.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
Not for the authenticated DevOps experience. The session cookies are strictly necessary. Consent is required for the marketing pages of gitlab.com (the cookie banner handles this) and for any optional product analytics through the GitLab Snowplow stack on the SaaS. Self hosted GitLab can disable usage statistics (Service Ping) entirely and avoid the question.
GitLab SaaS primarily stores data in Google Cloud US regions, with a Customer Data Residency commitment that limits routine transfers but does not eliminate them. GitLab Dedicated allows pinning the data to an EU region (Frankfurt) for compliance sensitive customers and is the recommended path for regulated industries. GitLab Inc. is DPF certified and signs SCCs through its DPA. The full sub processor list is published in GitLab Trust Center.
For EU customers, evaluate GitLab Dedicated with EU region for code that contains regulated data; self host GitLab CE/EE in the EU if you need full control; sign the GitLab DPA; disable Service Ping if telemetry is unwanted; configure SSO and MFA for all administrators; mention GitLab Inc. and its sub processors in the privacy policy; and treat the public marketing pages of gitlab.com as a separate consent perimeter when you embed GitLab content on your site.
Websites using GitLab must obtain user consent under GDPR regulations.
DPIA considerations
A DPIA is recommended for GitLab SaaS deployments that handle production code containing personal data, security scanners that produce vulnerability reports, or pipelines that touch regulated data. Self hosted GitLab is low risk because the customer controls the entire stack. Document the deployment model, the data residency promise, the use of Service Ping and the sub processors.
Sample consent text
Our developer portal runs on GitLab. Logged in users have session cookies set by GitLab. Public marketing pages on gitlab.com may set optional analytics and marketing cookies if you accept them in the cookie banner.
Third-party domains contacted
gitlab.comabout.gitlab.comdocs.gitlab.comassets.gitlab-static.netgitlab-runner-downloads.s3.amazonaws.comsnowplowanalytics.comregistry.gitlab.comCookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| _gitlab_session | first party | Session | Main GitLab session cookie, set on the application domain to keep the user logged in. Strictly necessary. |
| remember_user_token | first party | 2 weeks | Optional Remember me cookie that extends the GitLab session when the user opts in during login. |
| _gitlab_ci_session | first party | Session | Session cookie for CI/CD specific endpoints when accessed from a browser. |
| event_filter | first party | 1 year | Stores the last selected filter in the GitLab dashboard event feed. |
| user_oauth_state | first party | Short lived | OAuth state token used during third party login flows on GitLab. |
| _ga / _ga_<ID> | third party | 2 years | Google Analytics cookies set on the public marketing pages of gitlab.com after consent. Not set inside the authenticated application. |
This service may collect user data. Ensure GDPR compliance with FlowConsent.
The authenticated GitLab application sets _gitlab_session, remember_user_token (when the user opts in), _gitlab_ci_session, _gitlab_pages_session and CSRF tokens. All are strictly necessary. The marketing pages of gitlab.com load additional analytics and marketing cookies after consent.
Not for the authenticated DevOps experience. Yes for marketing and product analytics that GitLab loads on its public pages or that you enable through optional integrations. Self hosted GitLab can disable telemetry entirely.
Contract performance for the DevOps service, legal obligation for security and audit log retention, legitimate interest for fraud and abuse prevention. Consent is the basis for non strictly necessary trackers on public pages.
For GitLab SaaS, yes, with the EU US Data Privacy Framework and SCCs in the DPA covering the transfer. For GitLab Dedicated EU, customer data stays in the EU region. For self hosted, no data leaves your infrastructure unless Service Ping is enabled.
For self hosted CE or EE, generally no. For GitLab SaaS containing regulated or production data, a DPIA is recommended. For GitLab Dedicated EU, document the residency in your DPIA but the assessment is usually lighter than SaaS.
Choose Dedicated EU or self host in the EU when the data is sensitive; sign the GitLab DPA; configure SSO and 2FA; disable Service Ping if you do not want telemetry; review sub processors at the Trust Center; document the deployment in the Article 30 record.
GitHub (Microsoft, also DPF certified, EU regions in preview), Bitbucket (Atlassian, EU regions available), Gitea (open source, self hosted, Gitea Cloud EU), Forgejo (open source fork of Gitea), Codeberg (community hosted in Germany). Each has different data flows and licensing.
For the authenticated portal, list _gitlab_session and related cookies under Strictly Necessary with provider GitLab Inc., USA. For the public marketing pages, list the analytics and marketing trackers (Google Analytics, Marketo, Drift) separately with consent. Mention the transfer mechanism (DPF and SCCs).