Self-hosting

Garboard is built to run inside your boundary: one Go binary plus Postgres 16 with the pgvector extension. No orchestration framework, no queue, no service mesh — a deliberate monolith. Single-tenant and self-hosted installs are part of the Enterprise plan; this page is what an evaluation needs to know.

How to get it

Garboard is distributed to design partners. There is no public download and no public container image; partners are given a registry path, pull credentials and signed release binaries with their checksums. If you want to evaluate a self-hosted install, email us — that is the whole acquisition path today, and we would rather say so than publish an install a stranger cannot perform.

The shape of an install

One binary, several entrypoints: garboard serve (the API server and GitHub App webhook), garboard scan (CLI — parses a repo into facts and conventions, fully offline), garboard gate (the same deterministic checks as a CI step), and garboard mcp (the MCP server). All of them are the same gate — generated fixes pass through the identical checks external PRs get.

Database schema is managed by the binary itself: versioned, advisory-locked migrations run at startup, so an upgrade is "replace binary, restart" and is safe with concurrent instances. A Helm chart ships the same shape for Kubernetes installs — one chart, the binary plus Postgres, every credential passed by reference rather than as a plain value.

Postgres needs pgvector, and will not tell you loudly if it is missing

Episodic memory — the recall that lets a review cite what this repo did before — stores embeddings in a vector column. At startup Garboard runs CREATE EXTENSION IF NOT EXISTS vector. If that fails, the server still starts: it logs store: episodic memory disabled (pgvector unavailable), sets its episodic-memory gauge to false, and serves every other feature normally. Point a stock managed Postgres at it without enabling the extension and you get an install that looks healthy and is quietly missing a feature you are paying for.

So: enable pgvector before first boot, and check that log line after it. On AWS RDS and Aurora PostgreSQL the extension is available but must be created; managed providers that do not offer pgvector at all cannot run episodic memory.

Configuration

Everything is environment variables — no config files. The essentials:

GARBOARD_DB_URL                  # Postgres 16 connection string
GARBOARD_BASE_URL                # public URL of this instance
GARBOARD_GITHUB_APP_ID           # your own GitHub App…
GARBOARD_GITHUB_PRIVATE_KEY_FILE # …and its key — code is read via the App,
GARBOARD_WEBHOOK_SECRET          #    never via stored git credentials
GARBOARD_OIDC_ISSUER             # SSO via any OIDC identity provider
GARBOARD_OIDC_CLIENT_ID / _SECRET / _REDIRECT_URL
GARBOARD_SIGNUP_DISABLED         # close self-service signup (invite-only)
GARBOARD_SSO_ALLOWED_DOMAINS     # restrict SSO to your email domains
GARBOARD_SECRET_KEY              # envelope root key — REQUIRED for per-org SSO

GARBOARD_SECRET_KEY is load-bearing, not optional. It is the root key every per-org secret is sealed against. Without it an org admin cannot save an identity provider at all — there is nothing to encrypt the IdP client secret with — so per-org SSO is unavailable on an instance that does not set it. Set it before you invite anyone; rotating it later means re-entering every sealed secret.

AI features (Fix, Forge) take an Anthropic API key; without one, the deterministic gate — parsing, conventions, findings, merge checks — runs at full capability. garboard scan succeeds with no key and no network.

What it will never need

No cloud credentials. There is no code path that runs terraform apply or performs any cloud write — that's a structural invariant enforced by tests, not a policy toggle. Everything Garboard produces is a commit or a PR a human merges. Your infrastructure remains changed only by your existing pipeline.

Evaluating?

We set self-hosted evaluations up together with written success criteria and an end date.

prefer email? hello@winchlabs.io