Factory brings agent fleets onto customer infrastructure

Factory, the company behind the Droid coding agent, has introduced OpenCompute, a self-hosted control plane for provisioning and managing fleets of agent sandboxes. A sandbox is an isolated machine or container where an agent can clone code, install dependencies, run commands, and complete a task. OpenCompute extends Factory’s managed sandbox model to customer-selected infrastructure, keeping execution near internal code, secrets, and services.

OpenCompute is available in private preview to Factory customers through their account owners. Factory also plans to open-source the project, including its driver contracts and conformance tests, although the announcement specifies neither a release date nor a license.

Remote Control could not supply elastic capacity

Factory’s earlier deployment option, Remote Control, lets a Droid run on a registered workstation, virtual machine, or on-premises server and connect to Factory through an outbound connection. That model suits a persistent machine assigned to a user or service, including configured workstations, development VMs, and systems with specialized hardware.

Automated workloads need capacity that appears and disappears with demand. An alert may trigger an investigation before anyone provisions a VM, while scheduled jobs and bursts of Slack requests may require several isolated environments at once. OpenCompute handles sandbox creation, suspension, and teardown on customer infrastructure, then releases resources when tasks finish.

Drivers absorb backend differences

OpenCompute places each sandbox backend behind a shared lifecycle API. Provider integrations run as standalone gRPC services, using a structured service-to-service protocol to translate OpenCompute requests into each platform’s native operations for creating, inspecting, controlling, and destroying environments.

Factory reports existing drivers for AWS Lambda MicroVMs, Kubernetes, EC2, Kubernetes Agent Sandbox, Google’s Agent Substrate, and experimental providers. The driver boundary is intended to let teams add another runtime without forking the control plane.

Capability profiles allow runtimes with different feature sets to participate through clearly declared contracts:

• Core: Required lifecycle operations supported by every conforming driver.
• Optional profiles: Suspend, Snapshot, and Fork capabilities for backends that provide them.
• Conformance tests: Black-box checks that validate a driver through its observable behavior.
• Early rejection: Unsupported operations fail before provisioning begins.

The Go-based control plane stores desired state in Postgres as durable data. A reconciliation loop repeatedly compares that desired state with the provider’s actual state, starts provisioning work, observes progress, retries recoverable failures, and advances supported lifecycle transitions. Tasks remain recorded when the service restarts during an operation.

Outbound connections define the trust boundary

OpenCompute runs inside the customer’s environment and initiates a TLS-secured WebSocket connection to Factory. The deployment requires no public control-plane endpoint or inbound firewall port. During enrollment, OpenCompute registers a public key with Factory; the private key remains under customer control and can reside in a supported cloud key management service.

Each sandbox also establishes an outbound connection for control traffic. Because execution occurs inside the customer network, Droids can reach internal repositories, package registries, and services without exposing those systems publicly. The current design remains connected to Factory, so it is not an offline or fully disconnected deployment.

Full data residency depends on more than compute placement. Model inference, session storage, and synchronization have separate configurations, and keeping those data flows local requires appropriate session settings plus bring-your-own-key or self-hosted inference.

Variable, sensitive workloads fit the model

Factory is positioning OpenCompute for organizations that need elastic coding-agent capacity while retaining control over execution infrastructure. Its cited use cases include:

1. Interactive Droid sessions that receive a fresh sandbox for each task.
2. Scheduled Automations that start independently as work arrives.
3. Incident investigations launched by monitoring alerts.
4. Bursts of Slack delegations across a development team.

Factory says its team moved from an early prototype to a first customer deployment in six weeks, including support for a bespoke on-premises environment. According to the company, Droids generated the initial custom driver during a flight to the customer site. The vendor-reported account illustrates the intended extension workflow, though it does not provide an independent performance or development-time benchmark.

The bet is portable orchestration

OpenCompute enters a market that includes E2B, Daytona, Modal, Kubernetes Agent Sandbox, Google’s Agent Substrate, and AWS Lambda MicroVMs. These projects span hosted sandbox services, orchestration systems, and underlying execution runtimes, so they compete at different layers.

Factory is placing OpenCompute above those backends as a common orchestration layer. For developers, that approach offers one lifecycle model across several runtimes, explicit capability discovery, and a path to add internal infrastructure through a driver. Its value will depend on the quality of those integrations, the eventual open-source terms, and how reliably the control plane handles large, mixed-provider fleets.