AWS CodeBuild EU Alternative 2026: CI/CD Pipelines, Source Code Jurisdiction, and EU-Sovereign Build Infrastructure

Post #695 in the sota.io EU Compliance Series

AWS CodeBuild is Amazon's fully managed continuous integration service. It compiles source code, runs tests, and produces deployment-ready build artifacts — without requiring organizations to provision or maintain dedicated build servers. CodePipeline, the orchestration layer that wraps CodeBuild, coordinates the full CI/CD workflow: source retrieval, build execution, test stages, approval gates, and deployment actions across AWS and third-party services.

For engineering teams that adopted CodeBuild during AWS's push for native DevOps tooling, the value proposition is real: no build server maintenance overhead, elastic scaling for concurrent builds, native AWS service integration, and a managed environment that applies security patches without operator intervention. CodeBuild fits naturally into the broader AWS ecosystem — ECR for container images, S3 for artifacts, CloudWatch for logs, IAM for service access, Secrets Manager for build-time secrets.

The GDPR and CLOUD Act analysis of CodeBuild follows the same structural logic as every other AWS service in this series with one critical distinction: CodeBuild processes your source code. Not just runtime configuration or operational metadata — the actual application source code, infrastructure definitions, test suites, and all repository contents pass through AWS-managed build infrastructure during every build execution. For EU organizations processing personal data, the build pipeline is frequently the highest-sensitivity point in the entire deployment chain. Compliance engineers who have analyzed the runtime (App Runner, Fargate, ECS) and the storage layer (RDS, S3, DynamoDB) sometimes overlook the CI/CD layer — but source code repositories, build scripts, and artifact stores carry their own data sovereignty obligations that CodeBuild brings under US-entity jurisdiction.

What CodeBuild and CodePipeline Store Under US Jurisdiction

The data footprint of a CodeBuild-based CI/CD pipeline spans several AWS services. Understanding the full surface requires mapping the pipeline from source retrieval through artifact delivery.

Source code access and repository cloning. Every CodeBuild build begins with source retrieval. CodeBuild supports GitHub (via OAuth or personal access tokens), GitHub Enterprise, Bitbucket, AWS CodeCommit, and Amazon S3 as source providers. During each build execution, CodeBuild clones the specified repository reference — branch, tag, or commit SHA — into the managed build environment.

This means every file in the repository is accessible to the AWS-managed build infrastructure for the duration of the build. Source code, including application logic, infrastructure definitions (Terraform, CloudFormation, Kubernetes manifests), internal API client libraries, database schema migration scripts, and any credentials or secrets accidentally committed to version history, passes through AWS infrastructure under Amazon Web Services, Inc. jurisdiction. The cloned repository content is not stored persistently by CodeBuild after build completion, but it is processed on AWS servers and is accessible to CLOUD Act production orders during the build window.

For organizations using CodePipeline with GitHub as the source provider, CodePipeline additionally stores a copy of the source artifact — a ZIP archive of the repository contents at the triggered commit — in an S3 bucket managed by CodePipeline. This artifact persists beyond the build execution and is retained per the S3 bucket's lifecycle policy. The default CodePipeline configuration does not automatically expire these source artifacts; they accumulate in S3 storage under AWS management.

Build environment variables and parameter injection. CodeBuild build environments accept environment variables through three channels: plaintext variables defined in the build project configuration, variables retrieved from AWS Systems Manager Parameter Store at build time, and variables retrieved from AWS Secrets Manager at build time.

Plaintext environment variables in the CodeBuild project configuration are stored in the CodeBuild service configuration and are retrievable via the AWS API. These commonly include non-sensitive configuration values (environment names, region identifiers, service endpoints) but frequently also include values that should be treated as secrets (API keys, database hostnames, service tokens). The AWS documentation recommends using Secrets Manager or Parameter Store for sensitive values, but the actual usage pattern in production CodeBuild configurations shows significant plaintext secret storage in environment variables.

Environment variables injected from Secrets Manager are accessed by CodeBuild at build start. The Secrets Manager service, IAM role permissions governing the access, and the resolved secret values during the build all operate under US-entity AWS jurisdiction. The secrets themselves remain in Secrets Manager storage; the build environment receives the resolved values.

Build artifacts in Amazon S3. CodeBuild outputs build artifacts — compiled binaries, container images, deployment packages, test reports, static assets — to designated S3 buckets. The artifact storage is persistent: unlike the ephemeral build environment, artifacts remain in S3 until explicitly deleted or expired via lifecycle policy.

Build artifacts contain the compiled representation of your application source code. For container-based deployments, the artifact may be a container image pushed to ECR (with ECR storing the compiled application layers). For serverless deployments (Lambda, API Gateway), the artifact is a ZIP package containing compiled code. For static frontends, the artifact is the output of the build process — HTML, JavaScript bundles, CSS, and assets derived from the source code and build tooling.

S3 artifacts are stored under Amazon Web Services, Inc. jurisdiction and are accessible to CLOUD Act production orders. Organizations with GDPR obligations around source code protection (particularly relevant under trade secret provisions that intersect with GDPR data protection principles) should include S3 artifact storage in their data mapping under Article 30.

CloudWatch Logs: build logs and pipeline execution records. CodeBuild streams build log output to CloudWatch Logs by default. Build logs capture the complete console output of the build process: compilation output, test results, command execution records, dependency installation logs, and any diagnostic information printed by the build script. Build logs frequently contain more sensitive information than runtime application logs because the build process operates with elevated permissions and often connects to multiple infrastructure services.

Common sensitive data patterns in CodeBuild logs include: partial credential values printed by misconfigured tooling, internal service endpoints revealed during connectivity testing, dependency vulnerability scan results that reveal the application's security posture, and infrastructure resource identifiers (VPC IDs, subnet IDs, security group IDs) from Terraform or CloudFormation operations executed during build.

CloudWatch Logs for CodeBuild retain the full build history. Default retention is indefinite. Organizations subject to GDPR storage limitation principles (Article 5(1)(e)) should configure explicit retention periods for CodeBuild logs and document the retention rationale in Article 30 records.

CodePipeline additionally generates execution history records in the Pipeline service, storing pipeline run metadata (source commit SHAs, stage transitions, approval actions, deployment results) with indefinite default retention.

CodeCommit: source code repository under AWS management. For organizations using AWS CodeCommit (AWS's managed Git service) as the source provider, the repository itself — the complete version-controlled history of the codebase, including all commits, branches, tags, and file history — is stored under AWS management and subject to CLOUD Act jurisdiction. CodeCommit stores not just the current state of the code but the full commit history, enabling reconstruction of the entire development trajectory of the application.

While GitHub-hosted repositories involve a separate US-entity chain (GitHub, Inc., a subsidiary of Microsoft Corporation), the analysis for CodeCommit is simpler: AWS controls the repository infrastructure directly. The privacy implications of the full commit history in CodeCommit extend beyond the current source code — historical commits may contain credentials, personally identifiable data, internal architecture documentation, and business logic that was subsequently removed but remains accessible in the commit history.

IAM roles and service connection configurations. CodeBuild service roles — IAM roles that grant the build environment permission to access AWS services during the build — are stored in IAM under AWS management. The permission set defined in the CodeBuild service role reveals the access scope the build environment has to the broader AWS infrastructure: S3 bucket access, ECR push permissions, Secrets Manager read access, VPC access, and potentially cross-account permissions.

CodePipeline connection configurations for third-party source providers (GitHub connections via AWS CodeStar Connections) store OAuth tokens and webhook configurations that grant AWS access to the source repository. These connection objects are stored under AWS management.

The Source Code Jurisdiction Problem

The central compliance concern with CodeBuild is not unique to it — it applies to any managed CI/CD service operated by a US entity. But it is more acute for CodeBuild than for runtime services because source code carries higher sensitivity than runtime data for most organizations.

Source code as personal data. EU data protection law does not categorically classify source code as personal data. However, source code frequently contains personal data in ways that matter for GDPR compliance:

• Developer identification. Git commits embed committer name and email address. When CodeBuild retrieves a repository, the commit metadata — including developer names, email addresses, and the timeline of their contributions — is processed by AWS infrastructure.
• Test fixtures with real data. Test suites frequently include fixtures derived from real user data. Database seed files, API response mocks, and unit test fixtures sometimes contain real email addresses, user IDs, or other identifiers that should be considered personal data under GDPR.
• Configuration with personal data references. Configuration files in source repositories may contain examples with real email addresses, user IDs used for testing, or references to specific individuals in comments.

For organizations processing any of these categories, CodeBuild processing constitutes personal data transfer to a US entity, requiring the standard GDPR Chapter V legal basis (SCCs via AWS DPA, with accompanying Transfer Impact Assessment).

Source code as business-confidential data. Beyond personal data, source code represents the core intellectual property of software organizations. Trade secret protection, competitive confidentiality, and client data handling obligations all apply to source code. The CLOUD Act risk assessment for CodeBuild must address: under what circumstances could a CLOUD Act production order require Amazon to provide access to source code stored in CodePipeline S3 artifacts or processed during CodeBuild execution? This question is more consequential than the equivalent question for runtime infrastructure, because source code exposure has no equivalent technical remediation — encrypted-at-rest source code must be decrypted for the build environment to function.

The GDPR and CLOUD Act Analysis

GDPR Article 28 Data Processing Agreement. AWS's DPA covers CodeBuild, CodePipeline, and all underlying services. The DPA provides Standard Contractual Clauses for Chapter V compliance. For source code processing, the DPA coverage means AWS acts as a data processor for personal data contained in source code and build artifacts.

Transfer Impact Assessment for build pipeline data. The TIA for CodeBuild must address categories that differ from runtime service TIAs: source code content, build artifact content, developer identity data in commit metadata, and build environment secrets. The sensitivity assessment for these categories is typically higher than for runtime metrics or application logs.

The CLOUD Act compulsion probability assessment for CodeBuild should consider: Is the source code or artifacts of interest to US law enforcement or national security apparatus? For most commercial EU software organizations, the probability is low. But the scope of CLOUD Act production orders is not limited to active criminal investigations — civil enforcement actions and national security investigations also qualify. Organizations building security-sensitive applications, financial infrastructure, or applications touching US-regulated data categories should weight this probability assessment carefully.

NIS2 Article 21 and CI/CD supply chain security. NIS2 Article 21(2)(e) requires entities to implement security measures covering the full ICT supply chain. The build pipeline is part of the ICT supply chain for software-based services. NIS2 supervisory authorities — particularly in Germany (BSI), France (ANSSI), and the Netherlands (NCSC-NL) — have specifically highlighted CI/CD pipeline security as a supply chain attack vector requiring explicit security controls.

CodeBuild provides managed environment security (patch management, isolated build environments, no persistent state between builds). But NIS2 supply chain security also requires that the CI/CD provider itself is evaluated as a third-party ICT service provider, including assessment of its incident history, security certifications, and the contractual protections available in case of a security incident affecting the build pipeline.

DORA Article 28 exit planning for build infrastructure. For financial entities subject to DORA, the build pipeline is part of the ICT infrastructure supporting financial services. DORA Article 28 requires documented exit strategies for critical third-party ICT service dependencies. A CodeBuild/CodePipeline exit plan must address: Can the build process be reproduced outside AWS using the same Dockerfile/buildspec.yml? Are the CodePipeline stage configurations documented in version-controlled infrastructure code? Can the CI/CD workflow be migrated to an alternative provider (GitLab CI, Woodpecker, GitHub Actions) within the DORA-required recovery time objective?

DORA supervisory authorities (ECB, national competent authorities) expect exit plans to be concrete and tested, not theoretical documentation. For CodeBuild exit planning, this means actually running the build process outside AWS at least once during the annual testing cycle.

EU-Native CI/CD Alternatives to CodeBuild

For EU organizations that want CodeBuild's managed CI/CD capabilities without the CLOUD Act exposure, the alternatives span fully managed EU-sovereign services, self-hosted options on EU infrastructure, and hybrid approaches.

sota.io native Git-push deployment. sota.io provides git-push-to-deploy functionality that eliminates the need for a separate CI/CD pipeline for deployment use cases. The application build and deployment process occurs on Hetzner infrastructure under EU legal entity control — no AWS build pipeline in the chain. For teams using CodeBuild primarily to build and deploy application code (rather than complex multi-stage test pipelines), sota.io's native deployment workflow covers the primary use case without requiring a separate CI/CD service. Container builds, environment management, TLS, and deployment orchestration are handled by the platform itself.

Woodpecker CI on Hetzner. Woodpecker CI is an open-source CI/CD system (fork of Drone CI) that runs on self-managed infrastructure. Deployed on Hetzner Cloud (Hetzner Online GmbH, a German company with no US parent), Woodpecker provides a full CI/CD pipeline with no external service dependencies. Pipeline definitions are YAML-based and compatible with Drone CI configurations. Source code is cloned from the organization's version control system (Gitea, self-hosted GitLab, or external providers) directly into the Woodpecker runner environment on Hetzner — the source code never leaves EU-sovereign infrastructure during the build process.

Gitea with Gitea Actions on Hetzner. Gitea is an open-source Git hosting service that includes a CI/CD system (Gitea Actions) compatible with GitHub Actions workflow syntax. Self-hosted on Hetzner, Gitea provides both the source code repository (replacing CodeCommit) and the CI/CD pipeline (replacing CodeBuild) under a single EU-sovereign deployment. Organizations migrating from CodeCommit + CodeBuild can replicate both services in a single Hetzner-hosted Gitea instance.

Self-hosted GitLab CE on Hetzner. GitLab Community Edition provides the most feature-complete self-hosted CI/CD alternative to CodeBuild. GitLab CE is open-source and includes container registry, CI/CD pipelines, merge request workflows, package registry, and security scanning — the full DevSecOps platform. Deployed on Hetzner infrastructure, GitLab CE keeps source code, build artifacts, and pipeline logs entirely on EU-sovereign servers. The operational cost is higher than managed CodeBuild (GitLab CE requires server maintenance, updates, and backup management), but the compliance profile is unambiguous: no US-entity involvement in the build pipeline.

GitHub Actions with self-hosted runners on Hetzner. GitHub, Inc. is a US entity (Microsoft subsidiary), so the GitHub control plane — repository hosting, Actions workflow configuration, workflow logs stored in GitHub — falls under US jurisdiction. However, organizations that must keep source code on GitHub (existing workflows, team familiarity, external contributor access) can address the build execution jurisdiction by using self-hosted GitHub Actions runners on Hetzner. Build execution — the actual compilation, testing, and artifact production — occurs on Hetzner infrastructure rather than GitHub-managed runners. Build artifacts can be pushed directly to EU-sovereign storage (Hetzner Object Storage, self-hosted Nexus, or sota.io) rather than GitHub Artifacts storage.

This hybrid approach limits (but does not eliminate) US-entity jurisdiction: the GitHub control plane still stores repository metadata, commit history, and workflow trigger information. Organizations with strict requirements should use a fully EU-sovereign solution. But for organizations where GitHub repository access is a business constraint, self-hosted runners substantially reduce the CLOUD Act surface.

Scaleway Managed Containers + CI/CD. Scaleway (Iliad Group, a French company) provides container registry and CI/CD capabilities on EU-sovereign infrastructure. For organizations already using Scaleway for compute or managed databases, Scaleway's build and registry services provide an EU-sovereign CodeBuild alternative within a unified cloud account.

Migration Path from CodeBuild to EU-Native CI/CD

The migration complexity from CodeBuild to EU-native CI/CD depends primarily on the complexity of the existing build configuration.

Simple buildspec.yml migrations. AWS CodeBuild uses a buildspec.yml file to define the build process — phases (install, pre_build, build, post_build), environment variable injection, and artifact configuration. For simple build configurations (dependency installation, test execution, container image build and push), the buildspec.yml maps directly to equivalent Woodpecker CI, Gitea Actions, or GitLab CI pipeline definitions. The build logic itself — the shell commands that compile code, run tests, and produce artifacts — is portable and requires no modification.

Secrets migration. Build-time secrets stored in Secrets Manager or Parameter Store require migration to the target CI/CD system's secrets management. Woodpecker CI stores secrets as encrypted values accessible to pipeline steps. GitLab CI uses CI/CD variables with masking. Gitea Actions uses encrypted secrets equivalent to GitHub Actions secrets. The migration process is: export secret names from Secrets Manager (not values — retrieve values directly at migration time), create corresponding secrets in the target CI/CD system, update pipeline configuration to reference the new secret names.

CodePipeline stage migration. CodePipeline's multi-stage pipeline model (Source → Build → Test → Deploy) maps to standard CI/CD pipeline stage definitions in all alternatives. The approval gate functionality (requiring manual sign-off before production deployment) is available in GitLab CE (Protected Environments + required approvals), Woodpecker CI (manual step triggers), and Gitea Actions (environment protection rules). The deployment stage — which may invoke ECS, App Runner, Lambda, or other AWS services — may require redesign if the deployment target itself is being migrated to EU-sovereign infrastructure.

The Compliance Summary

AWS CodeBuild and CodePipeline provide managed, scalable CI/CD infrastructure that removes build server maintenance from engineering teams. For EU organizations processing personal data, the compliance profile of CodeBuild centers on a category of data that is more sensitive than runtime data: source code and build artifacts pass through Amazon Web Services, Inc. infrastructure under CLOUD Act jurisdiction during every build execution.

The GDPR TIA for CodeBuild must address source code content, developer identity data in commit metadata, build artifacts, and build environment secrets — all processed under US-entity jurisdiction. NIS2 supply chain security obligations apply to the build pipeline as part of the ICT supply chain. DORA exit planning requirements extend to CI/CD infrastructure for financial entities, requiring documented and tested migration procedures.

For organizations where build pipeline data sovereignty is a compliance requirement — whether driven by GDPR TIA results, NIS2 supervisory guidance, DORA exit planning obligations, or sector-specific regulations — the alternatives to CodeBuild are mature and deployable on EU-sovereign infrastructure. sota.io eliminates the need for a separate build pipeline for deployment use cases by providing native Git-push workflows on Hetzner infrastructure. Self-hosted Woodpecker CI, Gitea, or GitLab CE on Hetzner provide full CI/CD pipeline capabilities with no US-entity involvement in the build process.

See Also

• AWS CodeDeploy EU Alternative — Deployment automation: AppSpec lifecycle scripts and deployment agents as a US-jurisdiction operational control channel; GDPR and NIS2 analysis for CodeDeploy.
• AWS CodeCommit EU Alternative — Source code and Git history under US jurisdiction; CLOUD Act implications for intellectual property stored in CodeCommit.
• AWS CodePipeline EU Alternative — Orchestration layer connecting CodeBuild, CodeCommit, and CodeDeploy; how CodePipeline amplifies individual-service CLOUD Act exposure across the full CI/CD stack.

The practical migration path from CodeBuild is lower-friction than it appears: buildspec.yml configurations translate directly to standard pipeline YAML, secrets migrate through standard secret management APIs, and the build logic itself — the shell commands that compile and test software — is entirely portable. The question for engineering teams is not whether migration is technically feasible, but whether the CLOUD Act exposure of the current build pipeline is documented, assessed, and accepted, or whether it should be resolved.