How Keel works

Keel is one platform with a shared core and licensed modules — see Platform and modules. It is built as a modular monolith: one API host with ten modules, separate hosts for background work, scheduling, MCP and the SQL interface, a private agent that can run inside your network, one PostgreSQL metadata database and Redis. Modules talk only through contracts and events, so any of them can be extracted later.

Module	Part of	What it does
Identity	Core	Tenants, workspaces, roles, API keys, sign-in, feature flags and module licences, notifications
Sources	Core	Connections, secrets, Test connection, private agents
Discovery	Core	Scans: harvesting, profiling, proposals with evidence, review, drift
Governance	Core	Glossary, ownership, access policies, certification, lineage
Quality	Core	Data-quality rules, runs, incidents, trust scores
Audit	Core	Hash-chained audit log, verification, retention, export
Modeling	Keel Semantic	Versioned semantic models, generation, strategy, change requests, releases, exports, imports
Serving	Keel Semantic	Serving endpoints, semantic queries, MCP and assistant tools, SQL interface queries
Migrate	Keel Migrate (licensed)	Migration projects, mappings, plans, code generation, reconciliation, runs, cutover
Leads	Platform-level	Demo requests from the marketing site (no tenant)

   Marketing site (site/)    Web app (React SPA)       AI agents (MCP)    BI tools, apps       SQL clients, BI
        │ demo requests            │ REST + SSE               │               │ REST                 │ PG wire
┌───────┴──────────────────────────┴───── Keel.Api ───────────┴───────────────┴────────────┐   ┌─────┴─────────────┐
│ Core:     Identity · Sources · Discovery · Governance · Quality · Audit                  │   │ Keel.SqlGateway   │
│ Semantic: Modeling · Serving     Migrate (licensed)     Leads (platform-level)           │   │ :5433 (v1.1 beta) │
└──────────▲──────────────────────────▲───────────────────────┬───────────────────▲────────┘   └───────────────────┘
           │ outbox → job queue       │                       │                   │ outbound HTTPS
   ┌───────┴─────────┐        ┌───────┴─────────┐      ┌──────┴──────┐            │
   │ Keel.Worker     │        │ Keel.Scheduler  │      │ Keel.Mcp    │            │
   │ scans, DQ, AI   │        │ drift, DQ, health      │ /mcp/{slug} │            │
   └───────┬─────────┘        └─────────────────┘      └─────────────┘            │
           │ read-only connectors                                                 │
           │                ┌────────────────────── inside your network ──────────┴────────────┐
           │                │ Private agent (Keel.Worker in agent mode)                        │
           │                │   read plane: scans, DQ, queries (read-only credentials)         │
           │                │   Migrate write plane: bulk load + CDC, source → target,         │
           │                │   separate scope-checked write credential, approved plan         │
           │                └────────────────┬─────────────────────────────────────────────────┘
           │                                 │
   ┌───────┴─────────────────────────────────┴─────────────────────────────────────────────────┐
   │ Your databases: PostgreSQL · SQL Server · MySQL · Oracle · Redshift · Snowflake ·         │
   │ BigQuery · Databricks (sources, and Migrate targets)                                      │
   └───────────────────────────────────────────────────────────────────────────────────────────┘
   Keel's own state: PostgreSQL 17 + pgvector (metadata) · Redis · LLM (optional)

The pipeline (Keel Semantic)

Connect ─► Harvest ─► Profile ─► Relationships ─► Classify ─► Generate model ─► Strategy
                                     │                │              │
                                     ▼                ▼              ▼
                               Review queue (people accept, reject, edit)
                                                                    │
                    Change request ─► checks ─► approve ─► merge ─► Release
                                                                    │
                  Serving API · MCP · Assistant · Exports · Lineage · Trust scores

Long work runs as jobs in a PostgreSQL SKIP LOCKED queue (no separate broker). Changes publish integration events through a transactional outbox, so "scan completed → generate the model → recompute the strategy → suggest rules → rebuild lineage" happens reliably and exactly once per consumer.

Principles you will see everywhere

• Read-only, minimal access. Connectors open read-only sessions with statement timeouts; profiling is bounded; values of sensitive columns are never read, stored or sent to an LLM. See Security model. The one exception is the licensed Migrate write plane: only the private agent writes, with a separate scope-checked credential, for an approved plan. See Platform and modules.
• Proposals, not facts. Anything inferred carries origin, confidence and evidence and waits for a person (or an explicit auto-accept policy). See Proposals, evidence and trust.
• A model is a versioned document. Branches, revisions, object-level diffs, change requests and releases. See Versioning.
• Governance travels with the metric. Owners, glossary terms, certification, trust scores and access policies are applied when the metric is served — through the API, MCP and the assistant alike. See Policies.
• Tenant isolation in depth. Every tenant row is guarded by EF query filters and PostgreSQL row-level security; the runtime database role cannot bypass it.
• Everything is audited. Changes to governed objects land in a per-tenant, hash-chained, append-only audit log that is verified nightly.

Read on: The semantic model.