Short answer: Kaneo is a self-hosted, MIT-licensed project management tool written in TypeScript that is worth evaluating if you want a lean Jira or Linear alternative and can operate your own stack. The decision should rest on ops readiness, not features: before production you need to verify the HTTPS and environment configuration, exercise a database backup and restore, and test upgrades in staging, because recent releases changed cookie security, added a startup migration that can briefly lock the task table, and moved the supported runtime to Node 24. This is a source and documentation review as of 2026-08-29, based on the GitHub repository, README, and release notes; no installation or runtime testing was performed.
| Fact | Value |
|---|---|
| Review date | 2026-08-29 |
| Project | Kaneo (usekaneo/kaneo) |
| License | MIT |
| Language | TypeScript |
| Stars (snapshot) | 8,588 as of 2026-08-29 |
| Open issues (snapshot) | 77 |
| Latest release | v2.22.0, published 2026-08-21 |
| Verification level | Observed: repository, README, and release notes review |
what is kaneo?
Kaneo is an open source project management application whose repository description reads “all you need. Nothing you don’t.” The maintainers describe it as project management that “works for you, not against you.” According to GitHub metadata, it is built with TypeScript, uses React for the web client and Hono for the API, and is published under the MIT license. The README positions the project as a reaction to bloated trackers: the maintainers say most tools fail because they have too many features, and that Kaneo’s design principle is “less is more.”
The release history shows a lean but growing feature set: kanban boards, backlog, Gantt, and a per-project monthly calendar added in v2.21.0; granular task permissions; GitHub and Gitea imports with webhooks; a built-in MCP server at /api/mcp plus an npm package for AI clients; and deployment paths for Docker Compose, Coolify, Kubernetes, and a drim CLI installer. Those capabilities come from the repository README and release notes, not from testing in this review.
who should consider kaneo
Kaneo fits teams that want project data under their own control and prefer a simpler tracker than Jira. The evidence points to these use cases:
- Teams already using GitHub or Gitea: v2.19.0 added webhook handling that moves a task back when an issue is reopened, and import paths exist for both platforms.
- Teams that want AI assistants to manipulate tasks: the README documents an official MCP server, and the maintainers name Claude and Cursor as compatible clients.
- Organizations that standardize on Kubernetes or Coolify: the repository ships a Helm chart and a Coolify-optimized compose file.
- Teams that want board, backlog, Gantt, and per-project calendar views without paying for a hosted, seat-based tool.
The condition attached to every one of these use cases is the same: someone has to run it. Self-hosted means you own the database, the TLS configuration, the upgrades, and the recovery plan.
who should hold off
Teams without anyone responsible for operations should probably choose a managed tool or budget for outside help. The same applies if you need capabilities this review found no evidence of, such as mature SSO or enterprise compliance reporting. Kaneo is also young: the repository was created on 2024-12-31, so its long-term maintenance trajectory is not established. Large boards are an open question too, since the evidence includes no benchmarks; v2.21.0 did add gzip for large board payloads, which suggests board size is already a consideration for the maintainers.
what operators must check before production
the https cookie change in v2.19.0
The v2.19.0 release notes warn that session cookies now set Secure on any HTTPS deployment. Previously that flag was only set when the API and web app lived on different subdomains, so a same-domain HTTPS install was sending its session cookie in the clear. The operator-facing consequence is concrete: if KANEO_API_URL starts with https:// but the instance is served over plain HTTP, logins will stop working after the upgrade. The fix is to make the environment variable match how the instance is really served.
the startup migration for imported tasks
v2.19.0 also repairs tasks imported from GitHub or Gitea that had no priority: label. According to the release notes, those tasks were stored with no priority, the API rejected every later edit with a 400 error, and dragging a card between columns appeared to work and silently reverted. The migration sets those rows to a default priority and then makes the column NOT NULL. It runs at API startup and takes a brief exclusive lock on the task table, which matters if your instance has a very large board. If you do not use the GitHub or Gitea integration, the migration matches no rows.
environment variables and deployment paths
The README documents three main deployment routes: the drim CLI (curl -fsSL https://assets.kaneo.app/install.sh | sh followed by drim setup), which the maintainers say handles HTTPS and database setup automatically; Docker Compose with PostgreSQL 16 and the ghcr.io/usekaneo/kaneo image on port 5173; and a Coolify build using compose.coolify.yml. For Coolify, the README warns to leave KANEO_API_URL unset because it is derived from KANEO_CLIENT_URL, and a localhost value breaks browser API calls. v2.21.0 migrated the supported runtime to Node 24, so host-based installs should check their Node version. The README identifies the required secrets (AUTH_SECRET, POSTGRES_PASSWORD, KANEO_CLIENT_URL), but this review did not validate every documented variable.
backup and recovery are on you
The documented Docker Compose setup stores state in a PostgreSQL volume, which points to the database as the primary thing to back up. The README links to fuller documentation for setup and troubleshooting, but this review found no step-by-step backup and restore runbook in the evidence, so test one before trusting production data. Losing AUTH_SECRET or the database volume should be treated as an incident plan, not a surprise.
upgrade cadence is a maintenance commitment
Between 2026-08-15 and 2026-08-21, the maintainers published five releases: v2.19.0, v2.19.1, v2.20.0, v2.21.0, and v2.22.0. That cadence has a real upside: v2.19.1 was published on the same day as v2.19.0 to fix a data-loss bug where task descriptions could be saved to the wrong task. It also means operators should expect regular upgrade work and should read release notes before applying them, since at least one release (v2.19.0) contained changes the maintainers themselves flagged as upgrade-relevant.
maintenance signals in the repository
The project looks actively maintained. GitHub metadata as of 2026-08-29 shows 8,588 stars, 723 forks, and 77 open issues, with the default branch pushed on 2026-08-28. Recent releases show the maintainers investing in observability: v2.20.0 added runtime Sentry instrumentation, source maps, an error boundary, and alerts and dashboards provisioned as code. There is a sponsorship program, a Discord community, and a documented contributing guide. None of that proves the software is bug-free, but it is evidence that bugs are being collected and fixed rather than accumulating silently.
limitations and unverified claims
This review did not install or run Kaneo, so several things remain unverified: the README claim that the tool is “actually fast,” the behavior of the MCP server, the quality of the GitHub and Gitea integrations, and the real impact of the startup migration lock on large boards. The project is also young relative to enterprise trackers, and v2.22.0 itself is a light release: a blog section with alternatives round-ups, a 404 fix for missing labels, and CI and documentation changes. That is normal, but it means the latest version should not be read as evidence of new production features.
alternatives and evaluation questions
If you are shopping, compare Kaneo against hosted tools such as Jira or Linear and open source trackers like Planka, OpenProject, or Plane. The evidence only supports one direct comparison point: the repository contains a Planka import path, which the v2.21.0 release notes refactored, so moving from Planka to Kaneo is at least a documented direction. The other alternatives are named here as evaluation candidates, not reviewed findings.
Ask these questions before committing:
- Who owns backups, restores, and incident response, and what is the documented procedure?
- Can you reproduce a deployment in staging and run an upgrade across consecutive releases, including v2.19.0?
- Does your environment match the documented constraints, especially HTTPS,
KANEO_API_URL, and the Node 24 runtime? - What is your largest realistic board, and have you load-tested the tool against it?
- Do you need SSO, LDAP, or compliance features that are not present in the evidence?
- What is the rollback plan if an upgrade breaks logins or the API?
verdict
Kaneo is a credible self-hosted option for small and mid-sized teams that want a lean project tracker and can operate their own infrastructure. The maintainers ship frequently, publish unusually candid upgrade notes, and fixed a data-loss bug quickly, which is a strong signal for an operator audience. Adopt it if you are prepared to own configuration, upgrades, backups, and monitoring; treat the v2.19.0 HTTPS and migration notes as required reading; and validate performance on your own data before migrating a large board. If you cannot commit to that operational work, a managed alternative is the safer choice. This verdict is an evaluation of documented evidence, not a guarantee of production behavior.
what I can do next
If this review matches your situation, the practical next step is to close the gaps it identified. I can audit your Kaneo deployment and environment configuration, plan and execute upgrades across releases such as v2.19.0 and v2.21.0, and set up the backups, monitoring, and incident response that a self-hosted instance needs. The goal is to get you to a state where upgrades are routine and a restore is a tested procedure rather than a hope.