Scrumboy: a self-hosted Go project board with an MCP layer for agents

What Scrumboy is for, and who it is not for

Scrumboy is a self-hosted project management and issue-tracking server. The README describes it as boards plus cross-project workload and flow analytics, calendar-aware planning, a sticky-note wall, portable imports and backups, realtime email notifications, and an MCP/Agent automation layer. The repository topics list agile, scrum, kanban, self-hosted, docker, sqlite, oidc and mcp-server, which is a fair summary of the intended audience: a small team that wants its own instance rather than a SaaS account.

The design centre is the single process. There is no separate database server to run, no external queue, and no mandatory configuration file. The README states that no .env file, TLS certificate or encryption key is required to start the app, and that runtime data lands under ./data by default. That is the whole selling point: one binary, one directory.

It is the wrong tool if you need a hosted service with an uptime commitment, or if your organisation requires a vendor contract. It is also a poor fit if you expect a guided migration from Jira or Linear; the README documents import modes and export scope, but nothing describes a connector that preserves another tracker's history and field semantics.

How the Go server and SQLite storage fit together

The build produces one static binary. The Dockerfile compiles with CGO_ENABLED=0 and targets GOOS and GOARCH from build arguments, then copies that binary into an Alpine 3.20 image. Because CGO is off, the SQLite driver is the pure-Go modernc.org/sqlite module listed in go.mod rather than a cgo binding. That is why the image can be a single static binary on Alpine and why cross-compilation for linux/amd64 and linux/arm64 needs no emulation of the compiler, as the Dockerfile comments explain.

State lives in SQLite. The image defaults to DATA_DIR=/data and SQLITE_PATH=/data/app.db, and the Dockerfile sets SQLITE_JOURNAL_MODE=WAL and SQLITE_SYNCHRONOUS=FULL. Those two settings are the interesting pair. WAL mode lets readers proceed while a writer works, and SYNCHRONOUS=FULL makes the database fsync on commit. The trade-off is throughput on write-heavy workloads in exchange for durability on an unclean shutdown. SQLITE_BUSY_TIMEOUT_MS=5000 gives a writer five seconds to wait for a lock before failing.

The dependency list shows what the server does on its own: go-oidc and oauth2 for SSO, go-jose and golang-jwt for tokens, pquerna/otp and go-qrcode for TOTP second factors, webpush-go for browser push, golang-ical and rrule-go for calendar-aware planning, and golang.org/x/crypto for password hashing. None of these imply an external service. The only outbound integrations named in the README are SMTP, webhooks and the MCP endpoint.

Installing Scrumboy with Docker and creating your first board

The README's quick start uses the published container image from GitHub Container Registry. This command starts the server on the loopback interface only and keeps the database in a named volume, so the data survives container recreation.

docker run -d \
  --name scrumboy \
  -p 127.0.0.1:8080:8080 \
  -v scrumboy-data:/data \
  ghcr.io/markrai/scrumboy:latest

After it starts, open http://localhost:8080. The image already sets DATA_DIR=/data and SQLITE_PATH=/data/app.db, so the volume is the only thing you had to decide. The README warns that file-backed uploads such as user-wallpapers/ also live under /data, which is why the volume should cover the directory and not just app.db.

The repository's own docker-compose.yml is a useful reference for the environment variables the server accepts. It binds to :8080, mounts ./data, and passes SQLite tuning and optional SMTP and VAPID settings through.

services:
  scrumboy:
    image: ghcr.io/markrai/scrumboy:latest
    container_name: scrumboy
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./data:/data
    restart: unless-stopped

Run docker compose up -d from the directory holding that file. If you would rather build from a clone, the README gives docker compose up --build, and for a local Go toolchain it gives go run ./cmd/scrumboy. All three paths serve the same UI on port 8080.

The MCP endpoint is the differentiator, and the least documented part

Most self-hosted boards stop at a REST API. Scrumboy also exposes an MCP (JSON-RPC) interface so AI agents can act on boards, and the repository carries a plugins/ directory and an API.md file alongside it. The README lists MCP under Integrations and API Access, and outbound HTTP webhooks in the same section.

This is the feature that would make me pick Scrumboy over a plain kanban container, and it is also where the documentation runs out. The README does not state which tools or resources the MCP server exposes, what transport it uses, or how an agent authenticates. API.md is not reproduced in the README, so anyone evaluating agent integration should treat that file as required reading before committing. The presence of the endpoint is confirmed; its surface area is not.

The same caution applies to webhooks. The README names them as outbound HTTP, which implies Scrumboy calls your URL on events, but the event catalogue and payload shape are not described. If agent-driven workflow is your reason for choosing this project, budget time to read API.md and the plugins directory rather than assuming parity with a mature automation platform.

Backups, upgrades and the AGPL-3.0 licence

The README is explicit about what to back up and silent about how to upgrade. It says to back up the whole /data volume, or at least app.db plus the WAL and SHM sidecars and user-wallpapers/, and points to docs/diagrams/scrumboy_deployment_ops.md for detail. Copying app.db while the server is running without the sidecars is the failure mode to avoid, because a WAL-mode database can hold committed transactions in app.db-wal that a bare file copy misses.

On upgrades, the README gives version numbers (v3.33.14, v3.33.12, v3.33.11) and the repository carries a CHANGELOG.md in its root, but there is no documented rollback procedure and no statement about forward or backward schema compatibility between releases. The README does not document rollback. If you run the latest tag, an image pull can move you across several releases at once; pinning a specific tag and reading CHANGELOG.md before pulling is the only defensible practice the README supports.

The licence is AGPL-3.0, shown in the README badge and the LICENSE file. The practical consequence for a self-hosted internal deployment is usually small, but AGPL-3.0 section 13 is the clause that matters if you modify Scrumboy and let users interact with it over a network. This is not legal advice; if you plan to offer a modified Scrumboy to third parties, have counsel read the licence. The repository also carries a CLA.md and CONTRIBUTING.md, which affect contributors rather than operators.

Releases, platforms and what to check before you commit

Scrumboy ships more than a container. The README documents a Windows executable (scrumboy-*-windows-amd64.exe) and macOS archives for Apple Silicon and Intel, all published on GitHub Releases with matching .sha256 files and .intoto.jsonl provenance bundles. The macOS binaries require macOS 12 Monterey or later, and the README states plainly that they are not Apple-signed or notarized, so Gatekeeper will object on first launch. For a single-user desktop instance the Windows exe is the shortest path: put it in a writable folder such as %USERPROFILE%\Scrumboy, run it, and open port 8080.

Verification is scripted rather than manual. For the Windows artifact the README gives gh attestation verify with the repository flag, and for macOS it pairs shasum -a 256 -c against the .sha256 file with the same gh attestation verify call. That is a stronger supply-chain story than most projects of this size offer, and it costs you two commands.

The alternative worth naming is a conventional tracker backed by PostgreSQL, such as a self-hosted Jira or an OpenProject instance. The difference in approach is not features, it is the operational shape: those systems assume a separate database server, migrations run by an admin, and a larger resource footprint. Scrumboy collapses that into one process and one SQLite file, which is easier to run and harder to scale past a single writer. If your team is large enough that concurrent writes contend on SQLITE_BUSY_TIMEOUT_MS, the single-file design becomes the constraint rather than the convenience.

Editorial conclusion

Adopt Scrumboy if you want a single Go binary or container that gives you boards, workload analytics, OIDC login and an MCP endpoint without a separate database server, and you are comfortable reading the repository's docs/ directory for operational detail. Do not adopt it if you need a documented upgrade path, a supported migration tool from another tracker, or a vendor SLA; the README does not describe rollback or version-to-version migration steps. Before committing, verify that the /data volume backup covers app.db, its WAL and SHM sidecars and user-wallpapers/, and confirm that your host's architecture is covered by the published multi-arch image.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. markrai/scrumboy on GitHub
3. Project website
4. README
5. Releases