Plans and tasks each carry Markdown notes, and the repository is explicit about what they are for: recording decisions and their rationale so an agent picking the work up tomorrow has the context that would otherwise have died with the session. Ordering is a first-class operation rather than a priority field, which suits work that gets resequenced rather than re-scored. Persistence is on you — the data lives in the container's Valkey, so mount the volume before you start relying on it.
A Go server that keeps plans and their tasks in Valkey, so an AI agent can create, order, update and complete work items across separate conversations.
- create_plan, get_plan, list_plans, list_plans_by_application, update_plan and delete_plan
- create_task, get_task, update_task and delete_task inside a plan
- list_tasks_by_plan and list_tasks_by_status, so an agent can ask what is still open
- reorder_task — priority changed by moving a task within its plan
- update_plan_notes, get_plan_notes, update_task_notes and get_task_notes — full Markdown notes on both plans and tasks, with headings, tables and code blocks
- Three transports from the same image: stdio, SSE and streamable HTTP, one enabled at a time
- A health endpoint, and a named Docker volume for persistence
Docker with a named volume for the Valkey data, and one transport switched on explicitly — ENABLE_SSE, ENABLE_STREAMABLE_HTTP or ENABLE_STDIO, all off by default. The published image runs Valkey alongside the server, exposing 8080 and 6379. No account and no key.
One command — docker pull ghcr.io/jbrinkman/valkey-ai-tasks:latest