First run
Your first hour with Disco
What you see after the stack is up and a model is connected.
Pairing
Open http://localhost:8088 on the same machine and the browser pairs itself: the ports are bound to loopback and unreachable from anywhere else. If it asks for a token, you are opening the UI from another machine or cleared the cookie; print it with
podman compose exec app-server python -m disco.app_server.pairing_cli
It is derived from the install’s secret, so it prints the same token every time. Exposing the UI to a LAN or the internet is a deliberate step (DISCO_BIND, DISCO_PUBLIC_UI_URL); the reference covers the remote-preview cookie boundary.
Build components and Docker Compose exports · Benchmark source files
The four surfaces
| Surface | What it does |
|---|---|
| Search | One grounded answer. Claims are tethered to extracted passages and a verification pass marks the unsupported ones instead of hiding them. |
| Deep Research | A multi-source report: plan, adaptive search and read, evidence-led outline, cited synthesis and claim verification. Export as Markdown or PDF; make a slide deck or an audio overview from it. |
| Build | A coding agent in a sandbox: shell sessions, dev-server preview, browser automation, a persistent Python kernel, plan and risk-gated execution, workspace versions and rollback. |
| Agent | The same machinery as Build, framed as a general task agent. Extend it with MCP servers. |
What is live in each, and the known limits.
Build: how it works
Every Build starts with a plan you approve. The agent then works in an isolated sandbox container, runs its own checks, and hands you a live preview. Each shell check it runs is recorded against the source it ran on; a repeat on unchanged source is answered from the record instead of re-executed, an edit tells the agent which checks it staled, and finish re-runs the stale ones. The run’s Checks section shows the state of each. You can download the workspace at any point, roll back to an earlier version, or steer with a message mid-run.
Reference packs
A reference pack is a reusable collection of your own files: a brand kit, a spec, a data sample. Create one from an Agent task (“make a reference pack called Brand kit from these files”), manage it under Settings → Extensions & Storage → Reference packs, and select packs in the Build options row under References. Selected packs are copied into the build before the first model call, so later edits to the library never change a running build. Packs are inert data: text inside them is reference material, never an instruction.
MCP servers
Add servers under Settings → MCP. Each passes two approvals (origin, then tool schema) before any tool is callable. Remote servers must be reachable from the agent-server container (see the host-address table). Local stdio servers run inside the agent-server container; approving one lets npx download and execute a package there, so pin versions and prefer a remote server when one exists.
Where your data lives
Everything is in the disco-data volume: the event log (disco.db), settings and encrypted secrets, projects, reference packs, skills. Back it up with the script in the reference; restore is the same script in reverse. Set DISCO_SECRET_KEY in .env so encrypted settings survive a restart; the doctor warns when it is not set.
Reference: docs/self-host.md in the repository is the complete, versioned version of this guide. When the two disagree, the repository is right.