JetBrains TeamCity EU Alternative 2026: Czech CI/CD with CLOUD Act Score 6/25

Post #4 in the sota.io EU CI/CD Tools Series

JetBrains TeamCity occupies an unusual position in the EU CI/CD landscape: it is one of the few major DevOps platforms built and operated by a European company. JetBrains s.r.o., the primary operating entity, is incorporated in the Czech Republic — an EU member state. Unlike GitHub Actions (Microsoft/PRISM, 21/25), Azure DevOps (Microsoft, 21/25), or Jenkins CloudBees (Delaware, 18/25), TeamCity is not directly subject to the US CLOUD Act.

But "not directly subject" is not the same as "zero risk." JetBrains has a US subsidiary, TeamCity Cloud uses third-party cloud infrastructure, and the legal picture involves nuances that compliance teams need to understand before deciding whether TeamCity Cloud, TeamCity self-hosted, or a fully EU-native alternative is the right choice.

This post gives you the complete picture: corporate structure, CLOUD Act scoring methodology, GDPR implications for CI/CD pipelines, and a practical migration guide to Woodpecker CI, Forgejo Actions, and Tekton on Hetzner.

JetBrains Corporate Structure

Understanding the risk starts with understanding who actually operates TeamCity:

The critical fact: JetBrains N.V. and JetBrains s.r.o. are both incorporated in EU member states (Netherlands and Czech Republic respectively). Neither entity is a US person under US federal law, which means the US CLOUD Act (18 U.S.C. § 2703) does not apply directly to them.

This is fundamentally different from Microsoft (Washington State), Amazon (Delaware/Washington State), or CloudBees (Delaware) — all of which are US legal persons compellable under the CLOUD Act.

The US Subsidiary Caveat

JetBrains Americas Inc. (San Francisco, CA) is a US-incorporated entity. However, CLOUD Act exposure depends on what that entity actually controls — specifically whether it has "possession, custody, or control" (18 U.S.C. § 2703(a)) over TeamCity Cloud data.

If JetBrains Americas Inc. functions purely as a sales and support subsidiary with no administrative access to TeamCity Cloud infrastructure or data, the CLOUD Act risk via this entity is limited. If it shares IT systems, credentials, or key management with the Czech entity, the risk increases.

JetBrains' published documentation indicates that TeamCity Cloud customer data is controlled by the Czech/Dutch entity. But without a published sub-processor list that confirms zero data access by the US entity, this remains a residual risk requiring a Transfer Impact Assessment under GDPR Art.46 Schrems II guidance.

CLOUD Act Score: 6/25

Overall CLOUD Act Score: 6/25 — significantly lower than any US-headquartered CI/CD provider.

Score: 6/25 — lower than even Northflank (UK, 3/25 for CLOUD Act but 3/25 overall), but higher than fully self-hosted EU-native solutions (0/25).

Comparison table for this CI/CD series:

The Czech provenance of JetBrains makes TeamCity Cloud meaningfully lower risk than any US-headquartered SaaS CI/CD tool, even before considering the self-hosted option.

What TeamCity Is and Why Teams Use It

TeamCity is a mature, full-featured CI/CD platform developed by JetBrains since 2006. It predates GitHub Actions by over a decade and is particularly popular in Java, Kotlin, and .NET shops.

Core capabilities:

• Build Chains: Link multiple build configurations into a pipeline where one triggers the next. Unlike GitHub Actions' linear workflows, TeamCity's Build Chain concept handles complex dependency graphs natively.
• Per-Branch Builds: TeamCity's Branch specification lets you auto-build feature branches without explicitly defining them in a config file — useful for trunk-based development.
• Test History: Persistent test history across builds. If a test has been failing for 20 builds, TeamCity surfaces that pattern. First-failure attribution tells you exactly which commit broke it.
• Composite Builds: Aggregate results from parallel sub-builds without duplicating build logic — native parallelism without YAML gymnastics.
• Kotlin DSL: Build configurations as code via a JetBrains-designed Kotlin DSL, checked into version control.
• Build Agent Pools: Fine-grained routing — run specific build configurations on specific agents (e.g., Windows builds on Windows agents, CUDA builds on GPU agents).
• Artifact Dependencies: Pass build outputs between configurations as first-class versioned artifacts.

Two deployment modes:

1. TeamCity Cloud (JetBrains-hosted) — managed service, build agents provided by JetBrains, EU data region available. CLOUD Act Score: 6/25.
2. TeamCity On-Premises — self-hosted on your infrastructure. CLOUD Act Score: 0/25 when on EU infrastructure.

GDPR Risk Analysis for CI/CD Pipelines

CI/CD systems are not just build automation — they are critical supply chain infrastructure under NIS2 Art.21(2)(d) and DORA Art.28. They hold secrets, handle source code, and produce artifacts that go directly into production. The GDPR implications are significant.

1. Source Code as Personal Data (Art.4)

Git commit metadata is personal data. Every git log entry in your CI system contains:

• Developer full names
• Developer email addresses
• Timestamps and activity patterns (work hours, coding cadence)

If TeamCity Cloud processes this data, the Czech JetBrains entity acts as a GDPR Art.28 data processor. A Data Processing Agreement (DPA) is required. JetBrains publishes a standard DPA — review it to confirm it meets your Art.28(3) requirements, particularly regarding sub-processor notification and your right to audit.

Self-hosted TeamCity on Hetzner removes the Art.28 data processor relationship for TeamCity itself, though Hetzner becomes the infrastructure processor.

2. Pipeline Secrets and Key Material (Art.25 Privacy by Design)

CI/CD systems routinely store:

• Database connection strings (may contain credentials for DBs holding personal data)
• API keys for third-party services processing personal data
• Signing certificates for production artifacts
• SSH keys for deployment targets

Under GDPR Art.25, these secrets must be protected with appropriate technical measures. For Art.5(1)(f) integrity and confidentiality: pipeline secrets accessible to a CI/CD platform operator are accessible to that operator's entire legal chain — including government orders.

With TeamCity Cloud (JetBrains, Czech): the operator is not US-compellable. Your secrets are protected from US federal orders under normal circumstances.

With GitHub Actions (Microsoft, Washington State): the operator is a confirmed PRISM participant. Your pipeline secrets are accessible to the world's most capable intelligence apparatus under CLOUD Act.

This difference is not theoretical — it is the core reason European compliance teams are evaluating JetBrains and self-hosted alternatives.

3. Build Artifacts and SBOM (Art.30 Records of Processing)

TeamCity stores build artifacts: compiled binaries, Docker images, test reports, coverage data. If these artifacts contain embedded personal data (user data in test fixtures, analytics endpoints in app code), they constitute personal data under GDPR Art.4(1).

TeamCity Cloud's artifact storage is part of the data processor relationship. Ensure your DPA with JetBrains covers artifact retention periods and deletion rights under GDPR Art.17.

4. NIS2 Supply Chain Security (Art.21(2)(d))

NIS2 Directive (EU) 2022/2555, Article 21(2)(d) 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."

Your CI/CD system is a Tier-1 supply chain component. A compromise of your CI system is a compromise of every artifact it produces — including production deployments. For NIS2 compliance:

• Map TeamCity as a critical supply chain dependency in your NIS2 risk register
• Conduct a Transfer Impact Assessment (TIA) for any cross-border data transfers (TeamCity Cloud EU region: Czech/NL entity processing, no TIA required for EU-to-EU; US sub-processors: TIA required)
• Implement Code Signing via TeamCity's artifact signing features
• Enable Build History retention for audit trails under Art.21(2)(j)

5. DORA Art.28: ICT Third-Party Risk for Financial Entities

If you are a financial entity under DORA (Regulation (EU) 2022/2554), your CI/CD system is an ICT third-party service provider. DORA Art.28(2) requires:

• Written contractual arrangements with ICT service providers (✓ — TeamCity has contracts)
• Risk assessment of the ICT provider (✓ — CLOUD Act score 6/25 for TeamCity Cloud)
• Right to audit and inspect (check: JetBrains' contract terms)
• Exit strategy and portability (✓ — TeamCity's Kotlin DSL exports to self-hosted)

TeamCity's EU provenance (Czech) means it can potentially qualify as an EU-based ICT provider for DORA purposes — a significant advantage over US providers.

TeamCity Self-Hosted: The Zero-Risk Option

TeamCity self-hosted on EU infrastructure eliminates all jurisdictional risk. The architecture:

[Developer] → git push → [Gitea/Forgejo on Hetzner]
                              ↓ webhook
                    [TeamCity Server on Hetzner]
                         ↓ trigger
              [TeamCity Build Agents (Hetzner CCX13)]
                         ↓ artifacts
              [Hetzner Object Storage / Registry]

Hetzner CCX13 sizing for a 5-developer team:

• TeamCity Server: 1× CCX13 (2 vCPU, 8 GB RAM) — €26/mo
• 2× Build Agents: 2× CPX31 (4 vCPU, 8 GB RAM) — 2× €19/mo = €38/mo
• Hetzner Object Storage (artifacts): ~10 GB = €0.024/GB = €0.24/mo
• Total: ~€64/mo vs TeamCity Cloud €384/mo (Business plan, 10 agents)

CLOUD Act Score: 0/25 — you are the data controller and processor. No third-party data access.

License note: TeamCity Professional is free for up to 100 build configurations and 3 build agents. Beyond that, TeamCity requires a commercial license. For most small-to-mid teams, the free tier covers needs for years.

EU-Native Alternatives: Zero CLOUD Act, Open Source

If you want to eliminate any JetBrains dependency entirely, three EU-native alternatives cover the TeamCity use case:

Option 1: Woodpecker CI (EU-native, FOSS)

Woodpecker CI is a community fork of Drone CI, fully open source (Apache 2.0), and has no commercial US entity. Actively maintained by a European-led community.

Strengths:

• YAML pipeline syntax very similar to GitHub Actions — easy migration
• Docker-based agents (isolated builds by default)
• Forgejo/Gitea native integration
• Plugin ecosystem (100+ official plugins)
• Matrix builds and parallelism

CLOUD Act Score: 0/25 — self-hosted, no vendor

Hetzner deployment:

# docker-compose.yml (Woodpecker)
version: "3"
services:
  woodpecker-server:
    image: woodpeckerci/woodpecker-server:latest
    environment:
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=https://git.yourdomain.eu
      - WOODPECKER_AGENT_SECRET=${AGENT_SECRET}
    volumes:
      - woodpecker-server-data:/var/lib/woodpecker
  woodpecker-agent:
    image: woodpeckerci/woodpecker-agent:latest
    environment:
      - WOODPECKER_SERVER=woodpecker-server:9000
      - WOODPECKER_AGENT_SECRET=${AGENT_SECRET}

Pipeline syntax example (.woodpecker.yml):

steps:
  test:
    image: openjdk:21-slim
    commands:
      - ./gradlew test
  build:
    image: openjdk:21-slim
    commands:
      - ./gradlew build
    depends_on: [test]
  docker-push:
    image: woodpeckerci/plugin-docker-buildx
    settings:
      registry: registry.hetzner.eu
      repo: myapp
    depends_on: [build]
    when:
      branch: main

NIS2 Art.21 note: Woodpecker's event logs, build history, and secret vault are entirely within your infrastructure. No third-party processors in the GDPR Art.30 record.

Option 2: Forgejo Actions (Forgejo/Gitea-native CI)

Forgejo is a community fork of Gitea with a strong EU/European developer base. Forgejo Actions provides GitHub Actions-compatible CI/CD built directly into the Forgejo platform.

Strengths:

• 100% GitHub Actions YAML syntax compatibility — reuse existing workflows
• Single-platform: code + CI/CD + registry in one Forgejo instance
• Act runner is a drop-in replacement for GitHub Actions runner
• No separate server — CI is part of Forgejo

CLOUD Act Score: 0/25

Migration from TeamCity to Forgejo Actions:

• Export TeamCity Build Chains → map to GitHub Actions workflow_call / needs syntax
• TeamCity Parameters → GitHub Actions env: and inputs:
• TeamCity Artifacts → Forgejo artifact upload/download actions
• TeamCity Test History → Forgejo Actions test summary

Most GitHub Actions workflows work without modification on Forgejo Actions. Custom TeamCity features (composite builds, build chains) require translation, but Forgejo Actions' needs: syntax handles most cases.

Option 3: Tekton (CNCF, Kubernetes-native)

Tekton Pipelines is a CNCF project — open-source, no vendor, Kubernetes-native. Ideal if you are already running Kubernetes on Hetzner.

Strengths:

• Native Kubernetes resources (Tasks, Pipelines, PipelineRuns)
• Reusable Tasks across pipelines (Tekton Hub catalog)
• Event-driven via Tekton Triggers
• Integrated with supply chain security tools (Tekton Chains for SLSA provenance)

CLOUD Act Score: 0/25

SLSA Level 3 with Tekton Chains:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-sign
spec:
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.23.2
      args:
        - --context=/workspace/source
        - --destination=registry.hetzner.eu/myapp:$(params.IMAGE_TAG)
    - name: sign-provenance
      image: gcr.io/tekton-releases/github.com/tektoncd/chains/cmd/chains:v0.22.0

Tekton Chains automatically generates SLSA provenance attestations and signs them with Sigstore/cosign — meeting NIS2 Art.21(2)(d) supply chain security requirements at SLSA Level 3.

Migration Guide: TeamCity to Woodpecker CI

If you are moving from TeamCity to Woodpecker CI on Hetzner, here is a four-week migration plan:

Week 1: Infrastructure Setup

# Provision Hetzner servers
hcloud server create --name gitea-1 --type cpx21 --image ubuntu-24.04 --location fsn1
hcloud server create --name woodpecker-1 --type ccx13 --image ubuntu-24.04 --location fsn1
hcloud server create --name build-agent-1 --type cpx31 --image ubuntu-24.04 --location fsn1

# Install Gitea on gitea-1 (code hosting)
# Install Woodpecker Server on woodpecker-1
# Install Woodpecker Agent on build-agent-1

Cost: CPX21 (€7/mo) + CCX13 (€26/mo) + CPX31 (€19/mo) = €52/mo vs TeamCity Cloud Business at €384/mo.

Week 2: Mirror Critical Repositories

# Mirror TeamCity-connected repos to Gitea
# Export TeamCity build configurations via REST API
curl -H "Authorization: Bearer $TC_TOKEN" \
  https://teamcity.yourdomain.com/app/rest/buildTypes \
  > teamcity_configs.json

# Convert to Woodpecker YAML using the conversion script
python3 tc_to_woodpecker.py teamcity_configs.json

Week 3: Parallel Builds

Run both systems simultaneously for your most critical pipelines. Compare build outputs (artifact hashes, test counts, timing). Validate that the Woodpecker pipelines produce identical artifacts.

Week 4: Cutover

1. Update CI webhooks in Gitea to point to Woodpecker
2. Migrate TeamCity secrets to Woodpecker's secret store
3. Disable TeamCity build agents (not TeamCity itself — keep it for audit trail access)
4. Export TeamCity build history and store in your audit archive (NIS2 Art.21(2)(j))

TeamCity Cloud vs Self-Hosted Decision Matrix

Recommended Architecture for GDPR-Strict Environments

For organisations with strict GDPR requirements (healthcare, finance, public sector), the recommended stack is:

[Developer workstation]
    ↓ git push
[Forgejo on Hetzner fsn1 (Falkenstein, Germany)]
    ↓ webhook → Woodpecker CI trigger
[Woodpecker Server on Hetzner CCX13]
    ↓ dispatch to agents
[2× Woodpecker Build Agents on Hetzner CPX31]
    ↓ build artifacts
[Hetzner Container Registry (custom domain)]
    ↓ deploy
[Hetzner Cloud VMs / Kubernetes (k3s)]

GDPR Art.28 processor chain:

• Hetzner Cloud AG (Nuremberg, Germany) — NL Hetzner Online GmbH entity
• German law + GDPR governing
• No US sub-processors in standard setup
• Art.28 DPA: Hetzner publishes standard DPA at hetzner.com/legal/privacy-policy

CLOUD Act Score for entire stack: 0/25

This stack costs approximately €52-80/month for a 5-10 developer team and provides a complete CI/CD solution with no US jurisdictional exposure anywhere in the pipeline.

Conclusion

JetBrains TeamCity occupies a genuinely unique position: it is the only major enterprise CI/CD platform built by a European company (Czech Republic). Its CLOUD Act score of 6/25 reflects real EU provenance — not marketing claims about EU data centres with US parent companies.

For teams currently using GitHub Actions, Azure DevOps, or Jenkins CloudBees, switching to TeamCity Cloud represents a meaningful GDPR risk reduction while maintaining enterprise CI/CD capabilities. TeamCity self-hosted on Hetzner achieves 0/25 CLOUD Act exposure with full feature parity.

For teams prioritising open-source independence and zero vendor dependency, Woodpecker CI and Forgejo Actions offer a complete CI/CD stack with GitHub Actions compatibility, Hetzner deployment, and 0/25 CLOUD Act exposure at significantly lower cost.

The core principle that applies across all four options in this CI/CD series: your CI/CD pipeline processes your most sensitive assets — source code, signing keys, deployment credentials, and production artifacts. The jurisdiction of your CI/CD provider is not a detail — it determines who else has access to everything you build.

EU CI/CD Tools Series

Next: Post #5 — EU Enterprise CI/CD Comparison Finale: Full risk matrix, migration cost analysis, and which CI/CD stack is right for your organisation.

sota.io is an EU-native managed PaaS. Deploy any language or framework on Hetzner Germany — git push and you're live. No US parent company, no CLOUD Act exposure. Start free →