Moorhold Data
One governed workspace over the tools you already trust
Moorhold is an integration layer. It never forks, proxies or rebuilds a tool. It signs people in, wires the tools together through their own interfaces, keeps them in the state you declared, and records every change.
Identity
One login
People sign in once, through Keycloak, and reach every tool in the stack. There is no second password for the dashboards or the catalogue.
- Groups are defined once and projected into each tool's own roles.
- Each tool keeps its native permissions. Moorhold does not invent a new permission model on top.
- A launchpad shows each tool, whether it is healthy, and opens it in its own interface.
Why not one permission model?
Every tool already has its own idea of who may do what. Replacing that would mean rebuilding the tools. Moorhold keeps the tools' own rules and shows you where they differ.
Provisioning
Declarative sources
Declare a data source once, as plain configuration. Moorhold creates what each tool needs, and removes it again when the source goes.
- Adding a source creates the query-engine catalog, the scheduler connection, the dashboard database and the catalogue ingestion in one step.
- Before anything changes you see the plan, tool by tool.
- A reconciler compares what you declared with what is really there, and repairs drift.
- Sources can be databases or awkward REST APIs with tokens, paging and rate limits, loaded with dlt.
# sources/grants.yaml (fictional example)
kind: Source
name: grants
connection:
type: postgres
host: db.example.test
database: grants
user: grants_reader
password: vault://data/grants#password
access:
groups: [analysts, data-engineers]AI agents
Agents propose, people approve
AI agents are users of the workspace, not a back door into it. An agent always acts for a named person, with that person's permissions and no more.
- Agents connect through the Model Context Protocol (MCP), to each tool's own server where one exists.
- Changes from agents are proposals. A person in the admin group approves them, and never the person who asked.
- Tools that write are off by default.
- Secrets are references only. A literal secret in a proposal is rejected.
- Moorhold does not ship a model or an assistant. You bring your own agent and your own model endpoint.
A proposal has a lifecycle
Awaiting approval then Approved then Applied.
A proposal can also be rejected or withdrawn. Once applied, it is ordinary desired state: planned, applied, repaired if it drifts, and torn down when removed.
Metadata
Lineage and audit
Pipelines, tables and dashboards are connected in DataHub without anyone drawing the lines by hand. The tools report what they read and wrote, using the OpenLineage standard.
- Lineage comes from the tools themselves: the scheduler, the data models and the query engine.
- The audit log brings together the portal's own actions, sign-in and token events, and the query engine's record of what was read.
- Every agent action is attributed to the person it acted for.
- Retention is configurable.
| When | Who | What |
|---|---|---|
| 09:12 | claude-code for carol | Proposed add-source-grants |
| 09:40 | alice | Approved add-source-grants |
| 09:41 | Moorhold | Applied 4 changes across 4 tools |
| 11:05 | claude-code for bob | Read grants.public.awards through Trino |
No lock-in
Removable
You should be able to stop using Moorhold and keep everything it set up.
- Export all of the portal's state as plain, declarative configuration.
- Remove Moorhold and the stack keeps working: the tools are unmodified and configured through their own interfaces.
- Components are swappable. Each one meets a small set of contracts: sign-in, lineage, data, provisioning and agents.
Why build it this way?
A product that holds your platform hostage is a risk, however good it is. Being removable is a design rule, and it is tested.
Sovereignty
Runs on infrastructure you own
Everything runs on servers you control: a single virtual machine to start with.
- Bring your own vault. Secrets stay in the store you already use, such as HashiCorp Vault or Infisical, and Moorhold keeps references, not values.
- Values are read at the moment of use, in memory, and never written to logs, errors or files.
- Each tool has its own service account. No shared credentials.
- The default stack is built from permissively licensed components. Each release is licence-checked.
The first release targets a single virtual machine with Docker Compose. Kubernetes support comes later.
What leaves your network
Nothing needs to. Moorhold runs alongside the tools on your infrastructure. If you connect an AI agent, you choose where its model runs.
The default stack
What Moorhold runs
Moorhold is proprietary software. The tools below are open source and stay that way: you can use them without Moorhold.
| Tool | What it does | Licence |
|---|---|---|
| Keycloak | Sign-in (OpenID Connect) | Apache-2.0 (Keycloak licence) |
| Trino | Query engine | Apache-2.0 (Trino licence) |
| Apache Airflow | Scheduling and pipelines | Apache-2.0 (Apache Airflow licence) |
| Apache Superset | Dashboards and charts | Apache-2.0 (Apache Superset licence) |
| DataHub | Catalogue and lineage | Apache-2.0 (DataHub licence) |
| PostgreSQL | Database | PostgreSQL Licence (PostgreSQL licence) |
| dlt | Loading data from APIs and databases | Apache-2.0 (dlt licence) |
| dbt Core | Data models (SQL transformations) | Apache-2.0 (dbt Core licence) |
Licences checked by Allotment Technology, 28 September to 3 October 2026. Licences can change; each release is checked again before it is supported.
Status, October 2026
What is built, and what is not
Moorhold is in its first build phase. The features on this page are designed and partly built. Parts of them have been tested against a local copy of the stack. None has yet run in a customer's environment.
It is not yet available to buy. If you would like to be told when it is, or to help test it, get in touch.
Talk to us
Moorhold is in development. If your organisation runs, or wants to run, its own data stack, we would like to hear what you need.