Deployment Options

Factory offers two deployment options: Factory Managed and Factory Private. In both, Droids run on developer laptops and in CI pipelines, and Enterprise Controls govern models, access, telemetry, and autonomy. The options differ in where Droid sandboxes run and who operates the infrastructure they run on.

Choose a deployment option, then combine Droid with proxies, custom CAs, mTLS, sandboxed containers, and managed settings.

Choose a deployment option

Start with Factory Managed. Choose Factory Private when a specific regulatory or policy requirement rules out Factory Managed.

Factory Managed

Factory runs the control plane in Factory's cloud and provides orchestration, analytics, and operations. Droid runs on developer machines and build infrastructure, and sessions that need a sandbox can run on Factory-managed compute. LLM traffic can still be routed through your own gateways and providers; Factory does not need to broker model access.

To keep tighter control of your data without leaving Factory Managed, set a shorter session retention period. Organizations with European data-residency requirements can use the dedicated EU deployment.

Factory Private

Factory Private places some of Factory's infrastructure in your VPC. By default, Factory runs the control plane in Factory's cloud, and Droid sandboxes run in your VPC through OpenCompute. When a session, Automation, or other feature needs a sandbox, the control plane requests it from OpenCompute, which provisions the sandbox in your infrastructure. OpenCompute connects out to Factory, so you do not open inbound firewall ports.

Code execution stays in your VPC, and sandboxes reach internal repositories, package registries, and services without exposing them to the internet. Your team operates OpenCompute and the infrastructure it runs on, including upgrades, monitoring, capacity, and cost, and your IAM, network, and security controls govern that infrastructure. Model inference and session storage follow your model configuration and data settings.

If your requirements also rule out a Factory-hosted control plane, contact your Factory account team to discuss a Custom Deployment.

Outbound network allowlist

If your firewall or proxy only allows approved destinations, allow HTTPS (port 443) to the Factory hostnames below. This applies to developer machines, CI runners, and Factory Private infrastructure in your VPC. Allowlist by hostname, not IP address: these hosts sit behind cloud load balancers and CDNs, and their IP addresses change without notice.

Organizations on the EU deployment also need the regional hosts app.eu.factory.ai, api.eu.factory.ai, relay.eu.factory.ai, and prem.eu.factory.ai.

An Airgapped Deployment needs none of these hosts.

The list covers Factory itself. Also allow the model providers or LLM gateways you configure through Custom Models (BYOK), your source control host, and any MCP servers or package registries your sessions use. Run droid doctor to check connectivity to the Factory hosts from a given machine.

Proxies, custom CAs, and mTLS

Enterprise networks frequently require HTTP(S) proxies, organization-specific certificate authorities, and mutual TLS.

HTTP(S) proxy support

Droid respects standard proxy environment variables:

export HTTPS_PROXY="https://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
 
# Bypass proxy for specific hosts
export NO_PROXY="localhost,127.0.0.1,internal.example.com,.corp.example.com"

Use these to route traffic from Droid to LLM gateways and any Factory cloud endpoints through your corporate proxy.

Custom certificate authorities

If your organization uses custom CAs for HTTPS inspection or internal endpoints, configure the runtime environment so Droid trusts those CAs (for example, via NODE_EXTRA_CA_CERTS or OS-level trust stores).

Mutual TLS (mTLS)

For environments that require client certificates when calling gateways or internal APIs, configure your containers, VMs, or runners with the appropriate certificate, key, and passphrase. These settings are usually handled at the HTTP client or proxy layer that Droid uses.

Running in secure containers and VMs

Running Droid inside hardened containers and VMs is one of the most effective ways to bound the blast radius of any agent mistakes or misconfigurations.

See Agent Safety & Controls for how autonomy, allow/deny lists, and Droid Shield interact with these environments.

EU deployment and data residency

For Factory Managed, Factory operates a dedicated EU deployment, fully isolated from the Global (US) deployment, with its own backend, database, and LLM inference endpoints in Europe. Each Factory client (CLI, desktop app, and web app) ships as a single build that works in both regions; after login, the client detects the organization's region and routes all subsequent requests to the correct deployment.

Infrastructure

The EU API backend is hosted within the European Economic Area and reachable at api.eu.factory.ai; the EU web app is served from app.eu.factory.ai. Add the EU hosts to your outbound network allowlist. Outbound LLM traffic from the EU backend targets EU-region provider endpoints only.

Data residency

• Stored in the EU: session content (prompts, assistant messages, tool calls and results, Droid messages, Git AI notes, and Git AI checkpoints) lives in a managed database instance in Europe, provisioned separately from the global database with its own credentials, backups, and access controls. Raw request and response bodies are never written to logs or object storage.
• Stored in the global deployment (US): organization records (a small pointer document with the org's region tag), user profiles, and billing data. These contain no user-generated content and are required for cross-region authentication and account management.

Inference

All LLM requests from EU organizations are dispatched to EU-region endpoints only; prompts and conversation history do not transit US infrastructure. Models or providers not available in the EU are hidden in the model picker and rejected at the server. See Models for the current catalog.

Region enforcement

Identity is global (WorkOS-based SSO), but each organization is pinned to a region at creation time. Region matching is enforced at multiple layers so traffic and data can never be served by the wrong backend.

• Server-side. Session data access and LLM inference are both gated by region-aware checks. Requests for an organization whose region does not match the deployment fail closed, and requests for ineligible models or providers are rejected before any traffic is dispatched. EU traffic cannot reach US-only data or providers, and Global traffic cannot reach EU-only routes.
• Client-side. After login, each client reads the org's region and routes all subsequent API requests to the matching backend. Each canonical web hostname (app.factory.ai, app.eu.factory.ai) is statically backed by exactly one regional backend; users who land on the wrong region are shown a redirect page (not signed out). The desktop app targets the matching API host on every request, and the CLI pins the region to the local token cache on first login, re-deriving it on logout and re-login.

Configuration surfaces

Network and deployment configuration is expressed through:

Environment variables

Proxies, gateways, OTEL endpoints, custom certificates.

Org and project .factory/settings.json

Managed settings for model access, sandbox network rules, IP restrictions, feature gates, and defaults.

Org config endpoints

For large organizations, a central configuration service can distribute a standard .factory bundle to all environments.

System-managed settings.json

For MDM-deployed fleets and machines that never sign in, drop a settings file at a hardcoded platform path so org policy is in effect before any user authenticates. See Enterprise Controls & Managed Settings.

That same reference covers the full settings hierarchy and merge behavior.