EU Enterprise CI/CD Comparison 2026: Jenkins vs GitLab vs Azure DevOps vs TeamCity — CLOUD Act Risk Matrix

Post #5 (Finale) in the sota.io EU CI/CD Tools Series

Your CI/CD pipeline has access to everything: source code, secrets, deployment credentials, production infrastructure. Under GDPR Article 4, every IP address, commit author, and build log is personal data processed in that pipeline. Under NIS2 Article 21(2)(d), CI/CD is a Tier-1 supply chain component. Under DORA Article 28, your CI/CD vendor is an ICT third-party service provider requiring formal risk assessment.

This finale synthesises all four providers from the EU CI/CD Tools Series into a single decision framework: their complete CLOUD Act exposure, GDPR risk surface, EU regulatory compliance position, and total cost of ownership against EU-native alternatives.

Series Recap: What We Measured

Across Posts 1–4, we applied a consistent 25-point CLOUD Act scoring methodology to each provider:

A score of 0/25 means zero identifiable CLOUD Act exposure. A score of 25/25 means maximum exposure across all dimensions.

The Four-Provider Risk Matrix

Azure DevOps — 21/25 (Highest in Series)

Legal entity: Microsoft Corporation, Redmond, Washington State, USA
CLOUD Act exposure: Maximum practical exposure.

GDPR-specific CI/CD risks with Azure DevOps:

• Pipeline logs = personal data (Art. 4): Commit author names, email addresses, timestamps. Azure stores these in US-jurisdiction control planes.
• Secrets and variables (Art. 25): Azure DevOps Variable Groups and Library are stored encrypted but under US-controlled key management.
• Artifact metadata (Art. 30): Build artefacts with developer attribution are subject to CLOUD Act production orders.
• Agent pools (Art. 28): Microsoft-hosted agents run in Azure datacentres — but the control plane issuing agent tokens remains US-jurisdiction.
• DORA Art. 28: Azure DevOps as ICT TPP requires formal contractual clauses — Microsoft's DPA includes SCC Module 2 but SCCs do not override CLOUD Act.

The EU Data Boundary problem: Microsoft launched the EU Data Boundary in January 2024, committing to process EU customer data within the EU. However, the boundary explicitly does not override Microsoft's obligations under US law. When a US court issues a §2513 order, Microsoft must comply regardless of where data is stored. The EU Data Boundary is a contractual arrangement; CLOUD Act is statute.

Jenkins (CloudBees) — 18/25

Legal entity: CloudBees, Inc., San Jose, California, USA (Jenkins open-source core: Software in the Public Interest / Apache Software Foundation — 0/25)
CLOUD Act exposure: High for CloudBees SaaS/CloudBees CI; zero for self-hosted Jenkins.

The Jenkins split: This is the most important nuance in the series. Jenkins itself — the open-source project — scores 0/25 because there is no legal entity with CLOUD Act obligations. CloudBees CI, the commercial managed CI product, scores 18/25. European enterprises using self-hosted Jenkins on their own infrastructure (including Hetzner, OVHcloud, or Scaleway) achieve 0/25 exposure. The entire 18/25 risk is introduced by choosing the CloudBees SaaS wrapper.

GDPR for Jenkins self-hosted:

• Build data remains on your infrastructure under your legal control
• No Art. 44 transfer question — data never leaves EU jurisdiction
• Art. 28 DPA: you are both data controller and data processor; no third-party processor

GDPR for CloudBees CI SaaS:

• All data transferred to US-jurisdiction servers under Art. 44 Standard Contractual Clauses
• SCC Module 2 applies but cannot override CLOUD Act §2713
• Transfer Impact Assessment (TIA) required under Schrems II — CloudBees does not publish an EU-specific TIA

GitLab.com SaaS — 16/25

Legal entity: GitLab Inc., San Francisco, California, USA (GitLab CE/EE self-hosted: open-source MIT licence — 0/25)
CLOUD Act exposure: High for GitLab.com SaaS; zero for self-hosted GitLab CE.

The GitLab Dedicated nuance: GitLab launched GitLab Dedicated — a single-tenant SaaS offering — in 2023, with EU regions in 2024. This significantly reduces cross-region data flows. However: GitLab Inc. remains the US legal entity that receives any §2713 order; data isolation does not change the entity's legal obligations. GitLab's sub-processors include Google (GCP) — also a US entity.

GitLab CI/CD-specific GDPR risks:

• Runner tokens (Art. 25): GitLab.com issues runner registration tokens through the US control plane.
• Merge request diffs (Art. 4): Commit author attribution stored on US-controlled servers.
• CI/CD variables (Art. 25): Secret masking prevents exposure in logs, but secrets are stored encrypted under GCP/GitLab key management.
• Audit events (Art. 30): GitLab's audit log API includes developer identity — stored in US jurisdiction.

Self-hosted GitLab CE = 0/25: GitLab Community Edition running on EU infrastructure with no connection to gitlab.com achieves zero CLOUD Act exposure. The entire 16/25 risk is in the SaaS layer.

JetBrains TeamCity — 6/25 (Lowest in Series)

Legal entity: JetBrains s.r.o., Prague, Czech Republic (EU Member State) + JetBrains N.V., Amsterdam, Netherlands (EU Member State)
CLOUD Act exposure: Significantly lower due to EU incorporation — but not zero.

Why JetBrains is categorically different: The CLOUD Act targets "providers of electronic communication services or remote computing services" that are US persons or US-incorporated entities. JetBrains s.r.o. is neither. A §2713 order cannot be issued directly to the Czech entity. The US would need to use MLAT (Mutual Legal Assistance Treaty) procedures with the Czech Republic — a significantly slower and less certain path.

The residual risks:

1. JetBrains Americas Inc. — if data flows through the US entity (sales, support systems), that US entity could receive a §2713 order for data it processed.
2. Cloud sub-processors — AWS/GCP are US entities and can receive direct §2713 orders for data they store, even on behalf of a non-US customer.
3. TeamCity self-hosted — eliminates sub-processor risk entirely, scoring effectively 0/25 for data that never touches JetBrains servers.

Side-by-Side Risk Matrix

EU-Native Alternatives: The 0/25 Options

When EU compliance is the primary driver, self-hosted alternatives on EU infrastructure achieve zero CLOUD Act exposure:

Woodpecker CI — 0/25

Legal basis: Community project (no single US or EU parent entity). Apache 2.0 licence.
Status: CNCF Sandbox project. Fork of Drone CI.
Architecture: Docker-based pipeline execution. YAML pipeline syntax.
GDPR: All data on your infrastructure. You are the sole data controller.
Cost on Hetzner: 1× CX22 (€4.15/mo) for coordinator. Agents: 1× CX22 per parallel pipeline.
Best for: Teams migrating from Drone CI; straightforward Docker-based pipelines.

# Woodpecker CI pipeline example
pipeline:
  build:
    image: golang:1.22
    commands:
      - go build ./...
      - go test ./...
  deploy:
    image: alpine
    secrets: [HETZNER_TOKEN]
    commands:
      - apk add curl
      - curl -X POST $DEPLOY_WEBHOOK
    when:
      branch: main

Forgejo Actions — 0/25

Legal basis: Forgejo is a community-owned fork of Gitea (registered in Germany).
Status: Stable. GitHub Actions-compatible YAML syntax.
Architecture: Self-hosted Git + CI in one. Action runners written in Go.
GDPR: All data on your infrastructure.
Cost on Hetzner: 1× CX32 (€8.05/mo) for combined Git + CI. Runners: 1× CX22 per parallel job.
Best for: Teams migrating from GitHub Actions (drop-in YAML compatibility).

# Forgejo Actions — GitHub Actions compatible
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: go build ./...
      - name: Test
        run: go test ./...

Tekton — 0/25

Legal basis: CNCF project, Linux Foundation. No single US parent.
Status: Production-ready. Kubernetes-native.
Architecture: Kubernetes CRDs (Tasks, Pipelines, PipelineRuns). Cloud-native but complex.
GDPR: All data in your Kubernetes cluster.
Cost on Hetzner: Runs within existing k3s/Kubernetes cluster. Overhead: ~512MB RAM.
Best for: Kubernetes-native organisations; enterprise-grade pipelines; microservices.

GitLab CE Self-Hosted — 0/25

Legal basis: MIT licence. No SaaS dependency.
Architecture: Full GitLab stack (Git, CI, registry, merge requests) on your server.
Cost on Hetzner: 1× CCX13 (€26/mo) minimum. Recommended: CCX23 (€55/mo) for teams >10.
Best for: Teams already on GitLab SaaS wanting to self-host with identical CI syntax.

Jenkins Self-Hosted — 0/25

Legal basis: MIT licence, Software in the Public Interest.
Architecture: Java-based, plugin ecosystem (2,000+ plugins).
Cost on Hetzner: 1× CX22 (€4.15/mo) for coordinator. Agents: CX22 per parallel executor.
Best for: Teams with existing Jenkins expertise; complex enterprise pipelines.

GDPR Art. 44–49 Transfer Framework for CI/CD

All four SaaS providers require transfers to the US under Chapter V of GDPR. The applicable mechanisms and their limitations:

Standard Contractual Clauses (SCCs) — Module 2

All four providers offer SCCs under EU Commission Implementing Decision 2021/914. The Schrems II judgment (C-311/18) requires a supplementary Transfer Impact Assessment (TIA) to verify SCCs provide adequate protection in practice.

TIA finding for CI/CD: The TIA must assess whether US surveillance law renders SCCs ineffective. For CLOUD Act §2713, the answer is yes for three of the four providers: a §2713 order overrides any contractual commitments, including SCCs. CI/CD data (source code, secrets, build logs) qualifies as "contents of a wire or electronic communication" — directly subject to §2713 production orders.

Practical implication: Supervisory authorities in Austria (DSB), France (CNIL), Germany (LfDI Bayern), and Ireland (DPC) have found that SCCs alone do not render US transfers lawful when the recipient is subject to CLOUD Act. This directly impacts Azure DevOps, Jenkins CloudBees SaaS, and GitLab.com SaaS.

GDPR Art. 49 Derogations

Not available as a general transfer basis for ongoing CI/CD operations. Art. 49 derogations (explicit consent, vital interests, etc.) apply only to occasional, non-repetitive transfers. CI/CD pipelines run continuously.

BCRs (Binding Corporate Rules)

Microsoft has BCRs approved by the Luxembourg DPA covering intra-group transfers. BCRs do not override CLOUD Act obligations — they are internal transfer mechanisms, not external law shields.

NIS2 Art. 21(2)(d) — CI/CD as Supply Chain Risk

Article 21(2)(d) of NIS2 (Directive 2022/2555/EU) requires essential and important entities to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

CI/CD pipelines are Tier-1 supply chain components because:

1. They have write access to production deployment targets
2. They hold secrets for all downstream services
3. A compromised pipeline can inject malicious code into any artefact

NIS2 vendor risk assessment requirements for CI/CD:

Practical NIS2 compliance difference: For entities in NIS2 scope, a TeamCity Cloud supply chain risk assessment is meaningfully easier to pass than Azure DevOps. The Czech supervisory authority operates under EU law, making regulatory cooperation in incident investigations follow EU processes. A US-incorporated CI/CD vendor requires demonstrating that CLOUD Act risk has been adequately mitigated — a much harder showing.

DORA Art. 28 — ICT Third-Party Risk Management

DORA (Regulation EU 2022/2554) applies to financial entities and their ICT service providers. Article 28 requires:

1. Written contractual arrangements for all critical ICT TPPs
2. Risk assessment before onboarding
3. Exit strategy for each critical TPP
4. Incident reporting capability

For financial entities using CI/CD in production deployment pipelines, the CI/CD provider qualifies as a critical ICT TPP under Art. 28.

DORA contractual requirements vs. CLOUD Act:

The challenge: DORA Art. 28(8) requires contractual terms that ensure the ICT TPP cooperates with the financial entity's competent authority. For EU-supervised financial entities, the competent authority is typically an EU national authority (EBA, ECB, national central banks). A US-incorporated CI/CD provider is subject to US law first — creating potential conflict when US legal orders (§2713) conflict with EU supervisory requests.

DORA's Joint Oversight Framework (JOF), effective 2025, designates critical ICT TPPs. A US-incorporated CI/CD provider serving the EU financial sector faces dual regulatory pressure with potential jurisdictional conflict. JetBrains, as a Czech/NL entity, faces no such conflict — EU supervisory requests and home-country law align.

Decision Framework: Which CI/CD Platform for Your Risk Profile?

Risk Profile A — Maximum EU Compliance (NIS2/DORA scope, financial services, critical infrastructure)

Recommendation: Self-hosted on EU infrastructure

• Jenkins self-hosted (0/25): Highest plugin ecosystem, complex pipelines
• GitLab CE self-hosted (0/25): Best developer experience, integrated SCM+CI
• Forgejo Actions (0/25): GitHub Actions migration path, simple setup
• Woodpecker CI (0/25): Lightweight, Docker-native

Infrastructure: Hetzner Falkenstein (Germany) or nbg1 (Germany), or OVHcloud Roubaix (France)

Cost: €4–55/month depending on scale (vs €200–800/month for enterprise SaaS CI/CD)

Risk Profile B — Managed CI/CD with Reduced CLOUD Act Risk

Recommendation: JetBrains TeamCity Cloud (6/25)

• Acceptable for organisations that need managed CI/CD but cannot justify full self-hosting
• Requires TIA and DPA under Art. 28
• EU Data Region available — reduces cross-border transfer frequency
• Residual sub-processor risk must be documented

Cost: TeamCity Cloud Business: €384/mo (10 agents) vs self-hosted on Hetzner: €64/mo (10× CX22 agents)

Risk Profile C — Legacy Constraint (Existing Azure or GitHub estate)

Recommendation: Azure DevOps with compensating controls

• CLOUD Act risk is highest (21/25) but compensated by Microsoft's DPA, SCCs, and EU Data Boundary
• Requires formal TIA documenting accepted risk
• EU Data Boundary reduces — but does not eliminate — transfer scope
• Only appropriate when Azure estate lock-in outweighs compliance cost

Must-have compensating controls:

1. Enable EU Data Boundary (Azure DevOps organisation settings)
2. Use self-hosted agents in EU datacentres for sensitive pipelines
3. Store secrets in Azure Key Vault with EU-region vaults, RBAC limited to EU-jurisdiction identities
4. Implement pipeline audit logging with SIEM in EU jurisdiction
5. Document CLOUD Act residual risk in DORA/NIS2 supply chain register

Total Cost of Ownership: SaaS CI/CD vs EU Self-Hosted

For 10 parallel pipeline executors:

Cost difference: Moving from TeamCity Cloud to Jenkins self-hosted saves €338/month (88%) while reducing CLOUD Act score from 6/25 to 0/25.

Moving from Azure DevOps to GitLab CE self-hosted saves €743/month (88%) while reducing CLOUD Act score from 21/25 to 0/25.

Migration Paths

Azure DevOps → GitLab CE Self-Hosted (4 weeks)

Week 1: Deploy GitLab CE on Hetzner CCX23 (€55/mo). Import repositories via GitLab's Azure DevOps import tool.

Week 2: Migrate Azure Pipelines YAML to GitLab CI. Mapping:

• trigger → rules: [if: $CI_COMMIT_BRANCH]
• pool: {vmImage: ubuntu-latest} → image: ubuntu:24.04
• steps → script blocks
• Variable Groups → GitLab CI/CD Variables (Settings → CI/CD → Variables)

Week 3: Migrate Azure Artifacts → GitLab Package Registry. Migrate Azure Test Plans → GitLab's built-in test reporting.

Week 4: Cut over DNS, update webhook URLs, disable Azure DevOps pipelines. Run parallel for 1 week.

Jenkins CloudBees → Woodpecker CI (2 weeks)

Week 1: Deploy Woodpecker on Hetzner CX22 + PostgreSQL backend. Map Jenkinsfile stages to Woodpecker pipeline steps. Woodpecker's Docker-first model aligns closely with modern Jenkins pipeline stages.

Week 2: Migrate shared libraries. Jenkins shared libraries → Woodpecker plugins or Docker image abstractions.

GitLab.com SaaS → GitLab CE Self-Hosted (3 weeks)

Week 1: Deploy GitLab CE. Run gitlab-rake gitlab:import:gitlab to import projects.

Week 2: Migrate CI/CD variables, runner registrations. GitLab.com CI YAML is 100% compatible with self-hosted — no syntax changes needed.

Week 3: Migrate Packages, Container Registry, Pages. Update DNS.

Series Summary: EU CI/CD Compliance Ranking

The core principle: Every CI/CD SaaS provider headquartered in the US introduces CLOUD Act risk — regardless of where their servers are located. Source code, build secrets, pipeline logs, and developer identities processed by a US entity are reachable under §2713 without a European court order. Self-hosting on EU infrastructure eliminates this category of risk entirely.

For organisations where this risk is unacceptable — financial entities under DORA, critical infrastructure operators under NIS2, or any organisation processing GDPR Art. 9 special-category data — self-hosted CI/CD on EU infrastructure is the only fully compliant path.

Resources

• EU CI/CD Tools Series Post 1: Jenkins CloudBees EU Alternative 2026
• EU CI/CD Tools Series Post 2: GitLab.com SaaS EU Alternative 2026
• EU CI/CD Tools Series Post 3: Azure DevOps EU Alternative 2026
• EU CI/CD Tools Series Post 4: JetBrains TeamCity EU Alternative 2026
• CLOUD Act 18 U.S.C. §2713 Full Text
• NIS2 Directive 2022/2555/EU — Art. 21 Full Text
• DORA Regulation 2022/2554/EU — Art. 28 Full Text
• EDPB Guidelines 05/2021 on Standard Contractual Clauses
• Schrems II Judgment C-311/18 (Data Protection Commissioner v Facebook Ireland)