Skip to main content
Definite ships an on-prem distribution you can run in your own AWS, GCP, or Azure account. You get the full platform (data lake, semantic layer, dashboards, Fi) inside your VPC, with your data never leaving your network. The install has three pieces:
  1. Cloud infrastructure: a Kubernetes cluster, a Postgres database, and an object store. For AWS we publish a Terraform module that provisions these with sane defaults. For GCP and Azure, follow the per-cloud guide below; a Terraform module for each is on the roadmap.
  2. The definite CLI: a single binary that installs the platform onto the cluster from a config.yaml you fill in with values from your infra.
  3. Day-2 operations: upgrades, maintenance, license, and logs, all driven through the same CLI.

​
Default URL and DNS

The default install path uses Definite-brokered DNS and TLS. During setup, the definite CLI provisions a Definite-hosted URL for your deployment: 
https://<slug>.onprem.definite.app
You do not need to configure customer-owned DNS before the first successful install. After the cloud load balancer exists, the CLI calls the Definite setup broker, receives the *.onprem.definite.app URL, waits for DNS/TLS readiness, and continues the install. Customer-owned DNS is still supported, but treat it as an advanced/custom production option after the system is healthy. Private or internal-only production deployments may need a customer-owned hostname plus a customer certificate or private CA. Do not use nip.io, cert-manager, or Let’s Encrypt as the default first-run path.

​
Install guides

AWS (EKS + RDS + S3)

Provision with Terraform, install with the definite CLI.

GCP (GKE + Cloud SQL + GCS)

Provision with gcloud, install with the definite CLI.

Azure (AKS + Postgres + Blob)

Preliminary guide; reach out if you want to be a design partner.

Install with an agent

Point Claude Code, Cursor, or Windsurf at a single runbook and let it drive the install. The agent asks the discovery questions, fills in config.yaml, and runs the CLI against your cloud account.

​
Authentication

Google SSO

Sign in with Google Workspace via OIDC. Works on any cloud.

Local auth

Email + password (default). The first admin is bootstrapped from your config.yaml.

​
What you’ll need before you start

CategoryWhat
Cloud accountAn account with permission to create a Kubernetes cluster, a managed Postgres, an object store bucket, and IAM resources
Local toolingkubectl 1.28+, helm 3.12+, and your cloud’s CLI (aws / gcloud / az). AWS adds terraform 1.5+
LLM credentialsAnthropic, Bedrock (AWS), Vertex (GCP), or Azure OpenAI
OptionalA Google Workspace account if you want Sign in with Google instead of local auth; a customer-owned hostname only if you are intentionally using custom/private DNS
The CLI’s definite doctor command verifies all of these against your config.yaml before deploying, so you don’t have to keep this list in your head.

​
Architecture

An on-prem Definite deployment is one Kubernetes namespace with these workloads:
  • API: FastAPI service that all clients talk to.
  • Frontend: the Definite web UI.
  • Lakehouse: a single StatefulSet running our DuckLake query engine. Catalog file lives on a ReadWriteOnce PV; bulk data lives in your object store.
  • Job runner: executes scheduled syncs, Python pipelines, and webhook-triggered docs.
  • Fi sandboxes: ephemeral pods spun up per agent run via agent-sandbox CRDs.
External dependencies you bring:
  • Postgres 15+ for the application database (users, docs, automations).
  • An object store (S3, GCS, Azure Blob, or MinIO) for lakehouse Parquet files.
  • An LLM provider for Fi.
See the CLI reference for the full set of commands and flags. The config schema is documented inline in config.yaml and surfaced by definite doctor.