Paca: a self-hosted Scrum board where AI agents hold sprint assignments
AI-native, free, open-source alternative to Jira, Trello, ClickUp & Monday. Built for Scrum teams where humans and AI agents collaborate as equals — on the same board, the same sprints, the same goals. Self-hosted. Fully customizable via config and plugins.
At a glance
- What is it?
- Paca is an Apache-2.0, Go-based project management platform that treats AI agents as board members rather than chatbot add-ons. The interesting part is the WASM plugin sandbox and the MCP surface; the unproven part is whether agent teammates work outside a demo.
- Who is it for?
- Adopt Paca if your team already runs self-hosted infrastructure, wants its board data on its own hardware, and has at least one engineer comfortable writing Go or Rust against a WASM plugin ABI. Do not adopt it if you need a managed SaaS board with no ops burden, or if you need a migration path off Jira with field-level fidelity, because nothing in the material describes an importer.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- 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 problem Paca picks: agents as columns, not as chat windows
Most project tools added AI as a side panel. You select text, ask a model to draft a ticket, and paste the result back. The agent never holds a work item, never appears in a sprint, and never has its own status to update. Paca's README frames the opposite arrangement: agents "are assigned to sprints and appear on the Scrumban board alongside human teammates," pick up tasks from the backlog, and update status in real time. The same list says agents collaborate on BDD specs by helping Product Owners and BAs write Gherkin scenarios, and contribute to System Design Documents. That is a specific claim about data model, not a marketing phrase. If an agent can be assigned to a sprint, then the sprint entity must accept a non-human assignee, and the board must render it. The audience is narrow: Scrum teams that already self-host, already have agents running somewhere, and want the work item to be the shared object between the two. Teams that just want a cheaper Trello clone are not the target, and the README does not pretend otherwise.
The P-A-C-A cycle and what it implies about state
Paca names its loop Plan, Act, Check, Adapt, and maps it onto Scrum phases: backlog refinement with BDD and SDD artifacts written jointly, a live sprint where humans and agents pull tasks, QA agents running automated verification with human review of AI output, and a retrospective that feeds the next cycle. The README attributes the framing to the Cynefin and Stacey models and states that complex domains need teams rather than pipelines. Read as architecture, the loop says the board is the source of truth and every phase writes back to it. That matters for anyone evaluating the tool, because it means agent output is not a separate artifact store. It lands as a task update, a spec edit, or a status change on the same board a human is looking at. The README also notes that workflow, data model and UI are configurable, and that statuses, field definitions, board layouts, sprint rules and agent behavior are driven by project-level configuration files. So the cycle is not hardcoded. A team that runs Scrumban rather than strict Scrum, which the repository topics list as a supported mode, can reshape the phases through config rather than a fork.
Plugins as WASM modules with declared capabilities
The extension story is the most technically concrete part of the README. Backend plugins compile to WebAssembly, and the README says you can write them in Go, Rust, AssemblyScript, or anything with a WASM target. Frontend plugins are standard module bundles. The repository layout is given as plugins/backend for WASM modules that add custom routes, logic and data models, and plugins/frontend for UI modules that add pages, board views and widgets. Plugins run sandboxed under a capability-based permission model: they declare exactly which host functions they need, and nothing more. That is a real architectural decision with a real cost. A capability model means a plugin cannot reach a host function it did not declare, so plugin authors must enumerate their needs up front, and a plugin that later needs a new host call requires a permission change rather than a code change alone. The benefit is that installing a community plugin from the in-app marketplace at Settings, Plugins, Marketplace is a bounded trust decision rather than an open one. For local development the README gives one command: ./scripts/install-local-plugin.sh ./my-plugin --api-key <your-api-key>. The api-key flag is the only configuration key the README shows for this path.
Getting an instance running and connecting an agent
The README's getting-started anchor is the entry point, and the release artifacts carry the installable builds. What the supplied material confirms: Paca is self-hosted, there is a Helm chart published on Artifact Hub under the paca repository, and the badge in the README points at artifacthub.io/packages/helm/paca/paca. So a Kubernetes install is the documented path, and the chart name is paca. Beyond that, the README does not spell out docker run commands, environment variables, or a compose file in the portion available here, so treat any specific install incantation you see elsewhere as unverified against this repository. The MCP server is the agent-facing integration: the README links a section titled "MCP Server, connect any AI agent to Paca," and the repository topics include mcp. There is also a Paca Skills section aimed at Claude Code, Gemini CLI, Cursor and similar tools. The v0.15.0 release notes describe a browser extension for page annotations that lets you comment on an element of a running environment's preview page and convert the comment into a Paca task, authenticating through your existing Paca session via a same-hostname cookie documented in apps/extension/README.md, with a pre-built zip attached to each release. That same-hostname detail is the constraint to watch: if your Paca instance and the preview page you annotate do not share a hostname, the session handoff described here does not apply as written.
Where Paca is the wrong tool
Self-hosting is the first filter. Paca's pitch is that you own the data, which means you also own the database, the upgrades, the TLS certificates and the backups. A five-person team with no one on call should not run this, and nothing in the material suggests a managed option exists. Second, the agent-as-teammate model is only as good as the agents you connect. Paca supplies the board, the MCP surface and the skills; it does not supply the model. If your agents cannot reliably pick up a task and post a status update, the board will fill with stalled assignments and the collaboration claim collapses into noise. Third, the release cadence visible here is fast: v0.15.0 shipped on 2026-09-08, a release candidate five days earlier, and v0.14.1 a week before that. A project moving at that rate will change plugin interfaces and config schemas. If you cannot absorb an upgrade every few weeks, pin a version and accept that you are falling behind the plugin ecosystem. Fourth, and worth stating plainly: the README makes strong claims about agents contributing to system design and probing complexity, but the supplied material contains no evaluation of output quality, no accuracy figures and no failure analysis. Treat the collaboration model as a design hypothesis you will be testing, not a settled result.
How this differs from Jira, Trello and Linear
The README's comparison table sets Paca against Jira, Trello, ClickUp and Monday on six axes: AI integration, collaboration model, hosting, cost, customization and weight. The substantive difference is the second row. In Jira and Trello, the default assignee is a licensed human account, and automation acts on tickets through rules or app add-ons; the agent is a process operating on the board from outside. In Paca, the agent is an entity on the board with sprint membership. That changes the permission model, the notification model and the audit trail, because a work item can now be owned by something that is not a person. The hosting row matters too, though less for philosophy than for cost structure: self-hosting replaces per-seat pricing with infrastructure and maintenance. If you are comparing Paca to Linear, the honest difference is that Linear is a managed product with a fixed feature surface and no plugin ABI to maintain, while Paca asks you to run the server and, if you extend it, to compile against a WASM interface that can move between releases. Neither is strictly better. They fail in different ways, and the failure you can tolerate should decide the choice.
Licence, upgrade cost and what to check before you commit
Paca is Apache-2.0, which permits commercial use, modification and redistribution, and includes a patent grant. It does not impose copyleft on your own code. If you write a plugin, the licence does not force you to publish it, though the marketplace listing flow implies a distribution path you should read the terms for separately. This is a description of the licence text, not legal advice; get counsel if you plan to redistribute a modified Paca. On maintenance cost, the material supports a few concrete observations. The plugin ABI is WASM with a declared host-function set, so a Paca upgrade that adds or renames host functions can break plugins that did not declare the new capability, and the fix lives in your plugin, not in Paca. The Helm chart is the versioned deployment artifact, so chart version and application version need to be tracked together. The browser extension ships as a pre-built zip per release, which means extension updates follow release updates rather than a store channel. Before committing, verify on a throwaway instance that your agents authenticate through the MCP server, that a trivial custom plugin installs via ./scripts/install-local-plugin.sh and receives only the host functions it declared, and that your deployment's hostname arrangement satisfies the extension's same-hostname session requirement. If all three hold, Paca is a reasonable bet for a self-hosting team with agent workloads. If any one fails, the failure will be structural rather than cosmetic.
Editorial conclusion
Adopt Paca if your team already runs self-hosted infrastructure, wants its board data on its own hardware, and has at least one engineer comfortable writing Go or Rust against a WASM plugin ABI. Do not adopt it if you need a managed SaaS board with no ops burden, or if you need a migration path off Jira with field-level fidelity, because nothing in the material describes an importer. Before committing, verify three things on your own instance: that the MCP server exposes the operations your agents need, that the plugin permission model covers the host functions your custom plugin declares, and that the v0.15.0 browser extension authenticates against your deployment's hostname, since the README ties that flow to a same-hostname cookie.
Community notes