Self-hosting

Overview

What the self-hosted stack is made of, what runs where, and what leaves the machine.

Self-hosting means you run the Chronicler server. It is a Docker stack of four containers, started with one command, on one machine.

What runs

              ┌──────────────────────────────────────────────┐
   Chronicler │  backend        FastAPI, port 8410           │
   app on any │    ├── postgres  documents + search index    │
   PC on the  │    └── ollama    writes the answers          │
   network ──►│  (+ ollama-pull, a one-shot model download)  │
              └──────────────────────────────────────────────┘
                          one Docker stack, one machine

Container	What it does	Port
`chronicler-backend`	The API the app talks to. Extracts text, runs OCR, builds the search index, answers requests.	`8410`
`chronicler-postgres`	Stores documents, accounts and the search index. There is no separate search database.	`5432`
`chronicler-ollama`	Runs the language model that writes answers, on your CPU or GPU.	`11434`
`chronicler-ollama-pull`	Runs once at startup to download the model, then exits. Seeing it "exited" is normal.	—

Your documents live in a Docker volume (backend_uploads), the database in postgres_data, and the downloaded models in ollama_data. Those three volumes are the install. Everything else can be thrown away and recreated.

What leaves the machine

Nothing about your documents. Text extraction, OCR, indexing and answer generation all happen in the containers above.

The server does make two kinds of outbound connection:

Licence checks to api.chroniclerlm.com, every 30 minutes. It sends the licence key and an install identifier — no document content. See Licensing.
Downloads from Docker Hub and GitHub, when you install or update.

There is no telemetry beyond that.

What you can and can't configure

Most of the server's behaviour is fixed in the image on purpose — that's what makes a self-hosted install predictable, and what keeps the security-relevant settings out of reach of an accidental edit.

From the admin console: the generation model, where embedding runs, disk allocation, backup schedule, licence key, update checks, users.
From the .env file next to the compose file: the database password, GPU profile, ports, image versions, memory and performance knobs.
Not configurable: the realm (this server is always a single organisation), sign-up policy (always admin-provisioned), licence enforcement, the embedding model, and the internal service URLs.

Full list: Configuration reference.

Two ways to install

Guided

The desktop app writes the compose file, generates a database password and detects your GPU. Best on a normal PC.

Manual

Download the compose file, write the .env yourself, docker compose up -d. Required for a headless server.

Before either, check Requirements.

Edit this page

Managing users

Roles, adding accounts, access requests and the audit log.

Backups and restore

Scheduled backups, an offsite copy, and how to get your data back.