Open docker image as ubuntu EC2 instance or similar

[danlester]

devs-cli is all about running docker containers (devcontainers) for use by VSCode or other purposes locall, maybe connecting using VSCode remote devcontainer plugin.

We really value the reproducible dev environments. Might it be possible to launch complete instances based on the Docker images, e.g. EC2 instance (or another provider than AWS) so that we can use SSH (or SSM proxy) to connect via VSCode SSH tunnel or similar (but not ssh then docker remote - that's too many steps).

Have a think about creative solutions here.

[danlester]

Oh you forgot to actually do anything - adding a comment here might have been a good result!

[actflower]

Thanks for the feature idea! Here are my thoughts on potential approaches for launching reproducible dev environments as cloud instances:

Approach 1: Docker-based AMI/Image Generation

Convert existing devcontainer Docker images to cloud VM images:

• AWS: Use docker2ami or build AMIs using Packer with the Docker image as a base layer
• GCP: Use Cloud Build to convert Docker images to GCE images
• Azure: Similar approach with Azure Image Builder

Pros: Reuses existing devcontainer definitions, maintains reproducibility
Cons: Requires image conversion pipeline, storage costs for VM images

Approach 2: Cloud-init + Docker Pull on Instance Boot

Launch a minimal Ubuntu/Amazon Linux instance and use cloud-init to:

1. Install Docker
2. Pull the devcontainer image
3. Run the container with SSH exposed on port 22
4. (Or extract container filesystem to host)

Pros: No image conversion needed, uses existing Docker Hub images
Cons: Slower boot time, still has docker layer (though transparent to SSH user)

Approach 3: AWS EC2 Image Builder with Devcontainer Features

Use EC2 Image Builder with devcontainer features installed directly:

• Parse devcontainer.json features and translate to AMI build steps
• Creates native VM images with same tooling as containers

Pros: Native VM experience, fast boot
Cons: Requires building parallel infrastructure for image creation

Approach 4: Firecracker microVMs

Use Firecracker to run Docker images as lightweight VMs:

• Near-container performance with VM isolation
• Can convert OCI images to Firecracker rootfs
• Services like Fly.io use this approach

Pros: Best of both worlds - container images with VM connectivity
Cons: Requires self-hosting Firecracker infrastructure or using a provider

Approach 5: VS Code Tunnels (Avoids SSH Entirely)

Use VS Code Server inside containers:

• Container runs code tunnel command
• Connect from any VS Code client via tunnel URL
• Works through firewalls without SSH

Pros: Works with existing container setup, no port exposure needed
Cons: Requires VS Code (not generic SSH), depends on Microsoft service

Recommended Path

For devs, I'd suggest Approach 2 as the simplest starting point:

devs cloud start mydev --provider aws --instance-type t3.medium
devs cloud ssh mydev  # Opens SSH connection
devs cloud vscode mydev  # Opens VS Code Remote-SSH

The implementation could:

1. Use boto3/cloud provider SDKs to launch instances
2. Pass cloud-init script that pulls/runs the devcontainer
3. Configure SSH keys automatically
4. Store instance metadata for reconnection

Would you like me to prototype any of these approaches? I can start with a basic AWS implementation if that's useful. Let me know which direction feels right!

[danlester]

The point is we don't want to do the double-hop SSH and then inside docker.

Tell me more about:

Approach 1: Docker-based AMI/Image Generation
Convert existing devcontainer Docker images to cloud VM images:

AWS: Use docker2ami or build AMIs using Packer with the Docker image as a base layer

4 And Firecracker, perhaps in AWS if possible or something similar (but must support VSCode nicely)

5 More about VS Code Tunnels - perhaps even within a docker container on the instance, it won't be the double-hop is that what you're saying.

[actflower]

Great questions! Let me dive deeper into those three approaches:

Approach 1: Docker Image → AMI Conversion

docker2ami

docker2ami exports a Docker image's filesystem to create an AMI:

# Basic concept
docker2ami --image your-devcontainer:latest --ami-name devs-myenv

How it works:

1. Runs your Docker image, exports filesystem via docker export
2. Creates an EBS volume, mounts it, copies the exported filesystem
3. Registers as an AMI with proper boot configuration

Challenges: Docker images aren't designed to boot as VMs - they lack:

• Systemd/init system (can be added)
• SSH server (can be added)
• Cloud-init for key injection (can be added)
• Kernel (uses EC2's kernel)

Packer Approach (More Robust)

Packer can build AMIs that install from a Docker image:

# packer.pkr.hcl
source "amazon-ebs" "devcontainer" {
  ami_name      = "devs-{{timestamp}}"
  instance_type = "t3.medium"
  source_ami_filter {
    filters = {
      name = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*"
    }
    owners = ["099720109477"]  # Canonical
  }
  ssh_username = "ubuntu"
}

build {
  sources = ["source.amazon-ebs.devcontainer"]
  
  provisioner "shell" {
    inline = [
      # Install Docker
      "curl -fsSL https://get.docker.com | sh",
      # Pull and extract devcontainer
      "docker pull your-devcontainer:latest",
      "docker create --name temp your-devcontainer:latest",
      "sudo docker cp temp:/ /opt/devcontainer-root",
      # Merge into system (selective copy to preserve boot)
      "sudo rsync -av --exclude /boot --exclude /etc/fstab /opt/devcontainer-root/ /",
      # Ensure SSH works
      "sudo systemctl enable ssh"
    ]
  }
}

This gives you a native AMI with your devcontainer's tooling installed directly. SSH connects directly to the VM - no Docker layer.

---

Approach 4: Firecracker on AWS

What is Firecracker?

Firecracker runs microVMs that boot in <125ms with minimal memory overhead. Each "container" is actually a lightweight VM with its own kernel.

AWS Lambda Uses This

Lambda runs your code in Firecracker microVMs behind the scenes. However, there's no direct AWS service exposing Firecracker for custom workloads.

Options for Firecracker:

A) Self-hosted on EC2 bare metal

# Launch i3.metal or similar
# Install Firecracker
# Convert Docker images to rootfs:
docker export $(docker create your-image) | sudo tar -xf - -C /rootfs

# Boot microVM
firectl --kernel=vmlinux --root-drive=/rootfs --...

Cons: Requires managing bare metal instances, networking complexity

B) Fly.io (Firecracker-based PaaS)

# fly.toml
[env]
  # Your devcontainer config

[[services]]
  internal_port = 22
  protocol = "tcp"
  
  [[services.ports]]
    port = 22

Fly.io runs your Docker images as Firecracker VMs with direct IP connectivity. SSH works natively. This is probably the easiest path to Firecracker.

C) AWS Fargate + ECS Exec (Firecracker-adjacent)
Fargate uses Firecracker under the hood. You can use ECS Exec for shell access:

aws ecs execute-command --cluster mycluster --task mytask --container mycontainer --interactive --command "/bin/bash"

But this isn't VS Code compatible directly.

VS Code + Firecracker

For VS Code Remote-SSH to work with Firecracker, you need:

• Public/private IP or tunneling
• SSH server running in the microVM
• Proper networking setup

Fly.io handles this well. Self-hosted requires more plumbing.

---

Approach 5: VS Code Tunnels (Detailed)

How It Works

VS Code Tunnels flip the connection model:

1. A process inside the container initiates an outbound connection to Microsoft's tunnel service
2. Your local VS Code connects to that same tunnel service
3. They're bridged together - no SSH needed at all

[Your VS Code] <--tunnel--> [Microsoft Service] <--tunnel--> [Container running code tunnel]

The Key Point: No Double-Hop

Even if your dev environment is:

• On an EC2 instance
• Running Docker
• Inside a container

You don't SSH to EC2, then attach to Docker. Instead:

1. Container runs code tunnel
2. You open VS Code locally
3. Connect via the tunnel directly into the container

From your perspective, it's a single connection directly into the development environment.

Implementation Example

Your devcontainer's entrypoint or postCreate command:

# Install VS Code CLI
curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64' -o /tmp/vscode-cli.tar.gz
tar -xf /tmp/vscode-cli.tar.gz -C /usr/local/bin

# Start tunnel (will show URL/code for auth on first run)
code tunnel --accept-server-license-terms

From devs:

# Could add a command like:
devs tunnel mydev  # Shows tunnel URL or opens VS Code to tunnel

Authentication Flow

First time: CLI shows a URL and code, you authenticate in browser. After that, it's automatic.

Pros for devs use case:

• Works through NAT/firewalls (outbound only)
• No SSH key management
• No port exposure needed
• Container could be anywhere - local Docker, EC2, Kubernetes, etc.
• Single connection into the actual dev environment

Cons:

• Depends on Microsoft's tunnel service (reliability/privacy concerns)
• Requires VS Code (not generic terminal SSH)
• Initial auth flow

---

My Recommendation

Given your goal of avoiding the double-hop:

1. For simplest path today: VS Code Tunnels - works with existing devcontainers, no infrastructure changes
2. For native VM experience: Packer + AMI generation - more setup, but true VM with direct SSH
3. For container-like speed with VM isolation: Fly.io (Firecracker) - good balance, easy setup

Would you like me to prototype any of these? I could start with:

• Adding devs tunnel command that starts VS Code tunnels in containers
• A Packer template that converts devcontainer definitions to AMIs
• A Fly.io deployment example

Let me know which direction is most interesting!

[danlester]

Fly.io sounds promising (their sprites.dev service?) - however, I've heard it is difficult to get this running with vscode for dev purposes, only really SSH available or something. What are people doing?

[actflower]

Fly.io Sprites + VS Code - Current State

Great question! I researched this thoroughly. Here's what I found:

The Challenge with Sprites

Fly.io's Sprites.dev are lightweight VMs that spin up in ~1 second with persistent storage, checkpoint/restore, and pre-installed dev tools (Claude Code, Python 3.13, Node.js 22, etc.). They're designed primarily for agentic AI coding isolation.

However, VS Code integration is not officially provided and is still a community wishlist item. The main issue: Sprites use sprite console which tunnels through websockets, not SSH - so traditional VS Code Remote SSH doesn't work directly.

Current Workarounds

1. VS Code Tunnels (serve-web) - Works but clunky:

# On the Sprite:
./code serve-web  # Download VS Code CLI first

# On your machine:
sprite proxy 8000  # Opens localhost URL to access VS Code

Note: The regular ./code tunnel command conflicts with Sprite's port forwarding.

2. Regular Fly Machines (not Sprites) - Full VS Code support:

• Deploy a Fly Machine with OpenSSH server (not their built-in hallpass SSH)
• Connect via WireGuard + VS Code Remote SSH
• Requires more setup but gives proper SSH with port forwarding

3. Tailscale integration - Some users report success using Tailscale to establish proper SSH to Sprites, but it adds complexity.

Recommendation for devs-cli

Given the VS Code friction with Sprites, I'd rank the approaches:

1. VS Code Tunnels (my earlier suggestion) - Works with any cloud instance, including Sprites, without SSH config
2. Fly Machines + OpenSSH - Full VS Code Remote SSH support, but more infrastructure to manage
3. Sprites + serve-web - Viable workaround if you specifically want Sprite's checkpoint/restore features

Would you like me to explore implementing any of these as a devs cloud command? The VS Code Tunnels approach might integrate most cleanly since it works across providers (AWS, Fly, etc.) without requiring SSH configuration.

[danlester]

OK sure, try vscode tunnels - the main thing will be incorporating it into our devcontainer template really. Plus ideally being able to start it from outside the container and leave it running, if we decide it shouldn't start automatically. And/or maybe there is some auth we need to take care of in dev-cli. Have a think and see what you come up with.

[actflower]

I've implemented VS Code tunnel support as requested. Here's what's included:

Implementation

PR: #83

New Command: devs tunnel <name>

This allows you to start a VS Code tunnel from any devcontainer. The tunnel uses Microsoft's tunnel service - the container initiates an outbound connection, so no SSH or port forwarding is needed.

Usage

# Start a container
devs start mydev

# Start a tunnel (keep this terminal open)
devs tunnel mydev

# First time: you'll see authentication instructions
# - Open the URL shown in your browser
# - Enter the device code to authenticate with GitHub/Microsoft

# Check tunnel status
devs tunnel mydev --status

# Stop the tunnel
devs tunnel mydev --kill

Connecting with VS Code

1. After the tunnel starts, it will show connection information
2. In VS Code, open the Remote Explorer (sidebar icon)
3. Look for the "Tunnels" section
4. Your tunnel will appear as dev-<org>-<repo>-<devname>
5. Click to connect directly to the container

Key Benefits

• No double-hop: Connect directly to the container, not SSH → Docker
• Works through firewalls: Only outbound connections needed
• Works on remote servers: No port forwarding required
• Integrated into devcontainer template: VS Code CLI is now included in the base image

Implementation Details

• Added VS Code CLI to the Dockerfile (supports x64 and arm64)
• Added start_tunnel, get_tunnel_status, and kill_tunnel methods to ContainerManager
• Added the CLI command with --status, --kill, and --live options
• Added documentation to CLAUDE.md

Notes on Authentication

First-time authentication requires the interactive device code flow (GitHub or Microsoft account). After that, the tunnel name and credentials are stored, so subsequent tunnel starts are faster.

Let me know if you'd like any changes to the implementation!