Installation and startup

Notarium ships as a single self-contained image: one process serves the web interface, the REST API, and the MCP endpoint for agents, while the knowledge engine runs right inside it. No external services — no database, no message broker, no separate search engine — are required. All you need to get started is Docker and a free port.

This page is the fast path: spin up an instance, open it in a browser, and create the owner. Detailed self-hosting (Postgres, reverse proxy, production configuration) lives in the Self-host section.

What you'll need

• Docker (or Docker Desktop) — nothing else to install: Node, the database, and the search index are already inside the image.
• A free port — 3000 by default.
• A bit of disk space for your notes and the derived index.

Running a single container

The shortest path is to run the prebuilt docouno/notarium image:

docker run -d --name notarium \
  -p 3000:3000 \
  -v notarium-data:/data \
  docouno/notarium:latest

After a couple of seconds, open http://localhost:3000.

A single /data volume holds all state — the metadata database, the indexes, your notes, and export artifacts. There's nothing else to configure: port 3000 and the /data path are already baked into the image. You can change the port on the left of 3000 to any free one.

An alternative is to build from source via make, the single entry point for everything Docker-related:

cp .env.example .env   # the defaults work — nothing to fill in
make up                # build the prod image and bring it up → http://localhost:3000

Other commands come in handy for day-to-day use: make logs for logs, make ps for status, make down to stop and remove, make sh for a shell inside the container.

Volumes: where the data lives

All state lives in a single volume — that's what you need to preserve when recreating the container:

The key principle is file-first: the source of truth is the .md files in /data/spaces. The search indexes and the graph in /data/engine are derived: they're rebuilt from the files, so if you lose them, a reindex brings them back. The metadata database /data/meta.db — version history, users, and access — lives only in the volume, so /data deserves the same care as your notes. For backups, you only need your notes and meta.db; the derived indexes can be left out.

First run: the setup screen

On your first visit, Notarium greets you with a setup screen. There's no preset password: the first visitor creates the instance owner — that account becomes the administrator and the owner of the spaces it creates. After that, setup closes for good, and you land in the editor, already inside your personal space.

That's how the default authentication mode — AUTH_MODE=password — works. It's designed for a publicly reachable instance: login, sessions, personal tokens for agents. The second mode, none (a single all-access principal, no login screen), fits only a trusted environment: a desktop, local development, or a closed intranet. Details are in the Authentication section.

Basic configuration

The defaults are zero-config: the image as-is is enough to get started. Fine-tuning happens through environment variables (in Docker, .env passes them through; nothing is baked into the image):

Full-text search always works, with no configuration. Semantic (vector) search is opt-in via the VECTOR_SEARCH=on flag: it pulls in a local embeddings model (on the order of hundreds of megabytes of RAM), so it's off in the published image and has to be turned on deliberately. Without it, search still works over the full text — no error; that's the normal mode. The full list of variables and search setup are in the Configuration and Search setup sections.

Next steps

The instance is up and the owner is created — time to fill your knowledge base and open it to an agent:

• Your first note — the file tree, the web editor, and saving to .md.
• Connect an agent — the token, the POST /mcp endpoint, and the first call.

Want to understand the whole model? Check out the Concepts section: spaces, note types, the graph, and the access model.