Self-hosting overview

Self-hosting docs are for operators. They cover the infrastructure, secrets, deployment choices, and maintenance work that fully managed ctx| normally handles for you. Product workflows stay in the primary docs; this section explains what must exist underneath those workflows.

Fully managed vs self-hosted

Fully managed ctx| manages hosting, connector credentials, install links, model provider defaults, and production operations. In a self-hosted deployment, your team owns those responsibilities.

Fully managed vs self-hosted responsibilities

Use this table to decide who owns each part of the system. Fully managed ctx| is the managed path. Self-hosting means you run the same product capabilities on your own infrastructure, with your own production controls.

Area	Fully managed	Self-hosted
Application hosting	Managed service	You run backend, UI, worker, and codesearch
Public origin	Managed	You configure DNS, TLS, proxying, and callback URLs
Database	Managed	You provide Postgres 17 and run/monitor migrations
Graph database	Managed	You provide FalkorDB or another supported graph database
GitHub connector	Managed app flow	You provide or store GitHub App credentials per connection
Confluence connector	Managed Atlassian OAuth and Forge install link	You configure Atlassian 3LO, Forge install/provisioning, and callbacks
Model provider	Hosted defaults	You configure OpenRouter, Azure, Bedrock, or an OpenAI-compatible provider
Secrets	Managed	You rotate and protect auth, connector, model, and encryption secrets
Logs and traces	Managed	You collect stdout logs or configure OpenTelemetry exporters
Backups and restore	Managed	You back up Postgres, graph data, and persistent service volumes
Upgrades	Managed	You plan, test, migrate, and roll back deployments

Deployment tiers

This follows the same shape as mature self-hosting docs: start with a managed cloud option, keep Docker Compose positioned for evaluation or small deployments, and make production readiness a separate operational concern.

Tier	Use when	Shape
Fully managed	You want the product operated for you	Managed cloud
Local evaluation	You want to test with your own repositories	Docker Compose `deploy` profile on one machine
Small team	You need a persistent internal deployment	One backend, one UI, one worker, one codesearch service, managed Postgres if available, FalkorDB or equivalent graph database
Production	Multiple teams rely on agent context	Public HTTPS origin, managed database backups, monitored workers, log/trace collection, secrets rotation, and tested upgrade/rollback process

Start small, operate deliberately

The reference Compose stack is useful for evaluation and small deployments. Production operators should externalize stateful services where appropriate, add backup/restore procedures, and monitor the worker, codesearch, Postgres, and graph database separately.

What runs

A self-hosted deployment includes:

Component	Role
`backend`	Hono API, auth, REST routes, MCP endpoint, connector callbacks, UI proxy
`ui`	TanStack Start web app, served through the backend public origin
`worker`	OpenWorkflow jobs for ingestion, connectors, and provisioning work
`codesearch`	Zoekt-backed clone/index service used by repository search and ingestion
`postgres`	Application database, auth/session state, connections, repositories, workflow state
`graph database`	Claims and relationships used by the knowledge graph and agent context
`otel-collector`	Optional collector for traces, logs, and metrics fan-out