AWS CodeCatalyst & CodeStar EU Alternative 2026: Developer Portals, OAuth Token Exchange, and the CLOUD Act Developer Toolchain Gap

Post #791 in the sota.io EU Compliance Series

AWS deprecated CodeStar in July 2024. Its replacement, CodeCatalyst, is not in the AWS European Sovereign Cloud catalog.

This is not a minor gap. For EU development teams who need a developer portal — a centralized hub that connects source control, CI/CD, project management, and team access — AWS has no ESC-eligible option. Combined with CodeArtifact (also absent from ESC) and the CodeBuild/CodePipeline pair (ESC-eligible but deeply integrated with non-ESC services), the AWS developer toolchain presents a systematic CLOUD Act exposure that no ESC migration path resolves.

This guide covers what CodeCatalyst processes about your development team, why it matters under GDPR, and the EU-sovereign alternatives that provide equivalent developer portal functionality without US-jurisdiction data exposure.

CodeStar Deprecated, CodeCatalyst Not Sovereign

AWS CodeStar was a developer portal service that allowed teams to manage AWS-hosted projects with integrated source control (AWS CodeCommit, GitHub, Bitbucket), CI/CD pipelines, issue tracking (Jira, GitHub Issues), and IDE integrations (Cloud9, VS Code, IntelliJ).

In July 2024, AWS announced the end of CodeStar. New project creation was stopped. Existing projects continue to run until the service reaches its final end-of-life. CodeCatalyst is the designated successor.

CodeCatalyst's core capabilities:

• Unified dev environment (Dev Environments — cloud-based IDE instances)
• Source repositories (built-in Git hosting via connected GitHub/GitHub Enterprise/Bitbucket repositories)
• Workflows (CI/CD pipeline builder)
• Project blueprints (opinionated project templates for full-stack applications)
• Issues and backlogs (built-in project management)
• Team management with SSO integration

What CodeCatalyst is not: An AWS European Sovereign Cloud service. As of 2026, CodeCatalyst appears in the general AWS service catalog but is absent from the ESC service tiers. This means EU organizations that need GDPR-compliant developer tooling with ESC-grade data residency guarantees cannot use CodeCatalyst as a sovereign alternative.

The Four GDPR Obligations AWS CodeCatalyst Triggers

1. CLOUD Act: OAuth Token Exchange as Third-Country Transfer

CodeCatalyst's most significant GDPR exposure is its integration model. Unlike a standalone service that processes only your code, CodeCatalyst acts as an OAuth broker — it requests and stores access tokens to connect with external repositories.

When you link a GitHub organization, GitHub Enterprise instance, or Bitbucket workspace to CodeCatalyst:

1. You authorize CodeCatalyst to access your repository via OAuth 2.0
2. AWS stores the resulting OAuth access token (or refresh token) in its infrastructure
3. CodeCatalyst uses that token to clone repositories, trigger webhooks, report CI/CD status, and synchronize Issues

The CLOUD Act exposure: The OAuth token stored by CodeCatalyst is a credential that grants access to your source code repository. Under the CLOUD Act, US federal authorities can compel AWS to produce this token. Possession of the token grants read access to your private repositories — including all source code, all commit history, all pull request discussions, and all branch contents.

For EU organizations hosting proprietary code, client data processing logic, or regulated-sector applications in GitHub or Bitbucket, an OAuth token stored on US infrastructure represents a third-country transfer risk that goes beyond the code itself: it creates a compelled-access pathway into external repositories that are not AWS infrastructure.

This exposure is not covered by standard AWS SCCs (Standard Contractual Clauses). The SCCs address AWS's processing of your data. The OAuth token exposure pathway leads to repositories hosted by GitHub (a Microsoft subsidiary) or Atlassian — different data controllers with separate data processing agreements. The CLOUD Act access pathway bypasses all of them.

Art.46 requirement: For EU organizations using CodeCatalyst's repository integration features, the OAuth token storage on US infrastructure constitutes a transfer to a third country requiring a valid transfer mechanism — and a Transfer Impact Assessment that accounts for the CLOUD Act compelled-access risk to the linked external repositories.

2. Art.28 DPA: Third-Party Repository Integration Processing Scope

The Art.28 GDPR processor agreement you sign with AWS covers AWS's processing of data you store in AWS services. It does not clearly delineate the processing boundaries for data that CodeCatalyst accesses via the OAuth integrations it manages.

When CodeCatalyst connects to your GitHub organization via OAuth, it accesses:

• Repository metadata (names, visibility, branch structure, collaborator lists)
• Commit history (author names, email addresses, commit messages, timestamps)
• Pull request data (descriptions, review comments, reviewer assignments)
• Issue data (if GitHub Issues are linked to CodeCatalyst project management)
• Webhook payloads (which include full push event payloads with commit contents)

Commit messages and pull request descriptions may contain personal data — developer names, client references, ticket numbers referencing individuals, and occasionally credentials or API keys committed accidentally. Author email addresses embedded in git commits are personal data under Art.4(1).

The DPA gap: AWS's Art.28 DPA covers processing of data you upload to AWS. The processing of commit metadata fetched from GitHub via OAuth into CodeCatalyst's project management interface is less clearly scoped. When CodeCatalyst renders pull request information in its workflow interface, is it processing GitHub-hosted personal data as a sub-processor of GitHub, or as an independent controller? The answer affects your obligations under Art.26 (joint controllers) and Art.28 (processor requirements).

This ambiguity should be resolved contractually before deploying CodeCatalyst to manage active development projects involving EU developer data.

3. Art.5(1)(c) Data Minimisation: Dev Environment Telemetry and Linked Identity Processing

CodeCatalyst Dev Environments are cloud-based development environments that run on AWS infrastructure. When a developer opens a Dev Environment, CodeCatalyst records:

• The developer's linked identity (AWS Builder ID or AWS IAM Identity Center credentials)
• Session start and stop times
• The repository and branch checked out
• Resource consumption metrics (CPU, memory, storage)
• Actions taken within the environment (file saves, terminal commands if instrumented, extension activations)

The linked identity model is particularly relevant under Art.5(1)(c) data minimisation. CodeCatalyst links developer identities across multiple AWS services: the same AWS Builder ID that authenticates to CodeCatalyst may be used across other AWS services. This creates a cross-service identity graph.

The minimisation question: For EU development teams, the question is whether the telemetry CodeCatalyst collects to support billing (resource consumption), feature usage analytics, and security audit logging is minimal and proportionate under Art.5(1)(c), or whether the linked identity model creates a behavioral profile of individual developers that exceeds what is necessary for the stated processing purposes.

AWS does not provide granular data minimisation controls for CodeCatalyst's internal telemetry. You cannot disable session duration logging, resource usage tracking, or the identity linking that ties Developer IDs to workflow activity.

4. Art.17 Right to Erasure: Project Blueprint Data Retention

CodeCatalyst project blueprints are opinionated project templates. When you create a project from a blueprint, CodeCatalyst forks a template repository into your CodeCatalyst space and populates it with project scaffolding. If developer names, email addresses, or other personal data are embedded in blueprint configuration (a common occurrence in enterprise blueprints with committed author information), those entries appear in the git history of the forked repository.

Satisfying an Art.17 erasure request for a developer who leaves your organization requires:

1. Identifying all git commits attributed to that developer across all CodeCatalyst-managed repositories
2. Rewriting git history to remove those attributions (git filter-branch or BFG)
3. Confirming that CodeCatalyst's internal database records referencing that developer (workflow runs, issue assignments, review comments) have been deleted or anonymized
4. Verifying that Dev Environment session logs referencing that developer's identity have been purged

AWS does not provide tooling that automates this process for CodeCatalyst. The erasure obligation requires manual coordination across git history (external repositories connected via OAuth), CodeCatalyst's own database, and AWS CloudWatch logs (if Dev Environment metrics are exported there).

The Complete AWS Developer Toolchain ESC Coverage Map

Understanding CodeCatalyst's ESC status requires situating it in the broader AWS developer toolchain picture.

The pattern is clear: AWS's execution infrastructure (CodeBuild, CodePipeline) has ESC coverage. AWS's developer experience layer — the tools that handle developer identities, repository access, project management, and the SBOM/artifact intelligence layer — does not.

For EU organizations building on AWS, this means:

• You can run compliant CI/CD pipelines using ESC-eligible CodeBuild + CodePipeline
• You cannot use AWS's own developer portal (CodeCatalyst) with ESC data residency guarantees
• You cannot use AWS's own package registry (CodeArtifact) with ESC data residency guarantees
• Your developers' identities, OAuth tokens, Dev Environment sessions, and project telemetry all flow through non-ESC infrastructure

EU-Sovereign Alternatives

Gitea

Gitea is a lightweight, self-hosted Git service written in Go. It has grown from a simple Git hosting platform into a capable developer portal covering most of what CodeStar and CodeCatalyst offered.

Capabilities relevant to CodeCatalyst replacement:

• Git repository hosting with web UI, code review, and branch protection
• Built-in issue tracker with labels, milestones, and project boards
• CI/CD via Gitea Actions (compatible with GitHub Actions workflow syntax)
• Package registry (npm, Maven, PyPI, Docker, Helm, generic — replacing CodeArtifact for many use cases)
• OAuth 2.0 provider (issue tokens to other services rather than consuming them from AWS)
• Team and organization management
• Webhook integration with external tools
• SSH and HTTPS access

Hosting requirements: A single Gitea instance handles teams of 50–200 developers on a Hetzner CX21 (2 vCPU, 4 GB RAM, €5.83/month). For high availability, a Hetzner CX31 with an external PostgreSQL database (managed via Hetzner DBaaS or Supabase EU) provides production-grade reliability.

Data sovereignty: Gitea processes all data — repositories, issues, OAuth tokens, user identities, CI/CD logs — on your infrastructure in your chosen EU datacenter. No CLOUD Act exposure. No third-country transfer risk for OAuth tokens.

Forgejo

Forgejo is a community-maintained fork of Gitea, created in 2022 after governance concerns about Gitea's organizational structure. It maintains full API and workflow compatibility with Gitea while operating under a fully open governance model (Codeberg e.V., a German non-profit).

Forgejo vs Gitea for EU compliance:

• Identical technical capabilities and data processing footprint
• Forgejo's governance under a German non-profit provides an additional layer of accountability for EU organizations with strict vendor governance requirements
• Both support Actions-compatible CI/CD, package registries, and OAuth 2.0 provider mode
• Forgejo's Federation feature (under active development) adds ActivityPub-based cross-instance repository sharing

For EU organizations in regulated sectors (healthcare, finance, legal) where vendor governance documentation is required for procurement, Forgejo hosted on EU infrastructure may be the stronger compliance story.

GitLab Community Edition (Self-Hosted)

For organizations that need deeper CI/CD capabilities, advanced security scanning integration, or compliance reporting (audit events, access certifications), GitLab CE provides a more comprehensive developer portal than Gitea/Forgejo.

Tradeoffs vs Gitea/Forgejo:

• Significantly higher resource requirements (minimum 8 GB RAM for a responsive instance)
• More complex setup and maintenance
• More powerful built-in CI/CD, container registry, security scanning, and compliance features
• Better fit for teams of 100+ developers

Hosting: Hetzner CCX13 (4 vCPU, 16 GB RAM, €30/month) or CX41 (4 vCPU, 8 GB RAM, €14/month). All data remains on EU infrastructure.

Migration from CodeCatalyst to Gitea/Forgejo

Step 1: Repository Migration

For repositories hosted in CodeCatalyst's built-in Git:

# Clone from CodeCatalyst
git clone https://git.codecatalyst.aws/v1/spaces/<space>/projects/<project>/repos/<repo>

# Add Gitea remote and push
git remote add gitea https://git.yourcompany.eu/<org>/<repo>.git
git push gitea --all
git push gitea --tags

For repositories connected via OAuth (GitHub, Bitbucket), the source remains unchanged — you are migrating the integration point from CodeCatalyst to Gitea's external tracker sync or Gitea Actions webhooks.

Step 2: CI/CD Workflow Migration

CodeCatalyst Workflows use YAML syntax:

Name: Build
SchemaVersion: "1.0"
Actions:
  Build:
    Identifier: aws/build@v1
    Configuration:
      Steps:
        - Run: npm ci && npm test

Gitea Actions uses GitHub Actions-compatible syntax:

name: Build
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Most CodeCatalyst workflow patterns have direct Gitea Actions equivalents. The main migration effort is in AWS service integrations (CodeBuild, S3 deployment targets) — replace these with equivalent Hetzner/EU service calls.

Step 3: OAuth Token Cleanup

After migrating off CodeCatalyst, revoke the OAuth applications you created in GitHub/Bitbucket for CodeCatalyst integration:

1. GitHub: Settings → Developer settings → OAuth Apps → Revoke CodeCatalyst access
2. Bitbucket: Account settings → App passwords → Delete CodeCatalyst entries

This is a mandatory Art.5(1)(e) storage limitation action: CodeCatalyst's OAuth tokens for your repositories should not persist after you stop using the service.

Step 4: Identity Migration

CodeCatalyst uses AWS Builder ID. Gitea uses its own user database (optionally connected to LDAP, SAML 2.0, or OAuth for SSO).

For EU organizations with an existing identity provider (Keycloak, Microsoft Entra ID EU-region, Authentik), Gitea's SAML 2.0 integration allows seamless SSO without additional identity infrastructure.

Cost Comparison

The cost differential is significant even before compliance considerations. Self-hosted Gitea or Forgejo costs approximately 95–97% less than CodeCatalyst at equivalent team sizes, while providing full data sovereignty.

Summary: The AWS Developer Toolchain ESC Gap

AWS CodeStar is gone. AWS CodeCatalyst — its replacement — is not in the European Sovereign Cloud catalog and has no announced ESC roadmap.

For EU development teams evaluating AWS for GDPR compliance:

1. CodeCatalyst's OAuth token broker model creates CLOUD Act exposure for linked repositories beyond AWS's own infrastructure
2. Third-party repo integration DPA gaps require explicit contractual resolution before using CodeCatalyst with active EU development projects
3. Dev Environment telemetry linked to developer identities across AWS Builder ID raises Art.5(1)(c) data minimisation questions
4. Art.17 erasure for departing developers requires manual coordination across CodeCatalyst's database, git history, and connected OAuth repositories

The EU-sovereign path is straightforward: Gitea or Forgejo on Hetzner, OVH, or Scaleway EU infrastructure provides full developer portal functionality — repository hosting, CI/CD, package registry, issue tracking, and team management — at a fraction of the cost, with complete data residency in EU jurisdiction.

The complete picture of AWS developer toolchain ESC coverage shows a clear pattern: execution infrastructure (CodeBuild, CodePipeline) has ESC options; the developer experience layer (CodeCatalyst, CodeArtifact) does not. EU teams building compliance-first development infrastructure should plan accordingly.

This post is part of the sota.io EU Cloud Compliance Series — systematic GDPR and CLOUD Act analysis of AWS managed services and their EU-sovereign alternatives.