Deployment Models

FaburAI is two independently deployable planes — a Control Plane and a Data Plane — and deployments/ holds the raw building blocks for running them: no Helm chart, no operator, just plain Kubernetes manifests plus a Docker Compose file for local dependencies. Each plane gets its own Namespace, its own single-replica Deployment (labeled faburai.io/plane: control or the Data Plane equivalent), its own Service, and its own dedicated Postgres — cp-postgres with a 2Gi PVC for the Control Plane, a matching dp-postgres for the Data Plane. Nothing is shared between the two at the infrastructure level; they only talk to each other over HTTP (FABURAI_DP_CP_ENDPOINT).

What actually varies across "SaaS," "PaaS," "private cloud," "on-premises," and "air-gapped" is not the manifests — the same Deployment/Service/Namespace shapes apply everywhere — but who operates them and how many Data Planes exist. In the SaaS model, FaburAI runs one Control Plane and provisions a Data Plane namespace per tenant on FaburAI's own infrastructure (this is the path control-plane/modules/provisioning and the cluster fan-out logic in control-plane/modules/clusters are built for). In a private-cloud, an on-premises, or an air-gapped install, the customer applies these same manifests inside their own cluster and runs both planes themselves — the Control Plane's Cluster Registry and the tenant credential-apply flow exist specifically so an operator can register and manage Kubernetes clusters that are not FaburAI's own.

Configuration is entirely environment-variable driven: DATABASE_URL for each plane's own Postgres, FABURAI_CP_EXTERNAL_ENDPOINT / FABURAI_DP_EXTERNAL_ENDPOINT for the public URL each plane answers on, Auth0/OIDC issuer, client ID, and audience for authentication, and a FABURAI_DP_SECRETS_KEY (sourced from a Kubernetes Secret, not inlined) for the Data Plane's own connector-credential encryption. This is what makes the same manifests usable across models — a private install swaps in its own Postgres endpoint, its own Auth0 tenant, and its own external hostnames without any change to the deployment shape itself.

deployments/ also carries a handful of demo-only manifests (aws-demo, snowflake-demo, hr-demo, iceberg-demo) for standing up sample MCP servers to govern, and an edge-demo Docker Compose stack that runs the Policy Enforcer, an Envoy front door, and a placeholder MCP server together to demonstrate distributed enforcement at the network edge — useful for evaluating the product, not part of a production deployment model itself.