Playbooks are task-oriented guides. Where the reference pages describe one component at a time — a node, an endpoint, a config key — a playbook walks a whole job end to end: what you are building, the commands and manifests in order, and how to check that it actually worked.
Each playbook is self-contained. Start at the top, run the steps, and finish with the verification section. Where a step depends on behaviour documented elsewhere, it links to the reference page rather than repeating it.
Deploying with Docker
A production-shaped stack on a single host: PostgreSQL, the Loom server and one or more Cortex workers, wired with the volumes and the worker token they need to survive a restart.
Deploying on Kubernetes
The same stack in-cluster: service accounts, the RBAC the chat's coding sandbox needs to spawn runner Pods, the guardrails that keep those Pods contained, and how to package it all as a Helm chart.
Transcribing for the Chat Agent
Turn a library of video and audio into transcripts the AI agent can search, so questions like "what did they say about the launch date?" have something to answer from.
Scene-Level Video Analysis
Cut a video into scenes, then describe each one — from the soundtrack with Whisper, from the picture with a vision model, or both.
A Custom Node in Python
Run your own processing logic inside a pipeline without touching the JVM build: a single-file worker that advertises its node kind and answers the tasks Loom dispatches.
Translating Content
Get source text out of speech, documents and images, translate it, and — optionally — speak the translation back onto the asset as narration audio.
Before You Start
Every playbook assumes you can reach a Loom server and log in. If you have not run MetaLoom before, start with Getting Started — the demo image gets you a working system in one command — and come back here when you want to build the real thing.
The deployment playbooks assume familiarity with the container images and their ports. The pipeline playbooks assume you have read Pipeline Mechanism: Loom owns the graph and dispatches one node task at a time to a registered Cortex worker, which is why "which worker can run this node kind" appears in every one of them.
Which Node Kinds a Worker Can Actually Run
The pipeline playbooks assume the node kinds they use are dispatchable, and that deserves a precise
statement because it is the difference between a pipeline that runs and one that is rejected with
503.
A Cortex worker announces, at registration, the node kinds its pipeline node factory has producers for. Loom dispatches a task only to a worker that accepts its kind. Being present in the worker’s Dagger node collection is not enough — the kind has to be registered with the factory as well.
As of this revision the stock metaloom/cortex-server image registers:
filesystem-source · asset-source · md5 · sha256 · sha512 · chunk-hash · thumbnail · vlm · ttsThe other built-in nodes — whisper, llm, ocr, tika, facedetect, facedescription,
captioning, scene-detection, quality, consistency, the dedup kinds, loom and the filter-*
kinds — exist, are covered by tests, and are wired into the worker’s node collection, but are not yet
registered with the pipeline node factory, so Loom will not route work to them. The registered set is
growing; vlm and tts were the most recent additions.
Until a kind you need appears in that list you have two ways round it. The one that needs no JVM
build at all is to run the work in your own worker, which advertises its kinds on the wire —
A Custom Node in Python walks through it end to end. Otherwise register the kind
with the JVM worker’s pipeline node factory (a single line in
cortex/cli/…/dagger/PipelineNodeFactoryModule.java) and rebuild the cortex-server image. Check
the live answer for your deployment with:
curl -s -H "Authorization: Bearer $TOKEN" $LOOM/api/v1/processors | jq '.[] | {nodeId, nodeWhitelist}'The graphs in the playbooks are written against the node model as designed, so they stay correct as the registered set fills in.
Conventions Used Here
| Convention | Meaning |
|---|---|
|
Base URL of the Loom server, e.g. |
|
A JWT from |
Pipeline JSON |
Shown in the shape Loom’s graph parser executes — |
Node kinds |
Written as they appear in a definition’s |