BusDK

BusDK Update

Offload dev workers to a remote GPU box over SSH

BusDK's dev-worker stack gained an early remote environment path for running agent work on a GPU machine over SSH. The pieces are deliberately practical: remote worker environments, rootless Docker access on the remote GPU host, and a Codex app-server proxy for the worker connection.

For dedicated, customer-controlled deployments, this lets the local BusDK stack drive work while execution runs on hardware the operator controls. The shape is experimental, so it fits controlled trials where the operator owns the host, the SSH boundary, and the Docker setup.

May 25, 2026remote workersSSH offloadrootless Docker

In brief

TL;DR

  • Dev workers can target a remote worker environment over SSH while the local stack remains the control surface.
  • The remote GPU host can run rootless Docker and expose the runtime socket to worker containers.
  • A Codex app-server proxy bridges the worker session, so agent work can run on customer-controlled hardware from the local workflow.

The deployment shape keeps the BusDK control plane local and moves worker execution to a remote machine. The remote environment supplies a checkout, container runtime access, and a socket path usable by worker containers. SSH is the operational boundary for setup and synchronization, so the GPU box can stay inside the operator's own account and network policy.

ssh gpu-box.example 'test -S /run/user/1000/docker.sock && echo rootless-docker-ready'
rootless-docker-ready

The Codex app-server proxy is the connection piece. It gives the worker process a stable app-server endpoint even when the execution host is remote. That keeps task submission and observation in the local stack while letting the worker substrate run on a dedicated remote GPU machine.

This maps to BusDK's dedicated, customer-controlled environment deployment tier. A team can bring its own remote GPU box, run the worker substrate there, and keep the local BusDK workflow as the driver. The maturity is early: expect environment-specific setup, SSH and Docker assumptions, and careful operator validation before routine production use.

See docs.busdk.com for BusDK module documentation.