loading
loading
Introducing OpenCompute By Walker Hildebrand, Sherry Bai - October 14, 2026 - 7 minute read Product Share In a world where agents can work while you sleep, how do we enable them to run on your infrastructure? When the agent lives in a chat window, the answer is straightforward: it runs on the machine you've set up for the session. But when agents investigate alerts, respond to asynchronous requests, execute scheduled Automations, and pick up issues throughout the day, the problem becomes on-demand compute. You no longer just need somewhere to run an agent. You need a compute fleet that can keep up with the work. Today, we're introducing OpenCompute, Factory's self-hosted orchestrator for agent sandboxes on your choice of runtime, now in private preview. OpenCompute brings on-demand provisioning and lifecycle management to customer-controlled infrastructure, integrated with the Factory experience across Environments, Automations, and Remote Control. Your agents get computers when they need them. You choose where those computers run. It's built around a conviction: adopting autonomous software development should not require handing someone else the keys to your infrastructure. So how did we build something in six weeks that let us deploy into a bespoke on-premises environment in two days? In April 2026, we introduced Droid Computers: persistent machines for orchestrating Droids. Customers could create a computer in Factory's cloud or register their own machine through Remote Control. The Remote Control experience makes integration with Factory independent of the compute layer. Run Droid on any machine, connect it to Factory, and work with it remotely. That machine can be a workstation, a cloud VM, or a server inside a private network. Because the agent execution loop runs on that machine, Droid can work with private repositories, package registries, and services in an internal environment. Customers do not have to expose those systems publicly to make them available to an agent. Our support for BYOK and self-hosted inference offers additional control over data sovereignty. Remote Control proved the value of that model, and the broader industry has moved in the same direction. But we started to see another clear gap: our enterprise customers needed a solution for managing fleets of computers, not one computer at a time. Remote Control is a good fit for a persistent machine scoped to an individual user or service: a configured workstation, a development VM, or a box with specialized hardware. It answers the question: how do I bring agents to where I need them most? But we needed compute to meet the demands of entire organizations, supporting interactive sessions while also letting agents operate independently as work arises. An alert should be able to trigger an investigation without someone first provisioning a VM. A burst of Slack delegations should not leave a team counting available machines. A completed task should not leave idle resources running indefinitely. Our managed offering already handled parts of that lifecycle. Self-hosted machines did not have the same native provisioning, suspension, and resumption integration. Customers could run Droid where they wanted, but they were left operating the fleet themselves. We saw wide variation across our customers' cloud infrastructure. Some wanted agents running on existing Kubernetes clusters, some on specialized hardware, and some on an internal platform their developers already depended on. Others were onboarding new microVM infrastructure or shopping for a solution. Our mandate was not just to provide customers with fleets of sandboxes. We had to make fleet management work on any infrastructure. We needed to bring orchestration to the customer's environment, not bring every customer into ours. There is no shortage of work happening on sandbox environments for agents. Third-party cloud sandbox platforms include E2B, Daytona, and Modal. Projects such as Kubernetes Agent Sandbox, Google's Agent Substrate, and AWS Lambda MicroVMs also show growing demand for bring-your-own-cloud and bring-your-own-infrastructure solutions. Each platform makes different tradeoffs across isolation, persistence, startup speed, operational simplicity, and deployment flexibility. A backend that is right for short-lived tasks may not be right for a persistent development environment. A service that works well for a startup may be unavailable inside a regulated enterprise's network. And the best option six months from now may differ from the best option today. We decided to build a layer above the compute infrastructure. OpenCompute owns the common lifecycle: request a computer, bring it into the desired state, track its activity, and suspend or terminate it according to policy and provider capabilities. The provider owns the infrastructure mechanisms that make those operations possible. That lets us benefit from improvements across the ecosystem without making customers wait for us to replace the foundations of our product. OpenCompute development has been agent-native from the start, beginning with a Mission to prove the concept. Our job was to define the boundaries, specify the behavior, and make correctness testable. Droids handled the rest under human direction. That made interface design especially important. "Build support for this provider" is an open-ended assignment. "Implement this contract and satisfy these conformance tests" gives an agent a bounded problem and a verifiable definition of success. The same separation that made OpenCompute flexible for customers made it tractable to build. A new driver, the per-provider integration, could focus on its provider without rewriting fleet management. The shared control plane could improve without learning another cloud API. That approach let us develop and evaluate integrations across AWS Lambda MicroVMs, Kubernetes, EC2, Agent Sandbox, Agent Substrate, and other experimental providers. These were not identical implementations or equally mature backends. That was the point: the architecture could accommodate differences without turning each one into a separate product. The clearest test came with our first customer deployment. The customer needed OpenCompute inside a bespoke on-premises environment with an in-house provider interface. Right before boarding our flight to meet the customer, we kicked off a Mission to build the initial driver for its environment with the information we had. By the time we landed, the driver was built. After two days on-site, the customer provisioned their first sandbox through OpenCompute. From the user's perspective, it looked like creating a managed Droid Computer, but the sandbox was running in the customer's data center. We did not need to invent a new architecture for that customer. We needed to connect its infrastructure to an interface we had already defined. From the early prototype to that first customer deployment: six weeks. That first integration was not the end of the engineering work. Persistence, recovery, deployment tooling, and operational hardening continued afterward. But it validated the central bet: integrating a new provider could be a driver problem, not a platform rewrite. OpenCompute is a self-hosted service that connects the Factory backend to the customer's underlying compute plane. OpenCompute runs in your environment and establishes an outbound, TLS-secured WebSocket connection to Factory. Factory sends authorized compute requests over that connection. You do not need to expose a public OpenCompute endpoint or open an inbound firewall port for Factory. On enrollment, your OpenCompute deployment registers a public key with Factory. On connection, it proves possession of the corresponding private key by signing a fresh challenge. The private key remains under your control and can live in a supported cloud KMS. Each sandbox provisioned by OpenCompute establishes its own outbound connection to Factory, exactly like remotely controlled computers today. Internal repositories and services can remain private. Droid reaches them from inside your network. A note on data placement: Compute placement is separate from inference routing and session storage. Keeping session data entirely local depends on your inference and sync configuration. Provisioning is not a single reliable API call, especially when dealing with unfamiliar providers. Connections disappear. Providers throttle. Processes restart after a request succeeds but before the response arrives. OpenCompute addresses this with a declarative lifecycle model. Its Go control plane records desired and observed computer state in a Postgres database running in your environment. A reconciler continuously works to bring the computer into the requested state. Creating a computer records durable intent rather than holding a request open until a provider finishes. The reconciler handles provisioning and observation, retries recoverable failures, and drives supported lifecycle transitions. Because the intent is durable, a control-plane restart does not erase unfinished work. Computers launch from immutable Builds, separating environment preparation from machine creation. S3-compatible storage holds build artifacts and snapshot payloads. Activity signals and per-computer lifecycle settings tell the control plane when to keep a computer running and when to take lifecycle action. Each provider integration runs as a standalone gRPC driver. The driver translates common operations into the backend's native mechanisms for creating, observing, executing commands on, and destroying computers. Provider-specific behavior stays out of the control plane's database and reconciliation logic. Drivers can use the transport and runtime appropriate to their backend rather than adopting one mandatory guest agent. But a common interface is only useful if it is honest about differences. Not every backend can suspend a computer, snapshot its disk, or fork it. OpenCompute therefore defines a required Core conformance profile and optional Suspend, Snapshot, and Fork profiles. Black-box tests verify the behavior a driver claims to support. Unsupported requests are rejected before changing durable state, rather than surfacing as errors halfway through provisioning. The contract is also vendor-neutral. Factory is one possible client of OpenCompute, and drivers stay agnostic to Factory-specific features. OpenCompute exposes its own API, CLI, and administration panel because the layer managing your compute should be useful independently of the product that first asked for it. We plan to open-source OpenCompute. The goal is not merely to publish the implementation, but to make the contracts, conformance tests, and driver model useful to people building agent systems. We also see it as the foundation for Factory's future. Interactive sessions, scheduled Automations, incident investigations, and delegated work should not each need their own infrastructure story. They should be able to request the environment they need through the same lifecycle layer, whether Factory or the customer operates it. We are excited to put that foundation in more hands and see which providers people connect next. The future of agentic workloads will not run on one kind of machine in one company's cloud. OpenCompute is how we intend to build for that future. OpenCompute is now in private preview. If you are interested in exploring OpenCompute, contact your account owner at Factory. Start building
document fetched 2026-10-24 10:05