Assets, libraries and people
Libraries, collections, tags, ratings, reactions, users, groups and roles — with the person model that face clustering fills in as it goes.
The entity modelMetaLoom // Loom
The server that
remembers everything.
Loom is the media asset server at the heart of MetaLoom. It holds the files — or just points at where they already live — keeps everything the engine discovers about them, and hands it all back over a REST, GraphQL, gRPC or MCP interface.
Apache 2.0 · 1.0.0 in development, nothing tagged as a release yet
- License
- Apache 2.0
- Interfaces
- REST · GraphQL · gRPC · MCP
- Built on
- Java 25 · Vert.x 5 · PostgreSQL
- Runs on
- One container, or Kubernetes
What it is
One system of record
for the whole archive.
Loom owns the library: the assets, the people, the tags, the permissions, the pipelines and every result a processing node has ever produced. Cortex does the analysis and Graph answers questions about how things relate — but what is true about a file is true because Loom says so.
- Files stay where they are Reference a directory in place or upload into managed storage — on disk or an S3-compatible bucket, chosen per library.
- Results land on the asset Transcripts, detections, embeddings, captions, hashes and thumbnails are written back against the file they describe, with a ledger of which node produced them.
- It dispatches the work The pipeline graph lives here. Loom pushes one task at a time to whichever Cortex worker is allowed to run that node kind.
- Nothing leaves the building There is no phone-home and no metering. A Loom install works with no route to the internet at all.
Open source · Apache 2.0 · runs on your hardware
Loom
Asset server
API · storage · search · UI
You are here — this page
Cortex
Processing engine
45 node kinds · GPU-friendly
Graph
Graph database
Native code · openCypher
Ways to run it
Self-hosted
Free, unmetered, air-gap capable
Studio
Commercial edition · support
Cloud
Hosted by us · in planning
Loom is the only component the outside world talks to. Everything else registers with it.
What it does
An asset manager, not a file browser.
The parts that make an archive searchable rather than merely stored.
Search and vector indices
Full-text search and nearest-neighbour search over embeddings, backed by Elasticsearch, Lucene or Qdrant, with tooling to inspect, reindex and resync each one.
Search indicesChat and the AI agent
A conversational assistant over your own library — sessions, skills, memory, and an optional sandbox where it can write and run code against what it finds.
Chat & AI agentPipelines and dispatch
Author a graph in the editor, run it against a library, and watch each node's result come back — including breakpoints and a debugger for a run that went wrong.
Pipeline mechanismBinary storage
Disk or S3-compatible object storage per library, content-addressed, with a report of how much space each kind of content is using and how full each backend is.
Binary storageAuthentication and permissions
JWT bearer tokens, optional OAuth2, API keys, and per-entity permissions expressed as roles and groups rather than as a flag on a user.
Authentication
Ways in
Six front doors to the same library.
Every one of them is generated from the same model, so nothing is a second-class interface.
- REST API
- Full CRUD over every entity, with a published OpenAPI document and an explorer you can drive from the docs page.
- GraphQL API
- Nested queries over the asset model when one round trip should answer a whole screen. The schema and a GraphiQL explorer ship with the docs.
- gRPC API
- Binary RPC over HTTP/2 on its own port, for integrations that want a generated client.
- MCP server
- Connect Claude Desktop, an IDE or your own agent to the library over the Model Context Protocol.
- Java & Python clients
- Typed clients for both, kept in step with the REST surface by a parity test rather than by hand.
- Web UI, desktop and CLI
- The same server, driven from a browser, a desktop build or a shell — including the pipeline editor and the debugger.
Where to next
Run it, then wire it up.
Getting Started
From a container and a database to a first library with a pipeline running against it.
Start hereREST API reference
Every endpoint, its payloads and an explorer, generated from the server itself.
Open the referenceConfiguration
The YAML file and every environment variable, including storage, search and the agent.
Configure Loom
Loom
It runs today.
1.0.0 is not tagged and the interfaces can still move, but the demo container starts, seeds a library and gives you a UI to look at it with. That is the fastest way to find out whether this is what you want.
MetaLoom is Apache 2.0 and stays that way. The commercial edition adds identity, storage and support around it — it takes nothing out.