Factory brings Droid agents to customer-managed machines

Factory has launched Remote Control, a bring-your-own-compute option for running Droid coding agents persistently on machines customers already manage. Supported hosts include cloud VMs, workstations, on-premises servers, and spare hardware such as a Mac mini.

A persistent host keeps repositories, installed dependencies, configuration, running services, and saved context available across sessions. It also places the agent inside the environment where private APIs, internal databases, GPUs, licensed software, and existing development tools already live.

Two homes for a Droid

Factory now offers customer-managed Remote Control alongside Droid Computers, its hosted persistent environments. The main differences concern infrastructure ownership, maintenance, and machine lifecycle.

Factory scopes each Remote Control machine to an individual user or service, preventing it from becoming a shared team resource by default.

The shell survives the session

Registering a host gives Droid a persistent shell whose access follows the machine’s permissions and supplied credentials. From that shell, the agent can:

• Clone, edit, build, and test repositories on the host
• Install dependencies and interact with running services
• Use authentication tokens made available in the environment
• Read and write files or durable context that survives later sessions
• Run background tasks such as test suites and data pipelines

Factory’s CLI lists registered machines and opens interactive SSH sessions to selected hosts. Its core commands include:

• droid computer list to show registered machines
• droid computer ssh to start an interactive SSH session

Port forwarding travels through Factory’s relay, which carries the connection between the local client and registered host. The CLI accepts three mapping formats:

Code, files, services, and agent processes remain on the registered machine while Factory provides the remote connection path.

Bring the agent to private systems

Customer-managed hosts place Droid beside resources that hosted sandboxes may be unable to reach or reproduce. Practical uses include:

1. Running inside a corporate network with access to internal APIs and databases
2. Using a workstation equipped with a specific GPU, dataset, or licensed application
3. Repurposing an idle home server or Mac mini as a dedicated agent runner
4. Preserving a project-specific toolchain that would be costly to rebuild for each session
5. Keeping long-running tests, builds, or data jobs on a machine that remains available

Credentials set the access boundary

Remote Control gives Droid access to the host resources and authentication material that an operator provides. Dedicated operating-system accounts, narrowly scoped tokens, restricted network access, and host logging can limit the effect of mistakes or compromised credentials.

The per-user or per-service scope also affects team design. Shared workflows may require separate registered machines or service identities rather than assuming every developer can reach the same host.

Control comes with upkeep

Remote Control shifts patching, uptime, capacity planning, and host security to the customer in exchange for direct access to existing infrastructure. Factory-managed Droid Computers retain automated lifecycle management for teams that prefer a provisioned environment.

Teams whose agents need private services, specialized hardware, or durable local state can now run Droid in the same environment where those dependencies already operate, while continuing to reach the machine through Factory’s tools.