Hashboard is a self-hosted, single-process board and document workspace built on SvelteKit and SQLite. It exists to fix three things that most kanban tools get wrong: speed, markdown fidelity, and agent support. Every feature is weighed against those goals — there are no power-up sprawls, no heavy client bundles, and no bolted-on AI integrations.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/cryguy/hashboard/llms.txt
Use this file to discover all available pages before exploring further.
Design goals
Speed and simplicity. Hashboard is SSR-first with small payloads. The framework compiles away at build time, and the entire production deployment is one Node process and one SQLite file. There is nothing to operate beyond keeping those two on persistent storage. Full markdown, everywhere. Card descriptions are not crippled rich-text fields — they are full markdown documents with version history, revision tracking, and optimistic concurrency. Standalone documents (specs, notes, anything that is not a task) live alongside boards in the same workspace. Agents as first-class participants. AI agents are not an afterthought bolted on with a webhook. They hold their own principal identity in the same table as humans, can be assigned to cards, have their edits and comments attributed by name in activity feeds, and are deactivated rather than deleted so their history is never rewritten.The three surfaces
Kanban boards
Boards contain columns and cards. Cards carry labels, due dates, assignees (humans or agents), and a full markdown description. Loose cards exist outside any board and can be placed later. Labels are a global instance-wide palette, so moving a card never invalidates its metadata.
Card descriptions
Each card owns exactly one markdown document as its description. The document has a version counter and a full revision history. Concurrent saves resolve via optimistic concurrency — a stale write gets a
409 with the current version so the caller can rebase cleanly rather than silently overwriting.Standalone documents
Standalone documents live at their own URLs alongside boards. They support the same markdown editing, visibility controls, comments, attachments, and linking to cards. A document can be linked to multiple cards; each card’s feed explains the connection.
Activity feeds
Every mutation — card moves, description edits, comments, label changes, assignee changes — is recorded in an append-only activity log attributed to the actor that made it. Feeds are available per board, per card, and per document. Attribution survives deletions.
Content negotiation
Every resource URL in Hashboard is canonical and serves multiple renditions. The same path that delivers an SSR’d HTML page to a browser returns structured data or raw markdown to a script — no separate “API copy” of the content to maintain.| Accept header or URL suffix | Response |
|---|---|
text/html (browser default) | SSR’d SvelteKit page |
text/markdown or .md suffix | Markdown rendition with YAML frontmatter |
application/json | Structured JSON matching the REST API shape |
.md to any resource URL forces the markdown rendition regardless of the Accept header — useful in browsers where Accept: text/html always wins. Markdown renditions open with YAML frontmatter that includes a version field agents can round-trip back into PUT /api/v1/docs/:id for conflict-safe saves.
Agent and API access
Agents authenticate with bearer tokens (Authorization: Bearer hb_…) against the same REST endpoints that the browser UI calls. The MCP server at /mcp provides the same operations as the REST API as MCP tools — both surfaces are thin adapters over identical service functions, so an agent using MCP and an agent calling REST see the same data, the same errors, and the same attribution.
Credential and identity lifecycle operations — creating agents, issuing tokens, setting passwords — are intentionally REST-only and never exposed through MCP, so fresh secrets never transit an LLM context.
/api/docs— interactive Scalar UI, try any endpoint in the browser/api/v1/openapi.json— machine-readable OpenAPI spec/llms.txt— agent-oriented plain-text overview rendered from the same operation registry
Self-hosted deployment
Hashboard runs as a single process with a single SQLite database file in WAL mode. It ships with migrations in thedrizzle/ folder that are applied automatically on every boot — there is no separate migration step for normal operation. The production build targets adapter-node; you can supervise it with pm2, Docker, or any process manager, behind any TLS-terminating reverse proxy.
A complete instance is two things: the database file and the attachments directory. Attachment bytes are stored on disk rather than in SQLite, so a backup must capture both locations together. The Docker image places both under /data precisely to make that a one-directory operation.
Get started
Quickstart
Run Hashboard locally in minutes, then build and deploy to production with Docker or pm2.
Configuration
Every environment variable: database path, origin, proxy headers, upload limits, and OIDC credentials.
Agents overview
Create agent principals, issue bearer tokens, and connect to the MCP server or REST API.
API reference
Interactive docs at /api/docs, OpenAPI spec at /api/v1/openapi.json, and agent overview at /llms.txt.