Factory Private architecture inside your boundary

September 24, 2026 - 5 minute read

Factory Private architecture starts with ownership of the control plane. The service that coordinates development work runs in customer-controlled infrastructure, alongside the execution environments and approved services the organization chooses. That placement gives an infrastructure team a concrete system to operate and a security team a boundary to inspect.

Factory Private supports a customer-owned control plane in a VPC or on-premises environment. Choosing it also means accepting operating responsibilities. Model access, network policy, telemetry retention, and upgrades need named owners before developers depend on the deployment.

Factory Private architecture separates ownership decisions

A deployment diagram should show where work executes and where its supporting services live. Those locations can differ. An agent running on a laptop can still depend on a hosted control plane, a remote model endpoint, and a separate analytics service. Moving only the laptop into a private subnet leaves those other decisions unchanged.

Factory's deployment patterns documentation distinguishes cloud-managed, hybrid, and fully airgapped operation. Droid can run on developer machines, CI runners, VMs, or containers. The pattern determines which services remain reachable and where model and telemetry traffic terminates.

For a Private evaluation, draw the proposed control plane, execution environments, model gateway, source-control service, artifact repositories, and collectors. Label the operator of each component. Then label every connection with the information it carries and the identity permitted to use it.

This exercise often reveals a dependency that a high-level architecture misses. A repository may be internal while its package registry is public. A model gateway may have a private address while forwarding requests to an external provider. Neither arrangement is inherently unacceptable, but both require an explicit decision.

Keep the approved diagram with the deployment configuration. Review changes to either together. A new model route or plugin source changes the effective architecture even when no infrastructure resource moves.

Model placement determines where context travels

Local file access and local inference are separate properties. Factory's data-flow documentation explains that Droid reads and edits files on the machine where it runs. File contents used as model context travel through the configured inference path.

An evaluator should follow that path past the first endpoint. Record the model service behind a gateway, its hosting region, its operator, and the retention settings that apply to requests. A private DNS name establishes very little about those downstream properties.

Factory supports custom model endpoints through BYOK. That lets an organization choose a permitted inference destination, but the endpoint's privacy guarantees still come from its configuration and the relevant provider agreement. Customer ownership of the control plane does not automatically establish the model provider's retention policy.

Use a representative, non-sensitive repository to validate the proposed route. Observe destination hosts and gateway logs during a complete task, including retries and failed requests. Check that the observed route matches the architecture review.

If the deployment requires entirely internal inference, verify that every permitted model resolves to an in-network service. Document what happens when that service is unavailable. An operational fallback must stay within the same approved boundary.

Factory Private architecture needs independent controls

Infrastructure placement creates the setting for agent execution. Permissions determine what execution can accomplish. Treat these as separate review items so that a successful deployment does not become an implicit grant of broad access.

Factory's Agent Safety & Controls describes command controls, hooks, sandboxing, and Droid Shield. A command denylist asks for confirmation. A command blocklist prohibits execution without an approval path. Those mechanisms serve different purposes and should reflect the organization's actual policy.

For an initial deployment, give Droid access to a bounded working copy and the tools needed to validate it. Keep production credentials outside that environment. Let existing source-control protections govern how the resulting change reaches a protected branch.

Network controls deserve the same specificity. Permit the model endpoint, internal Git service, required package sources, and approved collectors. A general route to the corporate network may expose systems unrelated to the task. Restricting internet access alone leaves that internal exposure intact.

Test policy with harmless negative cases. Attempt a write outside the permitted workspace and a connection to an unapproved test destination. Record whether the operating system, sandbox, or application policy blocked the attempt. A reviewer should be able to identify the enforcement point without relying on the model's explanation of its own behavior.

Treat observability as part of the data boundary

Logs can contain information as sensitive as the source repository. Decide what the deployment needs to measure before enabling detailed collection. Activity metrics, model-service logs, and raw interaction content answer different questions and create different retention obligations.

Factory's telemetry documentation describes customer-owned OpenTelemetry export. Metrics are the default customer export. Message content can be exported separately as trace spans to a customer-configured collector. The collector is therefore a deployment component with its own access controls, storage policy, and operational owner.

Start with the evidence needed to support the pilot. Tool activity and execution duration can help identify a stalled workflow. CI results establish whether the proposed change passed validation. Source-control records identify what reviewers approved. A full transcript may be unnecessary for those questions.

Where content export is justified, review the material it can include before enabling it. Command arguments and tool results may carry secrets or test data. Apply the appropriate controls to the collector and its downstream destinations rather than assuming the word telemetry implies a low-sensitivity dataset.

Also test the absence of data. A healthy dashboard can conceal a runner that never received the collector configuration. Confirm coverage for each execution environment and establish who investigates gaps.

Plan operations before expanding the pilot

Factory Private leaves upgrade timing under customer control. That flexibility requires a release process. Identify who receives artifacts, validates them, approves promotion, and restores the previous version if necessary. Keep the process usable during an incident, when the primary administrator may be unavailable.

Model operations need a parallel plan. A new model version can change task behavior even when the Droid build stays fixed. Validate it against representative work, including tests that have previously caught incorrect changes. Preserve the configuration used for each evaluation so comparisons remain meaningful.

Capacity planning should cover the constrained dependency. More execution workers will not help if the model service is saturated or a package mirror cannot serve builds reliably. Measure queueing and failed work in the pilot before deciding which resource to expand.

Establish a support path that respects the boundary. Agree on which diagnostics can leave the environment, who approves their release, and how sensitive content is removed. A support archive should not become an undocumented exception to the deployment's data-handling rules.

Recovery deserves a rehearsal. Restore a disposable environment from the approved artifacts and configuration, reconnect the permitted services, and run a known task. Record what required manual intervention. Those findings are more useful than an untested statement that the deployment is recoverable.

Use a pilot to prove the operating agreement

Factory's sovereign software development whitepaper recommends starting with a measurable workstream. A useful Private pilot can be a recurring maintenance task, a bounded modernization change, or a defined remediation backlog. Keep the scope small enough that reviewers can inspect both the result and the operating process.

Write acceptance criteria before the first run. Include the allowed data paths, the validation required for a change, and the evidence needed for review. Assign owners for the control plane, model service, execution environment, and collector. Resolve ownership gaps before increasing the workload.

Measure accepted work alongside the effort required to produce it. Track validation failures, reviewer corrections, and operator intervention. These measures help distinguish a workflow that reliably produces reviewable changes from one that merely generates frequent output.

At the end of the pilot, compare the observed system with the approved architecture. Record exceptions and decide whether to remove them, accept them explicitly, or change the deployment. Expansion should follow a repeatable operating agreement, not just a successful demonstration.