Deployment Patterns

Droids are designed to run anywhere: on laptops, in CI pipelines, on VMs and Kubernetes clusters, and in fully airgapped environments.

Choose the deployment pattern that matches your data boundary, then combine Droid with proxies, custom CAs, mTLS, sandboxed containers, and managed settings.

Choose a pattern

Factory supports three canonical patterns. The difference between them is how far data travels and where the boundary sits. The runtime is the same in every case. You can mix patterns across teams and environments.

Use this table to pick a starting point, then read the notes below for the trade-offs.

Cloud-managed

Droid runs on developer machines and build infrastructure, while Factory cloud provides orchestration and optional analytics. LLM traffic can still be routed through your own gateways and providers; Factory does not need to broker model access. This pattern suits organizations that allow well-scoped cloud usage but want strong governance over models, keys, and telemetry.

Hybrid

Droid runs entirely within your infrastructure (on your VMs, containers, CI runners, and remote dev environments) while you may still use Factory cloud selectively for coordination. LLM traffic goes through your gateways or cloud providers under your accounts, and OTEL telemetry stays in your observability stack. Factory cloud sees only limited metadata (for example, org and project identifiers) if you enable cloud features. This pattern is common where network segmentation and central governance are mandatory.

Fully airgapped

Droid runs in an isolated network with no outbound internet connectivity. Models are served from on-prem or in-network endpoints, and OTEL collectors live entirely inside the airgap. Factory cloud is not reachable at runtime; binaries and configuration are imported through your own artifact repositories or offline processes. This is the default pattern for national security, defense, and other highly classified workloads.

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

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. Customers should allowlist *.factory.ai hostnames. 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 and airgapped fleets, 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.