- Category
- Productivity
- Rank
- No. 2044Tools index
Previous survey · No. 2050 ·
- Pricing
- Open Source
- Type
- APP
- Use case
- Productivity & Collaboration
- GitHub
- 9.4k stars
- Latest release
- v2.36.0
- Date
About
Kaneo is an open source project management tool built as a deliberate reaction to feature-heavy platforms, on the argument that most trackers fail by having too many features rather than too few. It ships as a self-hostable stack with Docker Compose files and a Helm chart, alongside a hosted cloud option and a community Discord.
What it does
Kaneo is a team task tracker. Work lives in shared workspaces and can be viewed as a board, list, calendar or Gantt chart, and each task carries subtasks, dependencies, attachments, comments and time logs. A TypeScript API backed by PostgreSQL sits behind a separate web front end, and the two ship together in one container image. Projects can link to GitHub and Gitea repositories so rules move cards when repository activity changes, and the API is exposed both as REST and as an MCP endpoint (Model Context Protocol, the interface AI assistants use to call tools) so an assistant can read and edit tasks.
Why it's ranked here
MIT licensed, one image that serves the web app and API on a single port, and an API whose every route declares its request shape and error responses. The AI hook is built in rather than bolted on: a hosted MCP endpoint with OAuth sign-in and per-user tokens, plus a separate MCP package that runs locally for desktop assistants. A written security policy promises acknowledgement within 3 days and an assessment within 7, and a separate policy sets rules for AI-assisted contributions. That combination makes it a serious candidate for teams that want an assistant working inside their tracker.
What's good
The limits are explicit. Task list responses cap at 100 tasks per page, 50 by default, and descriptions over 64 KiB are deferred instead of sent inline. GitHub issue import runs in bounded steps that save progress after each page and can be resumed after a failure. In production, credentialed cross-origin requests are refused unless allowed origins are configured, with a comment explaining why reflecting any origin is unsafe. AI clients register as public clients protected by PKCE (a proof step that stops a stolen authorization code being reused) plus an explicit consent page. The container runs as a non-root user and ships a health check.
Tradeoffs
Self-hosting needs PostgreSQL, Redis once more than one API instance runs, and S3-compatible storage for uploads. Only the latest release receives security fixes, so operators have to keep upgrading. Configuration has sharp edges the docs call out: changing the browser API address inside a running container does nothing, sign-in breaks if the auth secret changes between restarts, and private-network webhook destinations should only be enabled on trusted deployments. Pending sign-in emails get up to 10 seconds during graceful shutdown but are not persisted across a crash. Task write routes also pass through a billing entitlement check.
How to use it well
A fit for small teams that want a tracker they run themselves, with board and timeline views, repository-linked automation, and an assistant that manages tasks over MCP. Start from the single container image, set the client address so the API address is derived for you, and keep the auth secret stable. Point remote AI clients at the built-in MCP endpoint, or run the standalone MCP package with an API key for non-interactive use. The first non-guest account becomes the instance admin, so keep a fresh instance private until you have created it. Set the registration switches before inviting anyone.
Technical notes+
apps/api/src/index.ts assembles a Hono app with OpenAPIHono routes, drizzle-orm migrations run at startup, @hono/node-ws WebSockets with maxPayload set to MAX_WEBSOCKET_MESSAGE_BYTES and perMessageDeflate off, and compress() for multi-MB board JSON. apps/api/src/mcp/index.ts implements OAuth dynamic client registration with S256 PKCE and token auth method none, checks bearer tokens through better-auth sessions, rejects banned users, and serves legacy requests on a fresh stateless WebStandardStreamableHTTPServerTransport so any replica can answer. packages/mcp/src/server.ts is the stdio server, reading KANEO_API_URL and an optional KANEO_API_KEY, otherwise using a device flow. Dockerfile.kaneo runs nginx plus the API as uid 1001 on port 5173; bcrypt was replaced with bcryptjs so node_modules is architecture-independent.
Observed
- License
- MIT
- Language
- TypeScript, Node.js, pnpm workspace monorepo
- Database
- PostgreSQL required; Redis optional, for multi-instance live updates
- Packaging
- Single Docker image bundling API and nginx-served web app (Dockerfile.kaneo); hosted cloud option
- Interfaces
- Web app, REST API with OpenAPI route definitions, hosted MCP endpoint over HTTP with OAuth, stdio MCP server published to npm as @kaneo/mcp
- Integrations
- GitHub, Gitea, GitLab, Slack, Discord, Mattermost, Telegram, generic webhooks
- Security support
- Latest release only; older releases receive no backported patches (SECURITY.md)
- Contribution policy
- AI_POLICY.md permits AI-generated code but requires contributor-written issues and PR descriptions
Read from README.md, package.json, LICENSE, Dockerfile.kaneo, ENVIRONMENT_SETUP.md, AI_POLICY.md, apps/api/src/index.ts, apps/api/src/task/index.ts, apps/api/src/mcp/index.ts, packages/mcp/src/server.ts, packages/mcp/server.json, apps/api/src/github-integration/index.ts, SECURITY.md.
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.