Scrumboy: a self-hosted Go board server with an agent-facing MCP layer
Self-hosted project management, featuring customizable project boards, cross-project workload and flow analytics, calendar-aware planning, a sticky-note wall, portable imports/backups, realtime email notifications, and a MCP/Agent automation layer.
At a glance
- What is it?
- Scrumboy bundles kanban boards, workload analytics, calendar-aware planning and a JSON-RPC MCP endpoint into a single Go binary backed by SQLite. The trade-off is that the same process owns the database, the uploads and the agent API, so the backup unit is the whole data directory.
- Who is it for?
- Adopt Scrumboy if you want one Go binary you can run with go run ./cmd/scrumboy, a SQLite file at ./data/app.db, and an MCP endpoint your agents can call without a separate service. Skip it if you need multi-node horizontal scaling, a managed database, or a permissive licence for a closed derivative.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Scrumboy fills: one binary, no external database, no hosted account
Most self-hosted trackers assume you will run a database server next to them. Scrumboy does not. 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 with SQLite at ./data/app.db. The repository's topic list confirms the stack: go, sqlite, docker, pwa, oidc, mcp-server. That combination is the pitch. You get a single process that serves the board UI, stores its own state on a local file, and exposes an automation surface, without a Postgres container or a hosted account. The audience is small teams and individuals who already run a reverse proxy and a container runtime, and who want the tracker to be one more service in that stack rather than a vendor relationship. The scope goes past kanban: the description lists 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. That is a wide surface for one binary, and the width is the thing to evaluate, because every feature shares the same SQLite file and the same process.
Data flow: SQLite plus file-backed uploads behind one HTTP server
The architecture visible in the material is a Go HTTP server that owns both the relational state and the file state. The README is explicit that the database and file-backed uploads (it names user-wallpapers/ as an example) both live under the data directory, and that the default SQLite database may create app.db-wal and app.db-shm sidecars while the server runs. That last detail matters more than it looks. A SQLite database in WAL mode is three files, and a backup that copies only app.db can capture a state that does not match the write-ahead log. The README points at docs/diagrams/scrumboy_deployment_ops.md and tells operators to back up the whole /data volume or at least app.db plus the sidecars plus user-wallpapers/. The official image sets DATA_DIR=/data and SQLITE_PATH=/data/app.db, so in a container the volume mount is the entire persistence boundary. There is no separate object store, no external cache, and no message broker in the described layout. The MCP endpoint is described as JSON-RPC and is grouped in the README under Integrations & API Access alongside outbound webhooks, which suggests agents and webhooks talk to the same server process that serves the board. The consequence is simple to state: the process is a single point of both compute and storage, and its health is the health of the whole system.
Getting it running: three commands and a volume mount
The quickest path in the README is the published container image at ghcr.io/markrai/scrumboy:latest, described as multi-arch for linux/amd64 and linux/arm64. The documented docker run invocation binds the port to loopback and attaches a named volume: docker run -d --name scrumboy -p 127.0.0.1:8080:8080 -v scrumboy-data:/data ghcr.io/markrai/scrumboy:latest. The Compose example in the README is equally short, using image, container_name, a 127.0.0.1:8080:8080 port mapping, ./data:/data and restart: unless-stopped. From a clone, docker compose up --build uses the repository's own docker-compose.yml, which the README says uses build: . and maps ./data to /data. Without containers, go run ./cmd/scrumboy starts the server and you open http://localhost:8080. Windows and macOS users get release binaries; the macOS archives are documented as requiring macOS 12 Monterey or later, and the README states plainly that they are not Apple-signed or notarized, which means Gatekeeper friction is expected. Release artifacts ship with a .sha256 file and an .intoto.jsonl provenance bundle, and the README gives gh attestation verify scrumboy-<tag>-darwin-arm64.tar.gz -R markrai/scrumboy as the verification step. Configuration is environment-variable driven, with documented groups for server and data, encryption and TLS, OIDC/SSO, feature flags, Web Push (VAPID), SMTP for self-service password reset, public URL and reverse proxy, and an encryption key used for 2FA and password reset. There is also an owner disaster recovery section, which is worth reading before you need it rather than after.
Where the single-process design bites
The limitation is structural, not a bug list. Because the database is a local SQLite file and the uploads are local directories, the deployment scales up on one host rather than out across several. Nothing in the supplied material describes replication, a shared database backend, or a multi-node mode, so anyone planning to run several replicas behind a load balancer should treat that as unsupported until they confirm otherwise. The same coupling shapes backup and restore. A consistent snapshot requires either stopping the server or using a method that accounts for the WAL sidecars; a naive file copy of a running instance is the failure mode the README's own warning is aimed at. The MCP and webhook layer inherits the same boundary. If the process is down, agent calls and outbound notifications are down with it, and the material does not describe a queue that would let either survive a restart. There is a second, softer cost: the release cadence is fast. Three releases are listed in the supplied window (v3.33.11 on 2026-08-28, v3.33.12 on 2026-09-06, v3.33.14 on 2026-09-07), and the patch version moves quickly. That is not a defect, but it means an operator pinning ghcr.io/markrai/scrumboy:latest is opting into a moving target, and should pin a digest or a version tag instead if they care about reproducibility. The README does not document a migration or rollback procedure for schema changes between versions, which is the specific thing to confirm before letting an unattended updater pull new images.
Scrumboy against a tracker that expects a database server
The natural comparison is a self-hosted tracker such as Taiga or OpenProject, which run against PostgreSQL and separate the application tier from the data tier. That split buys you a managed backup story, the ability to run more than one application process, and a database you can query with standard tooling. It costs you a second container, connection configuration, and a restore procedure that involves two systems instead of one. Scrumboy inverts the trade. It gives you go run ./cmd/scrumboy and a file, and it takes away the horizontal scaling story and the option of pointing at a database you already operate. The difference is not cosmetic. With Scrumboy, disaster recovery is a volume copy and a container restart; with a Postgres-backed tracker, disaster recovery is a database dump plus whatever object storage holds the attachments. Pick based on which procedure your team can actually execute under pressure. There is a second axis worth naming: the MCP endpoint. The README groups MCP (JSON-RPC) for AI agents with outbound webhooks under Integrations & API Access, which means agent automation is a first-class surface here rather than a plugin. If your reason for looking is that you want an agent to read and write board state, that is a real differentiator against trackers whose automation story is a REST API plus a separate scripting layer. The material does not enumerate the MCP tools, so the shape of that surface is something you will have to inspect.
Licence, upgrades and what an AGPL deployment commits you to
Scrumboy is AGPL-3.0. For internal self-hosting this is usually unremarkable: you run the software, you do not distribute it. The obligation becomes interesting if you modify Scrumboy and expose it to users over a network, because the AGPL's network clause is the part that differs from GPL. If you are embedding it in a product, or patching it and offering it as a service, read the licence text and the LICENSE file in the repository rather than a summary, and get your own advice; this is a description of the licence identifier, not legal guidance. On maintenance, the practical costs are the ones the README already implies. Upgrades mean replacing a container image or binary and letting the app touch its SQLite schema, so the pre-upgrade step is a full copy of /data including app.db, app.db-wal, app.db-shm and user-wallpapers/. Configuration drift is the other recurring cost: OIDC, VAPID keys, SMTP and the 2FA/password-reset encryption key are all environment variables, and the encryption key in particular is the kind of value that, if lost, changes what still works. The README has an owner disaster recovery section for exactly this class of problem. Treat the environment file as part of the backup, not as deployment trivia.
Who should run it, and what to check before you do
Scrumboy fits a team that already runs Docker on one host, wants the tracker to be another container rather than a service, and has a concrete use for the MCP endpoint or the webhook output. It also fits a single operator who wants a board tool with SSO and push notifications without standing up a database. It does not fit a team that needs multiple application replicas, a database they can fail over independently, or a licence that permits a closed-source derivative. The verification list is short and specific. First, prove the backup: copy the whole /data volume, restore it into a fresh container, and confirm the boards and the user wallpapers are both intact, because the README treats them as one backup unit. Second, prove the identity path: configure OIDC and confirm that your provider's groups map onto the system roles and per-project roles the README documents, since a mismatch there is discovered at the worst time. Third, inspect the MCP tool list before you build automation on it, because the supplied material describes the endpoint's transport but not its operations. Fourth, pin the image. The releases move quickly, and ghcr.io/markrai/scrumboy:latest will not stay still while you are deciding whether the upgrade is safe.
Editorial conclusion
Adopt Scrumboy if you want one Go binary you can run with go run ./cmd/scrumboy, a SQLite file at ./data/app.db, and an MCP endpoint your agents can call without a separate service. Skip it if you need multi-node horizontal scaling, a managed database, or a permissive licence for a closed derivative. Before committing, verify three things yourself: that a restore from a copy of the whole /data volume (app.db plus the -wal and -shm sidecars plus user-wallpapers/) actually comes up, that your OIDC provider maps cleanly onto the system and project roles, and that the MCP tool surface exposes the operations you need rather than a subset.
Community notes