Assigning issues to agents is the reason to evaluate Itsaplan
Itsaplan gives agents roles, permissions, and assigned issues on the same board as people. For teams already handing work to coding agents, that is a concrete reason to evaluate this self-hosted tracker: assignments can stay attached to the project. The README also documents boards and shared project documents without requiring AI.
Internal agents run on the instance with a configured model and tools. External agents run on a machine and account you control, through a runner that hands tasks to Claude Code or another supported coding CLI. Neither arrangement was demonstrated by the supplied source build. These are documented capabilities, rather than verified agent workflows at the tested commit.
What happened when we ran it
The supplied sandbox run installed Itsaplan commit e82bc56 in 18 seconds on October 19, 2026, recording 1,294 dependencies and 1,489 MB on disk. The build succeeded in 125 seconds. Tests failed with exit 1 after 7 seconds.
Before installation, the checkout occupied 40.1 MB and contained 2,918 files with approximately 242,105 source lines. The dependency footprint helps budget a development checkout; it does not measure production storage or memory requirements.
The failing tail names @repo/db#test and says its bun run test command exited with code 1. The task summary records 0 successful tasks out of 8, with none cached. Separate fragments report 7 tests across one file and 1 test across one file for the database package. Those fragments do not establish a complete-suite passing count.
The tail does not explain the database task's underlying error. Retrieve the full failing output and reproduce that task before treating the checkout as a verified development baseline. The failure alone does not establish that the tracker is broken.
The scan recorded 6 CI workflow files, a Compose file, and monorepo workspaces, with no Dockerfile or tests directory detected. The absence of a detected tests directory does not contradict the test execution in the log. The sandbox had 3 CPUs and 8 GB RAM with image label lab-node:22; actual runtime and operating-system versions remain unverified. No dependency-vulnerability result was supplied.
Production sign-in requires TLS
The self-hosting guide requires Docker and a domain behind a TLS-terminating reverse proxy. In production, browsers do not retain the Secure session cookie over ordinary HTTP. A sign-in request can succeed while the application stays signed out. The guide separately describes localhost exceptions, so this production constraint should not be generalized to every local setup.
The documented stack includes PostgreSQL and RustFS object storage beside API, worker, bot, and web services. Operators configure application URLs, secrets, database access, and storage credentials. The API can use a subdomain or a path on the web host, with corresponding proxy configuration. The source build did not verify either deployment arrangement.
The guide describes a database dump before migrations and stores attachments separately in RustFS. Before importing team history, verify recovery of both stores. A database-only backup does not cover the attachment files. That is a deployment acceptance check, not a recovery test completed in this review.
For local exploration, the README documents Docker and Bun with a setup command that chooses ports and generates secrets. That route can help start an evaluation, but its documented convenience does not establish production readiness.
Check permissions and upgrades during the pilot
The README describes a REST API and an MCP server through which an external assistant can read and change issues. Agent runs can start from an assignment, a mention, or a schedule. Use a disposable project to check what the agent can read and change, then follow an assignment through completion before granting access to important work.
The stated license is AGPL-3.0 for the main application and Apache-2.0 for the runner. A commercial-license option is mentioned, but its terms were not assessed. Organizations that exclude AGPL should resolve that requirement before investing in deployment.
The README warns of breaking changes before the first stable release. Treat that as an upstream warning, rather than inferring release stability from a version number. Pin the version used for a pilot and rehearse required workflows before upgrading a populated instance.
Recent activity does not verify proposed features
The supplied GitHub metadata records a last push on October 19, 2026, and 46 open issues and PRs in the October 20 observation. The queue included an agent-run-history proposal updated October 20. PR #586 was created October 16 and remained open in the supplied snapshot; its proposed history and runner-queue behavior should not be presented as shipped functionality.
The queue also included an October 19 request for direct cloud invocation of external agents. These records show recent participation, but do not establish maintainer response quality, long-term support, or successful operation of either proposal. Tests reported in a proposal are not results from the measured e82bc56 run.
Compare alternatives by the workflow you need
Plane documents work items, cycles, roadmaps, and cloud or self-hosted deployment. Evaluate Plane when those planning features and a hosted option are priorities. This is a comparison of documented options, not a deployment or performance comparison.
Kanboard focuses on Kanban and declares maintenance mode. Its author says development is limited to small fixes rather than new major features, while community contributions remain accepted. Evaluate Kanboard when that scope and maintenance posture suit your workflow.
Pilot Itsaplan when assigning work directly to agents is a requirement you already have. Check browser sign-in, attachment retrieval, permissions, and an agent assignment through completion in one disposable project. Keep the team's only project record elsewhere until those checks and the unresolved database test failure are understood.