Docs · Self-hosting

Self-hosting

Most teams build against Closure SaaS. Private cloud and regulated installs use the same product — same MCP tools, same graph — with your own control plane URL.

When to self-host

Data residency or network isolation requirements
You must run the console inside your VPC / cluster
You’re evaluating the stack before a SaaS cutover

Otherwise prefer SaaS: no cluster, same IDE experience (npx @closurenetwork/ide init).

Patterns

Pattern	Where it lives	Use when
Helm + Terraform	`closurenetwork/deploy`	Production on-prem / private cloud / AWS EKS
Docker Compose	`platform` deploy/	Sandbox / single-host dogfood (droplet-style)

Helm (recommended for production)

The deploy kit installs console + workers against your Postgres and Redis:

kubectl create namespace closure
# apply secrets from examples/secret.example.yaml — never commit filled secrets
helm upgrade --install closure-platform ./charts/closure-platform \
  -n closure --create-namespace \
  -f ./terraform/examples/onprem-k8s/values-onprem.yaml

Images: ghcr.io/closurenetwork/platform-console (same as SaaS). Full guide: deploy README.

Docker Compose (sandbox)

For a single host matching the SaaS droplet shape, use the compose file in the platform repo:

cp deploy/.env.sandbox.example deploy/.env
# edit secrets / URLs
docker compose -f deploy/docker-compose.sandbox.yml --env-file deploy/.env up -d

Details: DEPLOY-DROPLET.md in the platform repository.

Point your IDE at your install

STUDIO_URL=https://<your-host>/console npx @closurenetwork/ide init

Then Connect (or --stdio + API key) as in the Quickstart. Only the base URL changes — tools stay platform_*.

What self-hosting is not

Not a second product model — Experiences still live on your Closure graph
Not a substitute for Dev → Test → Prod promote (that’s product collaboration, not infra)
Not required for IDE craft — SaaS is the default path