It's a Plan: a self-hosted tracker where agents hold an assignee slot
Open-source, self-hosted alternative to Linear and Plane. Project management and issue tracking where teams and AI agents work side by side to plan and ship products.
At a glance
- What is it?
- Itsaplan (croffasia/itsaplan) is an AGPL-3.0 TypeScript issue tracker that gives AI agents roles, permissions and assignments on the same board as people. Here is the mechanism, the setup path, and the pre-1.0 caveat that matters most.
- Who is it for?
- Adopt It's a Plan if you want issue tracking and agent execution inside one self-hosted system, and you can absorb breaking changes between minor releases. Do not adopt it if you need a frozen API surface, or if you only want a tracker and would rather not run a runner process on a developer machine.
- 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 last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, 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 between a tracker and an agent that can act on it
Most issue trackers now offer an AI feature that summarises a thread or drafts a description. The issue stays a document. It's a Plan takes a different position: an agent is a project member with a role, permissions and an assignee slot, so it takes issues on the same Kanban board as your people. The README states an agent's run starts on an @mention in a comment, on an assignment, or on a schedule. That is the whole pitch, and it is narrower than the tag list suggests. The project also describes itself as a full issue tracker on its own, with projects, boards, cycles, custom fields and dashboards, and says you can use it that way and never turn on a single agent. So the audience splits in two. Teams that want agent work to land in the same queue as human work are the primary audience. Teams that want Linear-style issue tracking on their own server, with agent support as an optional layer they may never enable, are the secondary one. The repository topics list jira-alternative, linear-alternative and trello-alternative, which sets the comparison the maintainers expect you to make.
Two agent types, two very different trust boundaries
The README splits agents into internal and external, and the split is the most consequential design decision in the project. Internal agents run on the instance: you configure the model, system prompt, tools and reusable skills, written inline or imported from a GitHub repository. External agents run on your own machine under your own account, via the @itsaplan/runner package, which hands each task to Claude Code, Codex, Antigravity CLI, GitHub Copilot CLI, opencode, or any command that reads stdin. A third option exists for teams that want neither: control the run queue through the API and do the work in your own implementation. The trust boundary is the point. An internal agent needs model credentials on the server and its tool calls execute there. An external agent keeps execution on a developer machine and the runner streams the reply and its tool calls back, resuming the same coding agent session on each chat message. That is a real architectural difference, not a packaging detail, and it determines what you have to secure and what you have to pay for. The README does not describe how internal agent tool calls are sandboxed, so treat that as unverified until you read the source.
The surface area you inherit when you self-host
The platform list is long, and each item is something you operate. REST API with an OpenAPI reference and API keys. An MCP server so an external assistant can read and change issues through the same API. Outgoing webhooks with signed payloads, retries and a delivery log. Pull requests from GitHub, GitLab, Gitea, Forgejo and Bitbucket, where a phrase like "Fixes KEY-42" links the pull request to the issue and the issue moves when the pull request opens and merges. Authentication by email or username and password, passkey, or Google. Notifications by email through SMTP or Resend, and by Telegram, with per-member preferences. Agent tools for Notion, Telegram, Threads, Instagram, Jina, Firecrawl and Gitea. The interface ships in English, Ukrainian, Russian, Simplified Chinese, Arabic, French and Bahasa Indonesia. On the product side there are Kanban, table, timeline and calendar views, cycles that time-box work with unfinished issues rolling to the next cycle, custom fields, saved view tabs with two-level grouping, subtasks and checklists, issue links typed as blocks, relates or duplicates, dashboards for throughput, breakdown and pulse, Markdown docs in a tree with revision history, freeform notes boards, public read-only share links, and initiatives. That is a lot of code to keep patched, and the AGPL-3.0 licence is part of the calculus.
Getting an instance running from the repository's own instructions
The README offers three deployment buttons: Railway, Coolify and Docker. The Coolify path points at docs/coolify.md and the Docker path at docs/self-hosting.md, and the README does not inline the compose file or environment variables, so those two files are the real starting point rather than anything quoted here. The runner is the one component with an explicit install command in the README: install @itsaplan/runner, and it will dispatch tasks to a coding CLI you already have. Beyond that, the README names the configuration surfaces without giving values: model, system prompt, tools and skills for internal agents; API keys for the REST API; SMTP or Resend for email; Telegram for notifications; per-project custom fields, labels, states and issue types. If you are evaluating this before deploying, the honest sequence is to read docs/self-hosting.md, confirm which database the compose file expects, and check whether the Coolify path in docs/coolify.md matches the infrastructure you actually run. Nothing in the supplied material states minimum resource requirements, supported database versions, or a migration path between releases, and those are the questions that decide whether a self-hosted tracker is a weekend or a quarter.
Pre-1.0, and the README says so plainly
The README carries a sentence that should shape any adoption plan: the project is under active development and you should expect breaking changes before the first stable release. The release cadence supports that reading. v0.15.0 landed on 24 August 2026, v0.16.0 on 31 August, and v0.17.0 on 6 September, so roughly weekly minor bumps, each one a potential migration. For a personal instance or an internal tool you can absorb that. For a team that has wired the REST API into CI, built dashboards against the OpenAPI schema, or written webhook consumers, a weekly minor release is a maintenance line item, not a footnote. The second limitation is structural rather than temporal. Agent runs depend on the model and on the external CLI you point the runner at, so output quality and cost are not properties of It's a Plan. The README lists which CLIs the runner supports but says nothing about how a failed or partial run is retried, or what happens to an issue an agent has claimed when the runner process dies. If your workflow depends on agents finishing what they start, that gap is the thing to test before you migrate a real backlog.
How it differs from Plane, and where a hosted tracker still wins
Plane is the closest open-source comparison and the one the README names first. Both are self-hosted, both cover projects, issues and cycles, and both are aimed at teams leaving per-seat pricing. The difference is where the agent lives. In a tracker like Plane, an agent integration is an external system that reads and writes through an API; the tracker has no concept of an agent as a member. It's a Plan makes the agent a first-class assignee with permissions, an @mention handle, a chat thread with its own conversation history, and a run queue that the REST API can drive. That is a genuine architectural divergence, and it is also the reason to be cautious: it means the tracker owns scheduling and execution state, not just records. If you want a mature tracker with a wide plugin ecosystem and you plan to bolt automation on yourself, a project that keeps agents outside the data model is the lower-risk choice. If you want the agent's work to appear as issues moving across a board your team already watches, It's a Plan is doing something the others are not. The MCP server cuts the other way too: it lets an external assistant read and change issues through the same API, so you are not fully locked into the built-in agent runtime.
Licence, upgrade cost and what to check before you commit
The licence is AGPL-3.0. For an internal instance that only your team reaches, that is usually unremarkable. If you modify It's a Plan and let users interact with it over a network, the AGPL's source-availability obligation is the clause to read, and this article is not legal advice; take it to whoever handles licensing for you. The upgrade cost follows from the cadence. Three minor releases in under three weeks, each tagged, with a README warning about breaking changes before 1.0, means you should pin a version, read the release notes before bumping, and treat your database as something you can restore. The features most likely to cost you maintenance are the ones with external dependencies: the five forge integrations, the webhook delivery log with retries, the seven notification and tool channels, and the runner talking to whichever coding CLI you installed. Each is a place where an upstream change becomes your problem. The strongest signal in the repository is the one the maintainers put in the README themselves: use it as a plain tracker first, and only turn agents on once the tracker has earned its place in your workflow.
Editorial conclusion
Adopt It's a Plan if you want issue tracking and agent execution inside one self-hosted system, and you can absorb breaking changes between minor releases. Do not adopt it if you need a frozen API surface, or if you only want a tracker and would rather not run a runner process on a developer machine. Before committing, read docs/self-hosting.md, confirm the Docker and Coolify paths match your infrastructure, and check whether the AGPL-3.0 network clause fits how you expose the instance to users outside your organisation.
Community notes