Frequently Asked Questions
What is Farna Control?
Farna Control is a self-hosted Delivery Governance Platform for the software development lifecycle (SDLC). You define the lifecycle, pipelines, policies, and review gates; Farna Control governs work across code, dependencies, security, release, documentation and knowledge, evidence, and remediation. Issue-to-PR automation is one example of the broader lifecycle. See What is Farna Control?.
Is it self-hosted?
Farna Control runs on your infrastructure, deployed with Docker Compose, the Helm chart, or the native installers (Linux or macOS). Telemetry and tracing are off by default, so an instance left at its defaults sends nothing. With default settings and no connectors configured it makes no external network calls, so it is air-gap capable. Self-hosting is how you retain control of the governed record; it is supporting proof of the platform’s purpose, not the category itself. See Installation and Configuration.
Which tiers are there, and what does each include?
The Community tier (Personal) is free and self-hosted: unlimited pipelines, team collaboration, per-agent token budgets, a pipeline spend circuit breaker, an org-wide pause (kill switch), community support, run-level inspection, and capture of the governance record. Team is a paid feature-gate add-on (current price on pricing) that adds single sign-on (SSO), Security Assertion Markup Language (SAML), role-based access control (RBAC), the audit viewer, chain verification, audit exports, signed evidence packs for offline verification, the compliance evidence index, organization and team spend limits, a budget overview, and a cost breakdown. Team is a self-hosted feature unlock, separate from any Enterprise agreement, and it comes with no uptime service-level agreement (SLA) and no contractual SLA.
What support is included?
A Team subscription includes direct, asynchronous support from the team, with a response within 24 hours, seven days a week. There are no sales calls and no account managers. Product-side defects (bugs in Farna Control itself) are fixed and shipped in a release. There is no uptime SLA and no contractual SLA: Farna Control is self-hosted and you operate the infrastructure. Self-hosting and third-party issues are covered by documentation and the community.
How are credentials handled?
Farna Control encrypts connector credentials and model backend API keys at rest with Fernet and decrypts them only in-process at run start. They never enter run state, checkpoints, logs, or telemetry spans. See Secrets.
Which large language model (LLM) providers are supported?
Hosted providers include Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI and Gemini, Mistral, Cohere, Groq, DeepSeek, xAI Grok, Alibaba Qwen, and others. Self-hosted OpenAI-compatible servers such as Ollama, vLLM, TGI, LM Studio, llama.cpp, and LocalAI are also supported. You can mix providers within the same pipeline. See Model Backends for the full list.
Which tools can I connect?
Farna Control ships 43 connector types covering source control, continuous integration and delivery (CI/CD), ticket tracking, messaging, monitoring, security scanning, and more, including GitHub, GitLab, Notion, filesystem, and any REST API. See Connectors.
Can I require human approval before agents act?
Yes. Human-in-the-loop (HITL) checkpoints pause pipeline execution for human review. See Human-in-the-Loop.
Is there an audit trail?
Farna Control captures the governed record at the run boundary. A run keeps its immutable definition snapshot, inputs, reported node outputs, timing, gate results, human decisions, and final artifact for run-level inspection through the API. Separately, significant governance events such as run starts, agent dispatches, human decisions, gate outcomes, sign-ins, permission changes, and configuration changes are appended to an organization-scoped SHA-256 linked audit chain. This is a tamper-evident record: changes become detectable through the links, but no software can make a record tamper-proof against someone who controls the database and its backups. The Community tier records this data. Team adds the audit viewer, chain verification, paginated and full-chain exports, signed evidence packs for offline verification, and the compliance evidence index. These are different surfaces: capture is the record written during execution; viewing and verification inspect it; export moves it out; a signed evidence pack packages a bounded chain for third-party verification; the compliance index maps Farna Control-produced artefact types to a customer’s audit period but does not create a compliance attestation or a single compliant/not-compliant verdict. See Architecture for the audit logger layer.
What stage is this?
Pre-release alpha. The platform is functional and being used in development, and breaking changes may occur. The Community tier is free; the Team tier is available as a paid, self-hosted feature add-on.
How do I get started?
See the Installation guide. Clone the repository and run docker compose up -d to start everything: PostgreSQL, Redis, the API, the frontend, and the queue workers. The first run builds the Docker images.
Can I use my existing agents?
Yes. You never rewrite your agents to use Farna Control. If an agent can run from a terminal or a CI/CD job, Farna Control can govern it.
Farna Control connects to existing agents through two execution patterns:
- Containerized or CLI agents: Point a pipeline node at your container image or command (Docker, a Kubernetes pod, or an E2B sandbox). Farna Control provisions the execution environment, passes the task context, and reads back the result.
- CI/CD dispatch: Farna Control triggers the continuous integration (CI) system that already runs your automation (GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins, TeamCity, or internal webhooks) via dispatch, passes parameters, and with
await_completionawaits completion to record the outcome in the governed run.
Communication follows standard Unix I/O conventions: inputs arrive via command-line arguments, environment variables, or JSON payloads; outputs are evaluated via exit code (0 = success) and structured output or artifacts. Typed input and output schemas are opt-in when you want contract validation. Your agent logic and tools remain unchanged; Farna Control handles orchestration, policy gates, and audit capture. See Farna Control with your existing agent runtimes, Connectors, and Execution Environments.
Can I drive Farna Control from a Model Context Protocol (MCP) client such as Claude Desktop or Cursor?
Yes. Farna Control runs a Remote MCP server. Add it to your client using the URL and configuration snippet shown at Settings > MCP, and authenticate with an MCP API key or an OAuth client application. From MCP you can list pipelines, trigger runs, read run output, browse the library, and act on human-in-the-loop gates. Gates marked human-only require a credential linked to a human account: a browser sign-in, or a local MCP client holding a consent-derived OAuth token for a human member. An MCP API key or a service-account credential cannot decide one. MCP is included in the free Community tier. See MCP and Human-in-the-Loop.
Do I have to replace my CI/CD tooling?
No. Farna Control governs the agent and automation steps around your existing tools and leaves your build and test tooling in place. CI-runner connectors for CircleCI, GitHub Actions, GitLab CI, Buildkite, Jenkins, TeamCity, and Azure Pipelines are supported today, and a pipeline dispatch node can start a run, wait for it, and fold the outcome into the same governed run. Issue-to-PR handling is one example; the same governed lifecycle can include dependency and licensing work, security remediation, release, documentation, evidence, and other stages. See Connectors and Lifecycle Maps.
Where does agent code actually run, and who controls it?
You choose per environment profile. The local provider runs agent commands as subprocesses on the Farna Control host with no sandboxing, which suits evaluation and solo development. The runner_docker provider gives each workspace an ephemeral hardened container, and you can point it at a Docker engine you own, including a remote host on your network. The e2b provider gives each run an isolated sandbox. The kubernetes provider runs each workspace as a long-lived pod in your cluster, hardened with a non-root user, a read-only root filesystem and dropped capabilities, and registered when MODULO_KUBERNETES_ENABLED is set. Pipelines are portable across providers. See Execution Environments.
How do I control agent spend?
Community includes per-agent token budgets that hard-stop an overspending run, a per-pipeline monthly spend circuit breaker that pauses that pipeline’s triggers when it trips, and an org-wide pause that stops all new trigger-initiated runs. Team adds organization-level and team-level daily spend limits, a budget overview with alert thresholds, a monthly cost breakdown, and spend-anomaly detection. See Cost Management.
What happens when an agent fails or produces bad output?
Where a schema is declared, output is validated against it before anything downstream sees it, and evals can score or block it. A failing eval can route the run to human review rather than failing outright. When a reviewer rejects an output, Farna Control records a Feedback Record, can spawn a correction run with the original context and the rejection reason, and flags the rejection as an eval gap when no existing eval caught it. See Evals, Feedback System, and Pipelines.
Can I get audit evidence out of Farna Control?
Yes, with separate boundaries. Every tier captures run-level truth and significant governance events in your own instance. Community exposes run data through the API, including the immutable run snapshot and reported outputs, but the administrative audit surfaces are Team features. Team provides the audit viewer, chain verification, paginated JSON and full-chain JSONL or CSV exports, a signed evidence pack with an embedded Ed25519 public key for offline verification, and the compliance evidence index. The evidence pack is an export artefact, not a certification or a promise that the underlying record is tamper-proof. The compliance evidence index is an inventory of Farna Control-produced evidence for an audit period; it does not attest that an organization is compliant and it does not supply customer-owned evidence produced outside Farna Control. See Architecture and Licensing.
What infrastructure does Farna Control need?
Farna Control v1 targets Linux server hosts. The supported way to run Farna Control is Docker Compose, which is distribution-agnostic apart from Docker itself: any Linux distribution that can run Docker 24+ and Docker Compose v2.20 or later works, and the production configuration brings up the API, the frontend, queue workers, PostgreSQL 16, and Redis. On Linux, a native installer is also available (Ubuntu 22.04 LTS+ or Debian 12+, glibc 2.35 or newer). macOS has a native installer, a signed and notarized .dmg for Apple Silicon; an Intel (x86_64) build is forward-looking until that release artifact is published, and Rosetta is not required for the Apple Silicon build. Windows is in Beta scope, opt-in only: a native Windows installer is in progress and no signed Windows installer is published yet, so until it ships a Windows-hosted deployment means Windows Server running the Linux Docker stack in a VM or container host. See Installation for the full platform support matrix.
Does any data leave my network?
Farna Control has no telemetry by default, opt-in only. OpenTelemetry is off by default, and once enabled it exports only to the collector endpoint you configure. Farna Control is air-gap capable. Model calls go only to the providers you configure, so pointing a model backend at a local endpoint such as Ollama, vLLM, or LocalAI keeps inference inside your network. Connectors call the tools you connect, so those calls leave your network when the tool is external. See Model Backends and Configuration.
Does Farna Control support SSO, SCIM, and role-based access control?
Yes, in the Team tier. Farna Control supports OpenID Connect (OIDC) and SAML 2.0 single sign-on with just-in-time provisioning, System for Cross-domain Identity Management (SCIM) 2.0 user and group provisioning from providers such as Microsoft Entra ID (formerly Azure AD), Okta, and OneLogin, and team-scoped role-based access control (RBAC) with admin, operator, and runner roles. The Community tier includes basic user management without these. See Single Sign-On and SCIM Provisioning.
Related
- What is Farna Control?: product overview
- Architecture: system design and layers
- Getting Started: first pipeline walkthrough
- Configuration: environment variables and setup