Factory Managed vs Private: choosing the boundary

September 24, 2026 - 5 minute read

Factory Managed vs Private is primarily a decision about control-plane ownership and the boundary around development data. Running an agent on customer hardware does not, by itself, establish where session data, inference requests, or operational records live.

Choose the deployment by writing down which services the organization can consume and which it must operate. That makes the decision reviewable. It also prevents a team from accepting an operating burden it did not budget for, or discovering a prohibited data path after a pilot succeeds.

Factory Managed vs Private changes operational ownership

Factory Managed provides a Factory-hosted control plane with managed orchestration, analytics, and operations. Droids can execute across developer environments and customer infrastructure. The customer still operates its local machines and CI environments.

Factory Private places the control plane in customer-owned infrastructure, such as a VPC or an on-premises environment. The customer governs the deployment through its own identity, network, and security controls, and controls updates.

Compare the options by the responsibility that moves, rather than treating private as a general synonym for secure. Both need an approved model path, appropriate agent permissions, and a clear review process.

With Managed, Factory operates the hosted control plane while teams can use local machines, CI/CD, customer infrastructure, or Factory-managed Droid Computers for execution. Managed customer content sits within Factory's tenant-isolated environment.

With Private, the customer operates the deployment and controls updates within its own infrastructure. Local machines and CI/CD still need appropriate access controls. Customer infrastructure controls work alongside Factory's agent controls rather than replacing them.

Use this comparison to identify the team responsible for each service. The decision is incomplete until that team agrees to the responsibility and has a way to meet it.

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.

Ask the deployment reviewer to approve a concrete data-flow diagram. Include the execution machine, control plane, model service, telemetry collector, and connected tools. Identify which data each connection carries, including error paths and support diagnostics.

Where public material leaves a detail open, obtain the offering-specific answer during the architecture review. Record that answer with the approved configuration. A broad product label should never substitute for an explicit agreement about session handling, retention, or downstream processing.

Factory Managed vs Private depends on the operating team

Managed control-plane operation can fit an organization that permits the hosted data boundary and wants Factory to own that service. The infrastructure team can concentrate on the execution environments, model integrations, and controls it still owns.

Private fits a requirement to place the control plane or sensitive development data in customer infrastructure. It also creates work for the operating team. Release promotion, recovery, certificate rotation, service monitoring, and capacity planning need a home in the organization's existing processes.

Estimate that work using the proposed deployment, not a generic self-hosting multiplier. Identify the components operators will monitor and the procedures they will maintain. Ask who handles a failed upgrade and who responds when the model service becomes unavailable.

Avoid turning the choice into a universal ranking. An organization with a mature internal platform may be prepared to operate Private. Another may prefer a managed control plane for permitted workloads while reserving a different boundary for restricted repositories.

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 and GovCloud 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.

Do not assume a connected pilot validates the isolated version. Reproduce the task with the actual internal model endpoint, package sources, source-control system, and collector. Verify both the result and the absence of unapproved runtime traffic.

Factory FedRAMP is a separate GovCloud offering with authorization in progress. GovCloud hosting, customer hosting, and completed authorization are distinct facts. A requirement for one should not be interpreted as approval of the others.

For a federal evaluation, confirm the current offering scope, deployment responsibilities, supported model arrangements, and authorization status with the appropriate reviewers. Keep that decision separate from the commercial Managed versus Private comparison so that assumptions do not cross between offerings.

Compare controls through observable behavior

The same task can be a useful evaluation case for either deployment. Give Droid a bounded change, a known test suite, and an explicit review requirement. Use equivalent repository permissions and model conditions where the approved boundaries allow them.

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.

Compare review burden and accepted output, not just elapsed execution time. A fast run that needs extensive correction may be less useful than a slower run that reliably satisfies the task. Also record deployment-specific operator work, such as repairing an internal package source or adjusting a hosted integration.

Preserve the test inputs and configuration so later evaluations remain comparable. Changing the model, repository, permissions, and task simultaneously makes it difficult to explain why one run differs from another.

Make the choice an explicit acceptance record

The final deployment decision should state the permitted workloads, approved services, and operating responsibilities. Include the data classes allowed in prompts and tool outputs, the model routes they may use, and the records retained for review.

Document the boundary's exceptions. A support process, external connector, or fallback endpoint can introduce a data path that the primary diagram omits. Either approve it explicitly or remove it before the deployment becomes routine.

Set expansion criteria around observable outcomes. A pilot should produce validated changes, manageable review effort, and predictable operations. Define who can approve another repository or team and which evidence they must review first.

Revisit the decision when its inputs change. A new regulatory requirement, a different model endpoint, or a revised operating model may justify a different deployment. Version the acceptance record with the configuration so future reviewers can understand what was approved.

The useful outcome is a deployment the organization can explain and operate. Factory Managed and Factory Private provide different ownership arrangements. The right choice is the one whose actual data flows, responsibilities, and supported workflow satisfy the workload's requirements.