Documentation for the vmctl born-digital-art conservation platform, and the source for docs.vmctl.org. Developed at ZKM | Center for Art and Media Karlsruhe.
vmctl is a toolkit for keeping born-digital artworks alive: tear a work apart to find out what it is, rebuild the machine it needs, and run it again. It was built at ZKM | Center for Art and Media Karlsruhe and is released open source.
It has three parts — the three stages a work passes through, from a dead bundle of bytes to a piece running on a gallery wall:
- Autopsy (analysis) — artwork-autopsy. It unpacks an artwork bundle, works out what the work is, what runtime it needs, and — crucially for a broken piece — every network host it reaches (so you know what to restore). An agentic analyst maps the crucial parts and writes a conservation report.
- Research (the workbench) — rvmc, the Research VM Controller. It clones era-correct virtual machines (Windows 98 … 11, classic Mac OS), boots the artwork inside one, captures its network traffic, and lets you fix, verify, and save the running state.
- Exhibition (the locked runner — the north star) — evmctl, the Exhibition VM Controller. The eventual goal is that a work analyzed and verified in the research workbench gets locked into evmctl: a frozen, reproducible, long-running exhibition instance a museum can switch on every morning without touching the research tooling. rvmc is in fact built on top of evmctl's foundation.
The lifecycle, as a north star: bring your artwork → autopsy → rebuild & verify in the research workbench → lock it into evmctl for exhibition.
Where this actually stands (built in steps). Today the working, documented system is parts 1 and 2 — autopsy + the rvmc research workbench. Autopsy is in good shape; rvmc already ships a broad library of era-correct golden images and is being refined on the agentic side (the analyst/agent that drives a VM). Part 3, the automatic hand-off to evmctl, is not built yet — it's the direction, not a current feature. These docs describe what works now and flag what's planned.
For the full technical picture of the whole system — the conservation problem, the architecture, the agentic analysis, and what's built versus planned — read the vmctl whitepaper (rendered: PDF).
- An artist or art historian? → Getting started for artists & historians. Short version: you don't have to set any of this up yourself. ZKM can provide the infrastructure — but the AI that reads your artwork costs money, so you bring your own AI key. See Bring your own AI.
- A conservator or researcher? → Getting started for conservators.
- Want to run it yourself? → Self-host quickstart.
- Bring your artwork — the full lifecycle, step by step.
- The autopsy — what the analysis does and how to read the report.
- Bring your own AI — why, how, which providers, and the security model.
- Working in the VM — save-points, network capture, exhibition staging.
- Install & deploy
- Auth modes — single-user
localvs. multi-tenantforward. - AI configuration — server LLM config, per-group keys, the OWUI boundary.
- Group AI-key runbook — mint a LiteLLM key + set the group's Authentik attribute.
- Dependencies — what you actually need, in tiers.
- Architecture
- Runtime modules — how autopsy learns a new file type, and the per-OS guest agents.
- MCP tools — the agent tool surface.
- Configuration — every environment variable.
Running old software is cheap — a VM is a VM. Reading and understanding an artwork is where the cost lives, because that is done by a large language model, and every serious work means a lot of tokens. So the deal we offer is simple:
We are happy to provide the infrastructure. You bring your own AI.
The whole system is designed around that: you point it at your OpenAI-compatible endpoint and your key, and you pay your provider directly for what your artwork costs to analyze. See Bring your own AI.
vmctl is a project of ZKM | Center for Art and Media Karlsruhe. Head researcher: Marc Schütze (ZKM). It grows out of ZKM's work on running born-digital art, and shares lineage with ZKM's exhibition-vm-controller (evmctl).
Source. The code is open source on GitHub, under the ZKM org —
github.com/zkmkarlsruhe:
artwork-autopsy,
research-vm-controller,
exhibition-vm-controller,
vmctl-core and
wayback-mcp. These docs are served at
docs.vmctl.org.
MIT — a ZKM open-source project.
Copyright (c) 2026 Marc Schütze @ ZKM | Center for Art and Media Karlsruhe.