bot0 Cloud Architecture
Overview
bot0 Cloud provides users with persistent, fully isolated cloud computers where a bot0 daemon lives and works 24/7. Each cloud computer is a dedicated KVM virtual machine — the same technology that powers AWS EC2, Google Cloud, and DigitalOcean. No one else has access to a user's machine except the user themselves.
Key principle: Creating a new agent = buying a new cloud computer. The daemon lives there, works there, and the environment persists indefinitely.
What Users Get
Each cloud computer is a full, isolated machine:
- Full Ubuntu Desktop (Xfce — lightweight, ~200MB RAM)
- Chrome/Chromium with extension support (dom0 extension sideloaded)
- bot0 daemon running as a systemd service
- Terminal access via SSH
- Remote desktop access via browser (noVNC)
- Persistent storage — apps, configs, files survive reboots and persist for years
- Full root access — install apps, change settings, download files
- Auto-sleep/wake — when idle, the VM auto-suspends (hibernates) and auto-wakes when a task arrives. Near-$0 idle cost, resumes in 3-5 seconds with everything intact
Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ BYTESPACE │
│ │
│ User clicks "Create New Agent" │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Provisioning API │──── POST /api/cloud/instances │
│ │ │ │
│ │ • Select plan │ │
│ │ • Select region │ │
│ │ • Assign user │ │
│ └──────────┬──────────┘ │
│ │ │
└─────────────┼────────────────────────────────────────────────────────────────┘
│
│ Hetzner API / Proxmox API
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ CLOUD INFRASTRUCTURE │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Hetzner Bare Metal Server │ │
│ │ (Proxmox VE Hypervisor) │ │
│ │ │ │
│ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │
│ │ │ VM: User A │ │ VM: User B │ │ VM: User C │ │ │
│ │ │ │ │ │ │ (SUSPENDED) │ │ │
│ │ │ Ubuntu Xfce │ │ Ubuntu Xfce │ │ │ │ │
│ │ │ Chrome+dom0 │ │ Chrome+dom0 │ │ RAM on disk│ │ │
│ │ │ bot0 daemon │ │ bot0 daemon │ │ Auto-wakes │ │ │
│ │ │ SSH + noVNC │ │ SSH + noVNC │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ISOLATED ─────│──│─ ISOLATED ────│──│─ ISOLATED │ │ │
│ │ │ (hardware │ │ (hardware │ │ (hardware │ │ │
│ │ │ enforced) │ │ enforced) │ │ enforced) │ │ │
│ │ └───────────────┘ └───────────────┘ └───────────────┘ │ │
│ │ │ │
│ │ Each VM = separate CPU, memory, disk, network │ │
│ │ Enforced by CPU hardware (Intel VT-x / AMD-V + EPT) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Additional Servers (scale) │ │
│ │ 8-20 VMs per server │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
│
│ WebSocket (Hub connection)
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ HUB (Fly.io) │
│ │
│ Cloud daemons connect to Hub just like local daemons. │
│ Tasks can be routed to cloud daemons from Bytespace, │
│ local daemons, or external triggers (Telegram, cron, etc.) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Security & Isolation
KVM Hardware Isolation
Each cloud computer runs as a KVM virtual machine — the same technology that powers AWS EC2 and Google Cloud Compute Engine. Isolation is enforced by CPU hardware, not software.
| Isolation Layer | Technology | What It Prevents |
|---|---|---|
| CPU | Intel VT-x / AMD-V | VM cannot execute host instructions |
| Memory | EPT (Extended Page Tables) | VM cannot read another VM's RAM |
| I/O | IOMMU (VT-d) | VM cannot access another VM's devices |
| Network | Virtual NIC + firewall | VM cannot sniff another VM's traffic |
| Disk | Separate qcow2 image | VM cannot access another VM's files |
A KVM VM is as isolated as a separate physical computer. One VM cannot see, access, or interfere with another VM. This is hardware-enforced by the CPU itself.
Who Has Access
| Entity | Access Level |
|---|---|
| The user | Full root — SSH, remote desktop, install anything |
| Other users' VMs | None — hardware-isolated, invisible |
| Bytespace (us) | Host-level access for maintenance only (same trust model as AWS/GCP) |
| Self-hosted users | Only them — they own the physical hardware |
bot0 Security Model Integration
Cloud VMs follow the same security model as local daemons:
- Daemon has ZERO secrets — only session tokens and proxy URL
- All credentials on Proxy — API keys encrypted at rest (AES-256-GCM)
- Device authentication — cloud VMs register as devices with vTPM (on AWS/GCP) or software-managed keys (on Hetzner)
- Session tokens are revocable — if a VM is compromised, revoke server-side
Daemon Hardening
The daemon process is hardened inside the VM to minimize attack surface, even if an agent is prompt-injected:
-
Environment stripping. On boot, the daemon reads
SESSION_TOKEN,PROXY_URL, andHUB_URLinto memory, then deletes them fromos.environ. If agent-executed code inspects the environment, those variables are gone. -
Privilege drop. The daemon starts as root (needed for system setup), then drops to an unprivileged
bot0user viasetuid/setgid. All agent work runs unprivileged. -
Network lockdown. The VM firewall is configured so the daemon can only make outbound connections to the Proxy URL and Hub WebSocket. Even if an agent is prompt-injected, it cannot call arbitrary external endpoints.
-
Presigned URLs for storage. The daemon never holds cloud storage credentials. When files need to be synced (workspace backup), the daemon requests presigned upload/download URLs from the Proxy, scoped to the session. Direct S3 access, zero stored credentials.
Zero-Secrets Control Plane Pattern
bot0's architecture follows the "isolate the agent" pattern (validated by Browser Use's infrastructure):
┌──────────────────────────────────────────────────────┐
│ VM (the agent) │
│ │
│ • ZERO secrets │
│ • Cannot reach the internet directly │
│ • Can only talk to Proxy + Hub │
│ • Disposable — can be killed/replaced anytime │
│ │
│ Key insight: "The agent should have nothing worth │
│ stealing and nothing worth preserving." │
└──────────────┬───────────────────────────────────────┘
│ Only allowed connections
▼
┌──────────────────────────────────────────────────────┐
│ Bytespace Proxy (the control plane) │
│ │
│ • Holds ALL credentials (encrypted API keys) │
│ • Validates session token on every request │
│ • Proxies LLM calls (adds real API key server-side) │
│ • Proxies file storage (presigned URLs) │
│ • Enforces billing / cost caps │
│ • Owns conversation history via ctx0 │
└──────────────────────────────────────────────────────┘
The VM is a disposable shell. The Proxy/Bytespace is the source of truth. If a VM is compromised, there is nothing to steal — revoke the session token and the attacker has nothing.
VM Image (cloud-init)
Each cloud computer is provisioned from a pre-built image with:
Ubuntu 24.04 LTS
├── Xfce Desktop Environment (~200MB RAM, lightweight)
├── Chrome/Chromium + dom0 extension (sideloaded)
├── bot0 daemon (systemd service, auto-starts)
│ ├── Runs as unprivileged 'bot0' user (privilege drop)
│ ├── Strips SESSION_TOKEN, PROXY_URL, HUB_URL from env after read
│ └── Firewall: outbound ONLY to Proxy + Hub
├── noVNC + websockify (browser-based remote desktop)
├── SSH server (key-based auth)
├── Xvfb or Xdummy (virtual display for headless Chrome)
├── cloud-init (auto-provisions on first boot)
│ ├── Registers device with Bytespace
│ ├── Connects daemon to Hub
│ ├── Sets up user SSH keys
│ └── Configures firewall rules (Proxy + Hub only)
└── Standard dev tools (git, node, python, etc.)
The image is pre-baked so new instances boot in seconds, not minutes. The same image runs everywhere — Proxmox VM in production, Docker container for development/testing. A single config switch controls which path the provisioning code takes.
Pricing Model
User-Facing Pricing
| State | What Happens | User Pays |
|---|---|---|
| Active | VM running, daemon working | $10-15/mo |
| Suspended | VM auto-hibernated (RAM saved to disk), resumes in 3-5s | $1-2/mo |
| Destroyed | VM and disk deleted | $0 |
Bytespace Cost (Internal)
| Scale | Infrastructure | Cost per VM | Margin at $10/mo |
|---|---|---|---|
| 1-10 VMs | Hetzner Cloud VMs | $5-7/mo | $3-5 |
| 10-50 VMs | Hetzner Bare Metal + Proxmox | $4-5/mo | $5-6 |
| 50+ VMs | Multiple dedicated servers | $3-4/mo | $6-7 |
| Self-hosted | User's hardware | $0 | Subscription only |
Infrastructure Costs
| Resource | Provider | Specs | Monthly Cost |
|---|---|---|---|
| Bare metal server | Hetzner AX42 | 8-core, 64GB RAM, 2x512GB NVMe | ~$50/mo |
| VMs per server | Proxmox | 2 vCPU, 4-6GB RAM each | 8-12 per server |
| Cost per VM | — | — | ~$4-6/mo |
| Idle storage | Hetzner | 40-80GB per VM | ~$1-2/mo |
Scaling Strategy
Phase 1: Hetzner Cloud VMs (Launch)
Simple API-driven provisioning. No infrastructure management.
- Bytespace API calls Hetzner Cloud API to create VMs
- Pre-built snapshot used as VM image
- $5-7/mo cost per VM
- Good for 1-50 users
Phase 2: Hetzner Bare Metal + Proxmox (Growth)
Own the hypervisor for better margins.
- Buy dedicated servers ($50-90/mo each)
- Run Proxmox VE (free, open-source hypervisor)
- 8-20 VMs per server
- $4-5/mo cost per VM
- Proxmox API for provisioning
Phase 3: Kubernetes + KubeVirt (Scale)
The Scrapybara approach — Kubernetes orchestrating QEMU/KVM VMs.
- Auto-scaling, live migration, self-healing
- Multi-region with Terraform
- Only worth the engineering cost at 500+ VMs
- $3-4/mo cost per VM
Phase 1 Phase 2 Phase 3
Hetzner Cloud VMs Bare Metal + Proxmox Kubernetes + KubeVirt
(1-50 users) (50-200 users) (200+ users)
Bytespace API Bytespace API Bytespace API
│ │ │
▼ ▼ ▼
Hetzner Cloud API Proxmox API KubeVirt API
│ │ │
▼ ▼ ▼
KVM VM KVM VM KVM VM (as K8s pod)
(managed by Hetzner) (managed by us) (managed by K8s)
Self-Host Option
Users can run their own cloud computers on their own hardware:
- Proxmox image — Download and import a pre-built VM template
- ISO/cloud-init — Boot from ISO on any KVM-capable host
- Bare metal install — Install directly on a dedicated machine (Mac Mini, NUC, etc.)
The daemon registers with Bytespace the same way, connects to Hub, and receives tasks. The only difference is who owns the hardware.
User Access Methods
| Method | How | Use Case |
|---|---|---|
| Bytespace UI | Chat interface in browser | Send tasks to daemon, view results |
| noVNC | Browser-based remote desktop | See the desktop, watch the daemon work |
| SSH | Terminal access | Power users, debugging, custom setup |
| Hub | WebSocket relay | Route tasks from other daemons or triggers |
VM Lifecycle
┌──────────┐ Create ┌──────────┐ Auto-suspend ┌──────────┐
│ │ ──────────────► │ │ ──────────────► │ │
│ (none) │ │ ACTIVE │ (idle 30 min) │SUSPENDED │
│ │ │ │ ◄────────────── │ │
└──────────┘ │ $10/mo │ Auto-wake │ $1-2/mo │
└──────────┘ (task arrives) └──────────┘
│ │
│ Destroy │ Destroy
▼ ▼
┌──────────┐ ┌──────────┐
│ DESTROYED│ │ DESTROYED│
│ $0 │ │ $0 │
└──────────┘ └──────────┘
- Active: VM running, daemon connected to Hub, executing tasks. Full compute charges.
- Suspended: VM hibernated to disk (RAM saved). ALL state preserved — apps, configs, open terminals, running processes. Resumes in 3-5 seconds. User only pays storage. Suspend/resume is handled automatically, not manually.
- Destroyed: VM and disk deleted. All data gone. No charges.
Auto-Suspend / Auto-Wake
VMs automatically hibernate when idle and wake when work arrives. Users don't manage this — it just happens.
Daemon has no tasks for 30 minutes
│
▼
Daemon notifies Bytespace: "going idle"
│
▼
Bytespace calls Proxmox API: qm suspend <vmid> --todisk
│
▼
VM hibernated — RAM saved to disk, $0 compute cost
Everything preserved (apps, configs, processes)
... time passes ...
Task arrives at Hub for this daemon
│
▼
Hub sees daemon offline → calls Bytespace: "wake VM for user X"
│
▼
Bytespace calls Proxmox API: qm resume <vmid>
│
▼
VM resumes in 3-5 seconds — everything exactly as before
│
▼
Daemon reconnects to Hub, receives task
This is like closing and opening a laptop lid. Everything is exactly where the user left it. No reinstalling, no reconfiguring, no booting from scratch.
Disaster Recovery & State Backup
There are two types of state on a cloud computer. They are backed up differently:
Agent State (ctx0)
Conversation history, session state, vault, task history — all stored in ctx0 (Bytespace database). If a VM is destroyed or lost, the daemon's work survives. A new VM can pick up where the old one left off.
ctx0 is NOT a backup of the OS. It only stores the agent's brain.
OS State (Proxmox Snapshots)
Installed apps, system configs, user files, Chrome profiles — captured by Proxmox snapshots. These are automatic, periodic, and nearly instant (copy-on-write).
# Automated daily snapshot qm snapshot <vmid> daily-2026-02-14 --description "auto" # Restore if something breaks qm rollback <vmid> daily-2026-02-14
Recovery Scenarios
| Scenario | What's Lost | Recovery | Speed |
|---|---|---|---|
| Daemon crash | Nothing | Process restarts, ctx0 has agent history | Seconds |
| VM corruption | Nothing | Restore from Proxmox snapshot | Minutes |
| Server hardware failure | Nothing (with replication) | Failover to replicated snapshot on another server | Minutes |
| Server hardware failure | Custom OS setup (without replication) | Fresh VM from base image, ctx0 restores agent work, user reinstalls custom apps | Hours |
For production, Proxmox supports snapshot replication across servers — so even a hardware failure loses nothing.
Comparison with Alternatives
| bot0 Cloud | Scrapybara | E2B | AWS WorkSpaces | |
|---|---|---|---|---|
| Type | Persistent cloud PC | Ephemeral VM | Ephemeral sandbox | Managed desktop |
| Persistence | Indefinite | Max 24hrs | Max 24hrs | Indefinite |
| Full desktop | Yes (Xfce) | Yes (Ubuntu) | No (code only) | Yes (MATE/Windows) |
| Browser | Chrome + extensions | Chrome | No | Yes |
| SSH access | Yes | No | No | Via SSM |
| User owns it | Yes | No (API-only) | No | Yes |
| Self-host | Yes | No | Yes (open-source) | No |
| 24/7 cost | $10/mo | ~$210/mo | ~$36/mo | ~$25-35/mo |
| Target | AI agent + user workspace | Browser automation | Code execution | Enterprise VDI |
Key Technologies
| Technology | Role | Why |
|---|---|---|
| KVM | Hypervisor | Linux kernel-native, hardware-enforced isolation, industry standard |
| QEMU | VM emulation | Emulates hardware for KVM guests, mature and battle-tested |
| Proxmox VE | VM management | Free, open-source, web UI, REST API, snapshots, live migration |
| cloud-init | Auto-provisioning | Industry standard for VM first-boot configuration |
| noVNC | Remote desktop | Browser-based VNC client, no install needed |
| KubeVirt | K8s + VMs | Kubernetes-native VM management (Phase 3 scale) |
| Terraform | Infrastructure-as-code | Declarative multi-region infrastructure provisioning |
References
- Browser Use — Agent Sandbox Infrastructure (Pattern 2: isolate the agent, zero-secrets control plane)
- KubeVirt — VMs on Kubernetes
- Proxmox VE — Open-Source Virtualization
- Hetzner Cloud API
- Hetzner Dedicated Servers
- Scrapybara — Virtual Desktops for AI Agents
- E2B — Code Sandboxes for AI
- cloud-init Documentation
- noVNC — Browser-Based VNC Client