Supported environments

Docker Compose

The straightforward path for local development, evaluation and test environments. Compose runs the application, database and queue together so you can validate a pipeline without building a cluster.

Kubernetes

The recommended production shape. Separate the control plane and runners, use your existing ingress and network policy, and operate Postgres and Redis with the reliability controls your organization requires.

Air-gapped reference stack

Supported when the stack is proven in your environment. Mirror images, provide a local model backend and allow only the connector destinations you explicitly configure.

What runs where

You decide the placement and operating boundaries of each part of the system.

Control plane: The Farna Control application serves the API and UI, validates pipeline graphs, creates run snapshots and records governance events.
Runner: Workers execute queued runs and dispatch configured agents. Place them close to the repositories, model backends and private systems they must reach.
Database: Postgres stores configuration, run evidence, audit records and encrypted secrets. You operate its storage, access, backups and recovery.
Queue: Redis carries execution coordination and queue state. Run it with the availability and persistence settings appropriate to your deployment.
Model backends: Use a provider you choose, including an internal or local endpoint. Farna Control routes calls to the backend configured for a node; it does not supply model capacity.

A clear operating boundary

Your responsibilities

Provide infrastructure, capacity, upgrades and access controls.
Operate backups, restore tests and disaster recovery.
Terminate TLS and enforce network policy.
Hold model-provider accounts and manage their residency and usage terms.
Create and rotate connector credentials and decide which destinations are reachable.

Farna Control responsibilities

Ship the application and its documented deployment shape.
Record the hash-chained audit trail and run-level evidence.
Encrypt connector, model and application secrets at rest.
Publish signed release artifacts and their verification material.

Air-gapped deployment

An air-gapped deployment is a controlled configuration, not a claim that every integration works without network access. Start with a proof-gated reference stack and verify the exact image, storage, model and connector assumptions in the target network.

Mirror images. Copy Farna Control, Postgres and Redis images into an internal registry before the isolated install.
Use a local model backend. Run Ollama, vLLM or another supported internal endpoint; external model accounts are not required for the run path.
Opt in to private ranges. A local model endpoint requires the explicit private-range setting; private network access is not enabled by accident.
Permit connector-only egress. When connectors are configured, allow only their declared destinations and any notification endpoints you choose.

Team identity configuration

The Team tier adds organization-scale identity controls. Configure SSO with SAML 2.0 or OIDC against the identity provider you operate, then use SCIM provisioning to create, update and deactivate accounts from that directory.

Team-scoped RBAC separates what viewers, runners, operators and admins can do. Your identity provider remains the source of authentication policy; Farna Control records sign-ins, permission changes and approvals in the local audit trail.

No Farna Labs hosting or phone-home

Farna Labs does not host your Farna Control instance and does not sit in the request path of a run. There is no phone-home license check or required telemetry. Data leaves your instance only towards the model backends, connectors and notification endpoints that you configure.