DOCS

Dovre

A cockpit over your GitHub repositories, deploys, apps and coding agents. It shows what needs you and lets you act without switching tools. It runs on your laptop at 127.0.0.1:4848, or on Cloudflare Workers behind Cloudflare Access.

To look around first, open the live demo: hosted Dovre with made-up repos, people and agents, read-only.

Quick start

The fastest way is the setup builder: pick your packs, then run the script or give the skill to your coding agent. By hand:

macOS and Linux

git clone https://github.com/bergaaberg/dovre.git && cd dovre
pnpm install
pnpm dev            # http://127.0.0.1:4848

Windows

git clone https://github.com/bergaaberg/dovre; cd dovre
pnpm install
pwsh scripts/install.ps1   # optional, needs Go: launcher, Ctrl+Alt+D, start at login
dovre                      # or pnpm dev without the launcher

The first page you see is Setup. It finds your GitHub user and orgs, checks which agent CLIs are installed, and says how to turn on the rest.

What you need

Node 24 and pnpm (corepack enable).
The GitHub CLI, signed in (gh auth login). Dovre reads GitHub as you, with gh auth token.
Go, optional: builds the launcher and supervisor, which restarts the server if it crashes. Without it, use pnpm start.
Any of the agent CLIs you use: claude, codex, agy, omp, copilot. Each one missing only switches off what needs it.

Hosted on Cloudflare

Hosted Dovre runs on Workers, D1 and a Durable Object, behind Cloudflare Access. It can't run agents itself, so pnpm bridge on your laptop dials out to it and runs them there. Nothing on the laptop listens for connections.

# 1. A separate instance repo beside dovre: your packs, worker.ts and wrangler config
pnpm instance new ../my-dovre --domain dovre.example.com

# 2. Signs in to Cloudflare, creates D1, applies migrations, sets secrets, deploys
pnpm instance provision ../my-dovre --deploy

# 3. On the laptop: run agents for the hosted Dovre (scripts/install-bridge.sh starts it at login)
pnpm bridge

The bridge needs BRIDGE_URL, BRIDGE_KEY (the same as the Worker's secret) and a Cloudflare Access service token (BRIDGE_CLIENT_ID, BRIDGE_CLIENT_SECRET) in the laptop's .dev.vars.

Packs

Everything Dovre does beyond the core is a pack. Core ships five, and any of them can be switched off with PACK_<ID>=off:

Pack	What it does
`agents`	Sessions from every agent CLI, live turns, worktrees, and the approval bar for tool calls.
`assistant`	Bino, the assistant, with memory from memlet; and the Repo Atlas.
`avatar`	A small companion that reflects what's going on.
`terminal`	Web terminals for your checkouts. Local only.
`docker`	Containers, compose projects and live logs.

Your own packs live in an instance repo, never in core. Add a ready-made one from dovre-packs (cf-health, http-otel, docker, jira, custom-app), or start a new one:

pnpm packs list
pnpm packs add cf-health --into ../my-dovre
pnpm packs new my-app --into ../my-dovre

A pack is a manifest plus the hooks it answers: today, routes, slots, needs, bino, acts, dock, scheduled, email. A pack that fails shows as failed and the page still draws. The contract is src/packs/types.ts; ARCHITECTURE.md walks through it. Coding agents can write one with the dovre-pack-builder skill.

Repo Atlas

A range.yaml in a checkout under CODE_DIR describes its components, which files each owns, and their rules. Atlas lists them, and picking a component when you start an agent keeps the agent to those files and loads their rules.

name: Quill
description: Publishing platform and worker queue
tier: active
components:
  - name: web
    owns: [src/web/, src/ui/]
    rules: .claude/rules/web.md
docs:
  architecture: ARCHITECTURE.md

Settings

Set them on the Settings page, or in .dev.vars (never committed), which wins. The ones you're most likely to need:

Key	What	Default
`REPO_HOST`	`github.com` or your GitHub Enterprise host	`github.com`
`REPO_OWNERS`	Users and orgs to follow, comma-separated	found on Setup
`CODE_DIR`	The folder your checkouts are in	`~/src` or `~/Code`
`AGENT_HARNESSES`	Agent CLIs to use: `claude,codex,agy,omp,copilot`	every one found
`ASSISTANT_VIA`	Bino's model route: `api-key`, `cf-gateway`, `openrouter`, an agent CLI, or `off`	best CLI found
`ASSISTANT_API_KEY`	Anthropic, OpenAI or Gemini key for `api-key`
`OPENROUTER_API_KEY`	Key for `openrouter`
`CF_ACCOUNT_ID`, `AI_GATEWAY`, `CF_AIG_TOKEN`	Cloudflare AI Gateway for `cf-gateway`
`PACKS`	Instance folders whose packs to load, comma-separated	none
`PACK_<ID>`	`off` switches one pack off	on
`GHE_TOKEN`	A GitHub token, if not the one from `gh`	`gh auth token`
`PORT`	Local port	`4848`

The README has the full list, including the hosted ones.

Security model

Local: the server listens on 127.0.0.1 only. Every request needs the launch-token cookie and a localhost host; anything else gets a 404. Forms are accepted only from Dovre's own origin.
Hosted: every request carries a Cloudflare Access token, which Dovre checks itself, and optionally an allowed email list.
Terminals start only programs from a fixed list, only in a checkout under CODE_DIR. Their output stays in memory, never on disk or in logs.
Writes to GitHub or an app check the current state first, take two clicks, and go to an actions log. Repos outside your REPO_OWNERS are refused.
Agents never get wider permissions from Dovre: an allow is the narrowest rule for the call that was denied.
Secrets stay where they are: the GitHub token comes from gh, the rest from .dev.vars or Worker secrets.

Found a problem? Please open a security advisory rather than a public issue.

demo.dovre.dev: the live demo (made-up data, read-only)
bergaaberg/dovre: the core (MIT)
bergaaberg/dovre-packs: ready-made packs
bergaaberg/memlet: the assistant's memory
Architecture and Lexicon
Issues