Kaneo keeps project management centered on boards and tasks
Kaneo presents itself as the antidote to project software that grows into a company operating system. The core is familiar: teams create workspaces and boards, then track tasks and labels in a web interface. That narrower pitch is credible for a small product group that mainly needs to see work, assign it, and move it. It is less convincing for a portfolio office that lives in dependency maps, capacity reports, and custom workflow rules.
The repository is still a sizeable TypeScript monorepo. Our checkout contained 1,638 files and about 140,624 source lines before dependencies. The product includes a web application, API, shared packages, deployment assets, and an official MCP server. GitHub and OAuth integrations, SMTP, notifications, Redis-backed WebSocket broadcasting, and cloud abuse controls are optional. You can keep the first installation small, but the platform has room to become operationally serious.
Docker Compose needs PostgreSQL and two real secrets
The README's quickest self-hosted path uses one Kaneo container beside PostgreSQL 16. You copy the sample environment file, set the public client URL, choose a database password, generate an authentication secret, and start Compose. PostgreSQL data sits in a named volume. The bundled container serves the application on port 5173 and reaches the database through the Compose service name.
That example is good, though it is not a backup or security plan. The AUTH_SECRET must contain at least 32 characters, and the database needs durable storage plus tested recovery. An internet deployment should use HTTPS and an exact client URL. Our 20.1 MB checkout had a Compose file but no Dockerfile, while the project publishes a container through GHCR. Operators who require a locally inspectable image build path should review that release pipeline before adoption.
What happened when we ran it
Our unprivileged Debian sandbox cloned commit 367132d with 3 CPUs and 8 GB of RAM. pnpm installation succeeded in 52 seconds, adding 1,476 packages and consuming 1,539 MB. The build completed successfully in 39 seconds. This is a heavy dependency footprint for a deliberately simple project manager, but installation and compilation did not need manual repair in our clean environment.
The test command also succeeded, finishing in 64 seconds. Our harness found 15 CI workflow files, a tests directory, and workspace configuration. We did not start PostgreSQL, create users, send email, connect GitHub, or drive a browser through a project workflow. The passing code checks lower the cost of a trial; they do not establish how upgrades, backups, or concurrent editing behave on your server.
MCP access is useful only with the same permission discipline
Every Kaneo instance exposes an HTTP MCP endpoint at /api/mcp, and the project publishes an stdio package for clients such as Claude and Cursor. The server can manage tasks, projects, and labels. Device-flow clients named kaneo-cli and kaneo-mcp are allowed by default unless the operator replaces that list. This makes a private task board accessible to an assistant without moving the whole product to a hosted planning service.
An MCP connection can change project data, so it deserves the same access review as the web interface. Limit trusted client identifiers, remove old device grants, keep the endpoint behind HTTPS, and check which users an automation represents. The successful 64-second test run says nothing about whether a prompt should be allowed to close a task or relabel a board. Start with a low-impact workspace before placing an agent beside delivery commitments.
Horizontal scaling adds Redis and production configuration
A single API instance broadcasts WebSocket updates in memory. Multiple instances require Redis, with documented standalone, Sentinel, and cluster modes. SMTP changes sign-in behavior to email verification codes unless an environment setting restores passwords. Optional Sentry integration stays off when its DSNs are absent. Cloud mode adds disposable-email blocking, Turnstile checks, guest restrictions, and tighter signup limits for hosted multi-tenant deployments.
Kubernetes users get a Helm chart for the app, PostgreSQL, ingress or Gateway API, autoscaling, and external secrets. The chart requires Kubernetes 1.23 or newer, Helm 3.2 or newer, and persistent-volume support. Its default database credentials are example values, not production choices. At that point Kaneo is no longer a two-command hobby deployment; it is project data with a database, ingress, secrets, resources, and a release process.
Current board bugs matter more than the minimal pitch
Open issue 1637 asks for local-storage support, confirming that PostgreSQL remains mandatory even for users wanting a personal offline board. Issue 1645 reports an unexpected result when marking a backlog task as planned. Issue 1620 says longer label values are truncated too aggressively to distinguish similar labels. These are narrow reports rather than proof of broad unreliability, yet each touches a daily project-management action and deserves a reproduction against your intended workflow.
GitHub recorded 8,537 stars, 74 combined issues and pull requests, and a push on August 26, 2026. Release v2.22.0 arrived on August 21 with a missing-label API fix and release-process documentation. The same-week push and issue activity show active maintenance. Kaneo earns a trial when simplicity is a product requirement, not just a slogan. Keep the trial focused on your real backlog, labels, login flow, and backup restore before moving a team's source of truth.