Factory Managed vs Private: choosing the boundary

Factory Managed and Factory Private are two ways to operate the services behind Droid, Factory's coding agent. The main difference is who runs the control plane, the service that coordinates development sessions and stores their context.

With Factory Managed, Factory hosts and operates that service. With Factory Private, the customer hosts it in its own infrastructure and takes responsibility for updates and recovery. Droid can run on customer hardware in either arrangement, so the location of the working copy does not settle who hosts the session. Model requests and telemetry need their own placement decisions.

Factory Managed vs Private changes operational ownership

Consider an organization whose policy permits hosted engineering sessions but requires its own CI runners. Managed can fit that combination: Factory operates the control plane, while the organization maintains its runners, repository permissions, and build dependencies.

Now consider a repository whose policy requires customer-operated session hosting. Private places the control plane in a customer VPC or on-premises environment. The infrastructure team must then provide an upgrade, monitoring, and recovery process for that service as well as the execution machines.

These examples concern placement and responsibility. Both arrangements need approved model routes, restricted execution identities, and review before consequential changes. Customer ownership does not automatically establish those controls.

Follow session and inference data separately

Factory's sovereign software development whitepaper distinguishes Managed control-plane and session-data hosting from Private's customer-hosted placement. In its Managed description, bringing customer-provided models does not remove the required session connection to Factory's control plane.

That distinction matters during procurement. An approved model provider answers the inference question. It does not automatically answer whether the organization permits the hosted service that coordinates the work or stores session context.

Factory's data-flow documentation also separates local file access from model traffic. Droid reads and edits the local working copy. Context used for inference travels to the configured model endpoint. Review both the destination and any services behind it.

Trace one representative task through the execution machine, control plane, model service, and collector. Include failed requests and support diagnostics. Obtain offering-specific retention and processing terms for any path the public documentation leaves open before sending sensitive repository context through it.

Factory Managed vs Private depends on the operating team

For the customer-hosted example, rehearse a failed control-plane upgrade and an unavailable model service. The response may involve different teams, and adding execution capacity will fix neither failure. Include certificate rotation, artifact promotion, and restoring the previous configuration in the operating plan.

For the Managed example, confirm how a hosted-service failure is escalated while keeping local runners and credentials under customer control. Managed operation reduces one category of service work, without removing the need to maintain the environments that build and test code.

Factory's deployment patterns allow different patterns across teams and environments. Any mixed approach still needs clear workload placement rules. Otherwise, developers must make data-classification decisions themselves every time they choose an execution environment.

Treat airgap requirements explicitly

Customer hosting and disconnected operation answer different requirements. A Private deployment can live in a customer VPC with approved connectivity. An airgapped configuration requires the runtime workflow to function without public internet or Factory connectivity.

The airgap documentation describes a dedicated enterprise build that uses customer-configured models and skips Factory-bound work. Cloud features such as session sharing, Slack integration, and Factory-hosted analytics are unavailable. Include those differences in the workflow evaluation.

Validate a disconnected workflow with its internal model endpoint, package sources, source-control service, and collector. Success in a connected environment does not establish that those dependencies are available inside the airgap.

Compare controls through observable behavior

A small maintenance change can expose whether the approved deployment is usable. It should install dependencies from permitted sources, run the relevant tests, and return a patch without needing production credentials.

Factory's Enterprise Controls distinguish organization-enforced policy from local session preferences. Validate the controls that matter to the organization, such as permitted models, command restrictions, sandbox access, and centrally managed hooks.

Exercise negative cases as well as successful work. Confirm that a prohibited command remains prohibited, an unapproved model cannot be selected, and a write outside the allowed workspace fails. Record the control that enforces each result.

Choose Managed when the hosted session boundary is permitted and Factory operation fits the requirement. Choose Private when customer control-plane ownership is required and the operating team can support it. Revisit that choice when data classification or service ownership changes, rather than treating either deployment as a universal security ranking.

Further reading

• Factory Private architecture
• AI code data residency
• Air-gapped AI development that works offline