Skip to content

Architecture

Overview

Cloud CLI Proxy consists of four core components: Control Plane, Host Agent, user containers, and the cloud-claude CLI. The control plane handles API, authentication, and task orchestration. The host agent executes Docker and network operations. The two communicate over a Unix socket.

User ──curl──> Control Plane (:8080) ──Docker──> │ User Container           │
                    │                              │  SSH + Claude + VNC      │
               SQLite (WAL)                        │  sing-box tun tunnel     │
                    │                              │       ↓                  │
              Admin UI (embed)                    │  Designated egress IP    │
                    │                              └──────────────────────────┘
              SSH Proxy (:2222)

Core Components

Control Plane

A Go API server that acts as the central orchestrator:

  • HTTP API — RESTful interface for admin and user panels
  • Authentication — JWT token issuance with admin and user roles
  • Task orchestration — Host create, start, stop, rebuild via async task queue
  • Expiry scanner — Periodically checks user expiration, auto-stops and disables
  • SSH proxy — Listens on :2222, proxies SSH sessions to target containers
  • Reconciler — Syncs running container state with database records

Host Agent

Executes privileged host operations, communicates with the control plane over a Unix socket:

  • Docker management — Create, start, stop, delete user containers
  • Network configuration — Create netns, configure sing-box tun
  • Firewall management — Set nftables default-deny rules per container
  • Network verification — Triple check: connectivity, exit IP match, DNS leak detection

Two run modes: socket (standalone process, recommended for production) and embedded (inside control plane, for development).

User Container

A managed image based on Ubuntu 24.04, created with --network=none for complete network isolation. Pre-installed with OpenSSH, Claude Code, KasmVNC + Chromium, sing-box, and dev tools (Git, tmux, zsh, Node.js).

cloud-claude CLI

A Go CLI installed on the user's laptop, bridging the local terminal and the remote container:

  • Local directory mounted at the same path inside the container via sshfs
  • Three mount modes: Auto / Full / SSHFS-Only
  • tmux multi-client sessions with auto-reconnect on disconnect
  • doctor five-domain self-check + --fix auto-repair
  • explain error code lookup
  • proxy_commands to run commands like git on the local machine

SQLite

The control plane uses a SQLite single-file database (WAL mode), specified via the DATABASE_URL environment variable. The database file is stored at /data/cloud-cli-proxy.db, persisted by a Docker Compose named volume.

Container Network Isolation

Each container is created with --network=none. Only the loopback interface exists after creation. No direct external network access.

sing-box tun Tunnel

User container namespace
├── lo (loopback)
├── tun0 (sing-box tun device)
│   └── Route: 0.0.0.0/0 → tun0
└── nftables: default deny, only proxy server connections allowed

sing-box runs in tun mode, capturing all outbound traffic and forwarding through the designated proxy protocol.

Triple Network Verification

After every host start, three checks are performed:

  1. Connectivity — HTTP request to external endpoint from container netns
  2. Exit IP match — Verify actual exit IP matches the configured one
  3. DNS leak detection — Ensure DNS requests also go through the tunnel

If any check fails, the host is marked unavailable.

Security Boundaries

Privilege Separation

The control plane does not touch Docker or networking directly. All privileged operations are centralized in the host agent and exposed to the control plane through a Unix socket.

User Isolation

  • Each user gets an independent container, created with --network=none
  • No inter-container networking
  • JWT tokens distinguish roles; users can only access their own resources

Credential Management

  • User passwords stored as bcrypt hashes
  • JWT token authentication with rotatable keys
  • Container SSH passwords are independent from user login passwords

Data Flows

User Access (curl)

User → curl /entry/{shortId} → Get entry script
     → Enter password
     → POST /v1/entry/{shortId}/auth → Authenticate
     → SSH params returned → SSH proxy connects to container

cloud-claude CLI

User → cloud-claude init → Write config
     → cd project dir → cloud-claude
     → Authenticate + wait for container ready
     → sshfs mount local directory to same path in container
     → Attach or create tmux session
     → Start Claude Code remotely

Host Startup Task Flow

Control plane creates task → Host Agent receives
  → Pull managed image
  → Create container (--network=none)
  → Configure netns + sing-box tun
  → Configure nftables
  → Start container
  → Triple network verification
  → Mark task succeeded

Architecture Principles

  • Single-host first — No multi-node scheduling in v1
  • Network enforcement — All traffic must go through designated egress IPs; no bypasses
  • Least privilege — Strict separation between API layer and privileged operations

Project Structure

cloud-cli-proxy/
├── cmd/
│   ├── cloud-claude/           # cloud-claude CLI
│   ├── control-plane/          # Control plane API
│   └── host-agent/             # Host agent
├── internal/
│   ├── controlplane/           # HTTP routes, business logic, scheduling
│   │   ├── http/               # Routes and middleware
│   │   ├── app/                # App lifecycle
│   │   ├── scheduler/          # Expiry scanner and scheduled tasks
│   │   └── credgen/            # Credential generation
│   ├── agent/                  # Host agent server
│   ├── agentapi/               # Agent API client
│   ├── broadcast/              # SSE real-time broadcast
│   ├── cloudclaude/            # cloud-claude CLI library
│   ├── local/                  # Local Dev Containers
│   ├── network/                # nftables / sing-box configuration
│   ├── runtime/                # Task runtime, container lifecycle
│   ├── sshproxy/               # SSH proxy
│   └── store/                  # Database migrations and queries (pgx)
├── web/admin/                  # React admin dashboard
├── deploy/                     # Dockerfiles, Compose, scripts
├── docs/                       # VitePress documentation
├── docker-compose.yml          # Production Compose
└── Makefile

Tech Stack

LayerTechnology
BackendGo 1.26, net/http, pgx v5
FrontendReact 19, TypeScript, Vite, Tailwind CSS
DatabaseSQLite (WAL mode)
ContainersDocker Engine 28, Ubuntu 24.04
Networkingsing-box tun + Linux netns, nftables
DesktopKasmVNC + Chromium