cloudX: Keep Your Code in AWS, Not on Your Laptop

In regulated industries—finance, healthcare, government—the question of where code lives matters as much as what it does. Source code, configuration, credentials, and the data your code processes: if any of it touches a developer's laptop, you have an endpoint risk problem. Laptops get lost, stolen, or compromised. They leave the office. They connect to unknown networks. They are, from a compliance perspective, the weakest link in your development chain.

cloudX takes a different approach: your code never leaves AWS. Developers work in VSCode as they always have, but the editor's backend—where files are stored, where code runs, where AWS credentials live—is an EC2 instance inside your own AWS environment.

The Compliance Case

For organizations under GDPR, ISO 27001, SOC 2, or sector-specific regulations, keeping development artefacts inside a governed AWS environment addresses several common controls in one move:

• Data residency: Code and data stay in the AWS region you choose
• Endpoint risk: Developer laptops hold no sensitive project data
• Access logging: All session activity is logged via SSM Session Manager to CloudWatch or S3
• Credential hygiene: No AWS keys on developer machines; IAM roles only
• Access revocation: Terminate the CloudFormation stack; the developer is out
• Cost control: The instance starts automatically when you connect and stops itself after 30 minutes of inactivity (configurable). You pay only for time you're actively developing—no forgotten instances running overnight

The Model: Thin Client, Thick Cloud

With cloudX, a developer's laptop becomes a thin client. VSCode runs locally, but everything else happens on an EC2 instance in your AWS account:

• Source code lives on the instance's EBS volume, not on the laptop
• AWS credentials are the IAM role attached to the instance—no local credential files, no ~/.aws/credentials, no risk of key leakage from endpoint devices
• Data the code operates on stays in AWS—S3, RDS, DynamoDB—and is accessed directly from the instance over private networking
• Build artifacts, logs, temporary files, pip caches: all on the instance

When a developer closes their laptop, nothing of consequence is there. The working state is on the EC2 instance in your VPC.

This is a meaningful shift for compliance. Instead of trying to control what happens on N developer laptops across N operating systems with N security postures, you control one thing: the AWS environment.

No Open Ports, No Public IP

The connection between VSCode and the EC2 instance runs through AWS Systems Manager Session Manager. The instance has no public IP address, no inbound security group rules, and no SSH port exposed to the internet. There is no network path to the instance that doesn't go through AWS IAM authentication first.

From a network security standpoint, the instance is as locked down as your production workloads.

cloudX-proxy is the client-side tool that makes this transparent. It handles instance startup, SSH key distribution via EC2 Instance Connect, and SSM tunneling—and writes an SSH config entry so VSCode Remote just sees a regular SSH host. Developers don't interact with any of the underlying mechanics.

The Architecture

cloudX has two parts: the AWS side and the client side.

The AWS side is a set of CloudFormation templates you deploy to your account:

• cloudX-environment.yaml — deploy once per environment (dev, test, prod, or per team). Creates the IAM instance profile, security group, IAM group with ABAC policies, and stores all configuration in Parameter Store.
• cloudX-instance.yaml — deploy once per developer. Creates an EC2 instance (default: t3.large, Amazon Linux 2023) with your chosen development tools pre-installed.
• cloudX-user.yaml — optional, for teams that need dedicated IAM users rather than SSO roles.

The client side is cloudX-proxy, a Python package (uvx cloudX-proxy) that handles the SSH proxy magic. The first connection takes 2–3 minutes while the instance starts and VSCode Server installs. Reconnecting is ~30 seconds.

Access Control: ABAC and Multiple Environments

cloudX uses attribute-based access control (ABAC) to tie developers to their own instances. A developer cannot reach another developer's instance, even in the same environment. Environments are fully isolated—each has its own VPC subnet, security group, IAM group, and SSM Parameter Store namespace.

You can run cloudX-dev-erik, cloudX-prod-erik, and cloudX-research-erik as completely separate SSH targets in separate environments, with separate IAM permissions, in the same AWS account.

Software That Comes Pre-Installed

Getting Started

Deploy the environment template first:

Then deploy an instance for yourself:

On your local machine, install the proxy and run setup:

uvx cloudX-proxy setup

The setup wizard prompts for your AWS profile, instance ID, and a hostname. It writes an SSH config entry and you're done. Open VSCode Remote Explorer, connect to cloudX-{env}-{hostname}, and you're developing in AWS.

cloudX is open source. The CloudFormation templates and the proxy client are both on our GitHub.