Platform and modules

Anchor Keel is one platform: a shared core that understands your databases, and licensed modules that put that understanding to work (ADR-0021). Every tenant has the core and Keel Semantic. Keel Migrate is licensed per tenant.

The shared core

Every module builds on the same core:

Capability	What it gives you	Read more
Connectors	PostgreSQL, SQL Server, MySQL, Oracle, Redshift, Snowflake, BigQuery and Databricks, reached directly or through a private agent inside your network	Connectors
Harvesting and profiling	Schemas, keys and statistics from bounded samples; sensitive columns are profiled without values	First scan
Inference	Joins, table roles, semantic types and sensitivity, each a proposal with confidence and evidence	Proposals, evidence and trust
Governance	Glossary and ownership, data quality and trust scores, access policies, certification, lineage, a hash-chained audit log	Policies, Lineage, Data quality
Drift and notifications	Scheduled drift scans; in-app, email, Slack, Teams and signed webhooks	Drift, notifications and webhooks
Platform	Tenants and workspaces, six roles, row-level security per tenant, SSO (OIDC), API keys, the web app	Security model

The modules

Module	What it does	Licence	Touches customer data
Keel Semantic (the launch module)	Proposes a governed semantic model from your schemas. People review it, and Keel versions it like code (branches, change requests, releases). The same metrics go to BI tools, apps and AI agents: the semantic query API, MCP, the SQL interface (beta) and the assistant. Exports and imports: dbt, Cube, LookML, Power BI TMDL and open YAML	Always on	Read-only
Keel Migrate — plan & prove	Proposes a source → target mapping with evidence, generates dbt/SQL from an approved plan, and proves the result with reconciliation and a sign-off	Migrate licence	Read-only
Keel Migrate — run & cut over	The private agent bulk-loads and syncs the target with change data capture inside your network, then a guided cutover switches Keel's serving to the target, with instant rollback	Migrate licence	Writes to the target (and sets up change capture on the source) inside your network only, with a separate write credential

Keel Migrate starts from what the core already knows about both schemas: names, keys, profiles, classifications and glossary terms. The mapping is not a blank spreadsheet. It feeds back into governance too: an approved plan adds lineage edges from source to target columns, and restricted source columns keep their classification and get a proposed mask.

Licensing

• A module is an entitlement of the tenant's subscription: an add-on an Owner buys in Settings › Billing, or one the platform operator grants by contract with the licence command (no HTTP endpoint). See Plans and licences.
• An unlicensed module is invisible, not just disabled: its navigation entry is hidden, its routes answer 404, and its jobs are dead-lettered.
• The web app reads GET /api/v1/tenant/modules to decide what to show.
• Licences are separate from feature flags. Tenant Owners switch feature flags on themselves, such as the SQL interface beta (sql-interface).

Read-only by default, and the write plane

Keel's promise is that it reads your systems and never changes them. The one exception is explicit, licensed and contained. ADR-0021 splits the platform in two:

• Control plane (Keel): everything described in these docs, including discovery, modeling, serving, mapping, code generation and reconciliation. It uses the same read-only connections as always.
• Write plane (your network only): the private agent running a Migrate run. It writes only with the conditions below.

Rule	How it is enforced
Only the private agent writes	Runs are work items addressed to the project's agent; Keel's own hosts never open a write connection to your systems
Only with a separate write credential	The credential is a secret name held by the agent; Keel never sees it. It must differ from every read credential, and it is used only by runs and scope checks, never for discovery or serving
Only inside its scope	The agent checks the credential's rights; a credential that can write outside the target schemas and keel_stage is refused
Only for an approved plan	A run executes an approved plan version; destructive steps (the serving switch) need a Steward or Owner, optionally a second one (four-eyes)
Rows stay in your network	Rows move source → target through the agent. Keel receives counts, timings, lag, checksums and at most 50 business keys, never row values
Everything is audited	Every run step and cutover action is in the audit log with its actor and plan version

Keel also generates the transformation code as open artefacts: dbt projects and SQL scripts. Letting Keel run the migration is optional. You can run the code with your own tools, and Keel then stays read-only and only reconciles.

Around the product

• Marketing site: site/ (F17) is the public website: home, pricing, security, demo request and legal pages.
• Demo requests: the site's form posts to the API's public endpoint (POST /api/public/v1/demo-requests). The requests land in the platform-level Leads module, which belongs to no tenant.

Read on: Keel Migrate: plan and prove.