AWS Cloud9 EU Alternative 2026: Browser-Based IDEs, Developer Keystroke Processing, and CLOUD Act Source Code Exposure

Post #792 in the sota.io EU Compliance Series

AWS Cloud9 was deprecated in late 2023. But the GDPR questions it raised — what happens when a developer's IDE runs on US-controlled cloud infrastructure — remain entirely relevant for every cloud-based development environment in 2026.

Cloud9's deprecation did not eliminate the category. Browser-based IDEs and remote development environments are more popular than ever: GitHub Codespaces, Gitpod, JetBrains Space, and Coder all offer cloud-hosted development workspaces where your code, your terminal sessions, your environment variables, and your keystrokes transit infrastructure you do not control. For EU development teams processing personal data or building regulated-sector applications, the question of where that IDE runs — and under what jurisdiction — is a live compliance concern.

This guide uses Cloud9 as the entry point for a broader analysis of cloud IDE GDPR obligations, explains why Cloud9 is not in the AWS European Sovereign Cloud catalog, and identifies the EU-sovereign alternatives that let you run remote development environments on European infrastructure.

What Was AWS Cloud9

AWS Cloud9 was a browser-based integrated development environment that ran entirely within AWS infrastructure. Unlike VS Code or JetBrains IDEs running locally, Cloud9's editor, terminal, file system, and language services all executed on an EC2 instance managed by AWS.

Core Cloud9 architecture:

• EC2-backed workspace: Each developer got a dedicated or shared EC2 instance running the Cloud9 agent
• Browser IDE: Code editing, syntax highlighting, and debugging ran in the browser — no local software required
• Integrated terminal: Direct bash access to the EC2 instance
• AWS service integrations: One-click connections to Lambda, API Gateway, and other AWS services
• Collaboration: Real-time collaborative editing with cursor and selection visibility for other users

Deprecation timeline: AWS announced Cloud9 deprecation in late 2023. New environment creation was disabled for standard accounts. Enterprise customers were given migration paths to alternative IDE options. As of 2026, Cloud9 is in maintenance mode — it operates but receives no new feature development, and AWS actively directs customers to alternatives.

ESC status: Cloud9 is absent from the AWS European Sovereign Cloud service catalog. Even before deprecation, it was never offered as a sovereign-tier service. For organizations that deployed Cloud9 for EU-regulated development work, the service sat outside the ESC boundary that would provide enhanced data residency and access control guarantees.

The Four GDPR Obligations a Cloud-Based IDE Triggers

The Cloud9 deprecation is instructive because it forces EU teams to evaluate what they actually need from a cloud IDE and what the compliance costs are. Any cloud-based IDE that replaces it faces the same four GDPR obligations.

1. Art.4(1): Developer Keystrokes and Code as Personal Data

The most fundamental GDPR question for cloud IDEs is whether the data they process constitutes personal data under Art.4(1) GDPR.

Keystrokes as personal data: When a developer types code in a cloud-based IDE, each keystroke is transmitted from the browser to the cloud infrastructure and rendered back. For collaborative IDEs, keystroke streams may include cursor positions, deletion patterns, and typing cadence — data that can be used to profile individual developers. Behavioral biometrics research has demonstrated that typing patterns are sufficiently unique to identify individuals with high accuracy. Whether keystroke data in a cloud IDE meets the Art.4(1) "identifiable natural person" threshold depends on whether the provider processes it in a way that could identify the developer — and most cloud IDEs associate sessions with authenticated user identities, making the link direct.

Developer identity in code: Source code itself frequently contains personal data. Developer names and email addresses appear in git commits, code comments, function documentation, and configuration files. Variable names, class names, and code structure can reflect the individual developer's cognitive patterns. In collaborative environments, code ownership metadata tracks which developer wrote which line.

Code that contains personal data: The application code being developed frequently processes personal data — user records, authentication tokens, database schemas containing personal information. When that code executes in a cloud IDE environment — during debugging, testing, or local execution — the personal data it processes may transit or be stored on cloud infrastructure subject to the IDE provider's data processing terms.

Art.4(1) compliance requirement: EU organizations using cloud IDEs should conduct a Data Protection Impact Assessment (DPIA) under Art.35 that addresses: (a) what developer behavioral data the IDE provider collects, (b) how long it is retained, (c) whether it is shared with third parties, and (d) whether it is subject to law enforcement access requests in the provider's jurisdiction.

2. CLOUD Act: Source Code Exposure via Browser-Based Infrastructure

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) authorizes US federal authorities to compel US-headquartered companies to produce data stored on servers they control, regardless of where those servers are physically located.

The Cloud9 exposure model: In Cloud9, source code was stored on an EC2 instance managed by AWS. The developer's working directory — containing all source files, configuration, dependencies, and environment — resided on AWS-controlled storage. Under the CLOUD Act, US authorities could compel AWS to produce any data from those EC2 instances, including the complete source code of whatever application the developer was building.

Why EU server location does not resolve this: The CLOUD Act's scope is jurisdictional, not geographic. A US company's obligation to comply with a CLOUD Act order does not depend on where its servers are located. Data stored in an AWS datacenter in Frankfurt, Paris, or Stockholm is equally accessible to US authorities via CLOUD Act orders as data in Oregon or Virginia, because compliance is compelled from the parent company — not the data center.

Regulated-sector risk: For EU organizations in financial services, healthcare, defense contracting, or public sector — all sectors where source code may contain regulated information — cloud IDE infrastructure represents a CLOUD Act exposure that standard contractual clauses and data processing agreements do not address. SCCs govern AWS's contractual obligations. The CLOUD Act creates a separate, non-contractual compelled-access pathway that SCCs explicitly cannot override.

The ESC carve-out: The AWS European Sovereign Cloud introduces operational and contractual controls that provide some insulation from CLOUD Act access for data in its perimeter. However, Cloud9 was never part of the ESC offering — meaning even organizations that had deployed Cloud9 in EU regions were outside the ESC protections.

Transfer Impact Assessment requirement: Any EU organization using Cloud9 for development work involving sensitive source code should have conducted a Transfer Impact Assessment under Art.46 GDPR that addressed the CLOUD Act risk. Given that Cloud9 is deprecated, the more pressing question is whether its successor environments — including AWS-native alternatives and third-party cloud IDEs — have equivalent exposures.

3. Art.32: Credentials and Secrets in Cloud Workspaces

Cloud-based development environments present a specific Art.32 security risk: the concentration of credentials, API keys, database passwords, and authentication tokens in a single, cloud-hosted location.

The credential surface in a cloud IDE:

• Environment variables: Cloud IDEs commonly allow developers to set environment variables for their workspace — including database connection strings, API keys, and service credentials
• .env files: Local environment files containing secrets are stored on the cloud workspace's file system
• SSH keys: Developers frequently add SSH keys to cloud workspace instances for git operations, server access, and service authentication
• AWS credential files: Cloud9 workspaces automatically received temporary AWS credentials via EC2 instance metadata — a feature that simplified AWS service access but also created a credential surface accessible to anyone who gained access to the workspace
• Browser-accessible terminal: Since the terminal runs in a browser, any credentials visible in the terminal output are transmitted over the network and potentially stored in browser session data

The Art.32 obligation: GDPR Art.32 requires "appropriate technical and organisational measures" to ensure security appropriate to the risk. For cloud IDE environments, this includes:

• Encryption of secrets at rest in the cloud workspace
• Access controls that prevent one developer from accessing another's workspace credentials
• Audit logging of credential access and workspace activity
• Mechanisms to revoke and rotate credentials when a workspace is deleted or a developer leaves

Cloud9's credential model: Cloud9's EC2-backed architecture meant that the workspace's security posture depended on the security of the EC2 instance, the IAM role attached to it, and the network security groups configured around it. AWS Secrets Manager and Parameter Store were recommended for managing secrets rather than environment variables — but the recommendation was not enforced, and many Cloud9 deployments used environment variables for convenience.

Regulatory exposure: For organizations subject to NIS2 (EU Network and Information Security Directive 2022/0383), the concentration of production credentials in cloud development environments is a reportable incident risk — a compromise of the cloud IDE represents not just a development environment breach but a potential pathway to production systems.

4. CodeStar Connections: OAuth Token Persistence

AWS Cloud9 was tightly integrated with the broader AWS developer toolchain, including CodeStar Connections — the AWS service that manages OAuth-based connections to GitHub, GitHub Enterprise, Bitbucket, and GitLab.

The OAuth token persistence problem: When a Cloud9 developer connected to an external repository via CodeStar Connections:

1. The developer authorized AWS to access their repository via OAuth
2. AWS stored the resulting OAuth access token in CodeStar Connections
3. Cloud9 used that token to clone repositories, push commits, and trigger CI/CD pipelines

The OAuth token persisted in CodeStar Connections beyond the lifetime of the individual Cloud9 workspace. Even after a Cloud9 environment was deleted, the CodeStar Connection — and its associated OAuth token — remained active until explicitly revoked.

GDPR implications of token persistence: An OAuth access token to a GitHub organization is a form of credential that grants ongoing access to repository data. Under GDPR's storage limitation principle (Art.5(1)(e)), personal data should be retained only as long as necessary for its processing purpose. An OAuth token connected to a Cloud9 workspace that no longer exists serves no processing purpose — yet it persists and continues to represent an access pathway into the developer's repositories.

Audit gap: Most organizations that deployed Cloud9 did not systematically audit their CodeStar Connections inventory. Developers created OAuth connections for specific projects, and those connections accumulated over time. A GDPR Art.5(1)(e) compliant practice would require auditing all CodeStar Connections, identifying those no longer associated with active Cloud9 workspaces or active pipeline needs, and revoking the associated OAuth tokens.

Migration risk: Organizations migrating away from Cloud9 — whether due to deprecation or compliance concerns — should include a CodeStar Connections audit in their migration checklist. Active OAuth tokens from legacy Cloud9 workspaces represent ongoing exposure even after the workspaces themselves are deleted.

AWS European Sovereign Cloud: Cloud9 Is Not Listed

The AWS European Sovereign Cloud, launched in January 2026, provides enhanced data residency controls, operational sovereignty guarantees, and access restrictions for a subset of AWS services. The ESC service catalog includes core infrastructure services — EC2, S3, RDS, Lambda — along with networking and security tooling.

Cloud9 is not in the ESC catalog. Given its deprecation status, it is unlikely to be added. This means:

1. Organizations that used Cloud9 for EU-regulated development work were operating outside the ESC perimeter even for EU-region deployments
2. No ESC migration path exists for Cloud9 workloads — organizations must migrate to a different IDE solution rather than simply enabling ESC features
3. The gap reinforces the broader AWS developer toolchain ESC coverage issue (CodeArtifact, CodeCatalyst, and Cloud9 all absent from ESC)

For EU teams doing compliance-sensitive development, the Cloud9 deprecation combined with ESC absence means the path forward requires moving off AWS IDE infrastructure entirely.

EU-Sovereign Cloud IDE Alternatives

Eclipse Theia

Eclipse Theia is an open-source, VS Code–compatible IDE framework developed under the Eclipse Foundation (a European open-source foundation headquartered in Brussels, Belgium).

Architecture: Theia is not a hosted service — it is a framework that you deploy and host. It runs as a Node.js application, can be containerized with Docker, and exposes a browser-based IDE via HTTP. VS Code extensions are largely compatible.

Sovereignty profile:

• Open-source under Eclipse Public License 2.0
• No telemetry to US-jurisdiction services (configurable)
• Deployable on Hetzner, OVHcloud, Ionos, or any EU infrastructure
• European Foundation governance — no CLOUD Act jurisdiction over the software itself

Self-hosting on Hetzner: A basic Theia deployment on Hetzner CX21 (€5.77/month, 2 vCPU, 4 GB RAM) provides per-developer isolated workspaces. For team deployments, Theia Blueprint — the pre-packaged Theia distribution — provides a configurable starting point.

Use case fit: Theia is ideal for organizations that want to self-host with minimal third-party dependencies. The tradeoff is operational overhead — you manage the deployment, updates, and workspace lifecycle yourself.

Cost comparison: Hetzner CX21: €5.77/month per workspace vs. Cloud9's EC2-backed workspaces (m4.large: ~€85/month). For teams of 5–10 developers, the cost difference is substantial.

Gitpod (Self-Hosted)

Gitpod is an open-source cloud development environment platform that provides ephemeral, pre-configured workspaces from git repository configurations (.gitpod.yml files).

Architecture: Gitpod Self-Hosted runs on Kubernetes (k3s for smaller deployments, standard K8s for production) and provides workspace orchestration, workspace image management, and an administrative dashboard. Workspaces are ephemeral by default — they spin up from a git branch and are deleted after a configurable idle timeout.

Sovereignty profile:

• Gitpod Self-Hosted is open-source (AGPL)
• German company (Gitpod GmbH, Kiel, Germany)
• Self-hosted deployment means your code and workspaces stay on infrastructure you control
• No mandatory telemetry to Gitpod's cloud service when self-hosted

Gitpod on Hetzner: Gitpod's recommended self-hosted stack for small teams uses k3s on Hetzner dedicated servers. Recommended minimum: 1 × Hetzner AX41-NVMe (€36.90/month, 8 cores, 64 GB RAM) supporting 10–15 concurrent workspaces.

.gitpod.yml workflow: Developers open a workspace with one click from their git hosting interface. Gitpod clones the repository into an isolated container, runs the initialization commands from .gitpod.yml, and presents a VS Code–compatible browser IDE. Workspaces are deleted automatically after inactivity, preventing credential accumulation.

Use case fit: Gitpod is ideal for teams that want ephemeral workspaces and pre-configured environments. The ephemeral model directly addresses the Art.5(1)(e) storage limitation concern — credentials and code do not persist beyond the workspace lifetime.

Cost comparison: Hetzner AX41-NVMe at €36.90/month for a 10-developer team = €3.69/developer/month vs. Cloud9's EC2 costs. For regulated-sector organizations, this represents both cost reduction and compliance improvement.

Coder

Coder is an open-source remote development platform that provisions workspaces as Terraform-managed infrastructure — allowing workspaces to run on any cloud, on-premises hardware, or Kubernetes cluster.

Architecture: Coder's control plane (coderd) manages workspace lifecycle, authentication, and access proxying. Workspaces are defined as Terraform templates — meaning you can define precisely what infrastructure each workspace runs on, what ports are exposed, and what environment it includes. Developer access to workspaces is proxied through the Coder control plane, which provides audit logging for all connections.

Sovereignty profile:

• Open-source under AGPL-3.0 (Coder Technologies, Austin, TX — but self-hosted removes US-cloud dependencies)
• Terraform-based workspace definitions allow deployment on Hetzner, OVHcloud, or any EU infrastructure
• All workspace traffic proxied through your self-hosted Coder instance — no traffic to coder.com when self-hosted
• Built-in audit logging for workspace access — supports Art.30 records of processing activities

GDPR-relevant features:

• Workspace templates control exactly what data is stored and where
• Audit logs capture every developer connection, file access, and terminal session — enabling Art.33 incident investigation
• Workspace expiration policies enforce Art.5(1)(e) storage limitation for development environments
• Role-based access control prevents one developer from accessing another's workspace credentials

Use case fit: Coder is ideal for larger engineering teams or regulated-sector organizations that need fine-grained control over workspace infrastructure, audit logging, and access policies. The Terraform template model allows compliance teams to define standardized workspace configurations that enforce security requirements.

Migration Checklist from Cloud9

Organizations moving from Cloud9 to EU-sovereign alternatives should address:

1. CodeStar Connections audit: Enumerate all CodeStar Connections in your AWS account. Identify those created for Cloud9 workspaces. Revoke OAuth tokens for connections no longer associated with active pipeline requirements. Document the audit for Art.30 records of processing activities.

2. EC2 instance credential cleanup: Audit IAM roles attached to Cloud9 EC2 instances. Remove overly permissive roles. Ensure that AWS credentials in environment variables or .env files in Cloud9 workspaces are rotated after migration — any credentials that transited Cloud9's EC2 infrastructure should be considered potentially exposed.

3. Developer behavioral data deletion request: Review Cloud9's data retention policies for usage telemetry, session data, and workspace activity logs. Submit a deletion request under Art.17 GDPR for data no longer required for the original processing purpose.

4. DPIA for replacement environment: If deploying Gitpod or Coder on self-hosted EU infrastructure, conduct a DPIA that documents: processing activities in the new environment, data flows (workspace creation, code cloning, terminal sessions), security measures (encryption, access control, audit logging), and the legal basis for processing developer personal data.

5. .gitpod.yml or Coder template standardization: Establish organization-wide workspace templates that enforce security defaults — no plaintext credential storage in environment variables, mandatory Secrets Manager or vault integration, workspace expiration policies aligned with Art.5(1)(e).

Why This Matters for EU Development Teams in 2026

Cloud9's deprecation creates a forcing function that many EU teams have postponed: making an explicit decision about where their development infrastructure runs and under what jurisdiction.

The GDPR obligations of cloud-based IDEs are not unique to Cloud9 — they apply equally to GitHub Codespaces (Microsoft/GitHub, US jurisdiction), JetBrains Space (recently discontinued), and any other cloud-hosted development environment operated by a US-headquartered company.

EU teams in regulated sectors — financial services under DORA, healthcare under GDPR Art.9, public sector under NIS2 — face the highest compliance pressure. For these organizations, the answer is increasingly self-hosted: Gitpod on Hetzner, Coder on Ionos, or Theia on any EU-sovereign infrastructure. The operational overhead is real, but measurable. The compliance exposure of US-jurisdiction IDE infrastructure is open-ended.

For teams in non-regulated sectors, the risk calculus depends on the sensitivity of the code being developed and the value of the intellectual property. CLOUD Act compelled access to source code containing trade secrets or proprietary algorithms represents a competitive risk beyond GDPR — one that does not require a law enforcement order to materialize if the broader intelligence community has access to the same cloud infrastructure.

The cloud IDE question is, at its core, the same question that applies to every cloud service EU teams use: who controls the infrastructure, under what law does that control operate, and what happens when legal compulsion meets your data.

Cloud9 is deprecated. The question it raised is not.

Summary: Cloud9 vs. EU-Sovereign Alternatives

The cost differential is striking: Cloud9's EC2 backing at m4.large rates costs approximately 20× more than an equivalent Gitpod or Coder deployment on Hetzner. EU sovereignty and cost efficiency align for once.

Part of the sota.io AWS EU Alternative Series — systematic GDPR analysis of AWS services for EU development teams. Each guide in the series covers the specific data flows, legal obligations, and EU-sovereign alternatives for one AWS service category.