Kaneo Setup: Self-Host a Free Jira Alternative in 10 Minutes

Kaneo is an open source, self-hosted project management tool that positions itself as a Jira and Linear alternative you can run on your own server, and it is one of the hottest repositories on GitHub trending today with roughly 760 stars in a single day on top of 5,780 total. Setup takes about ten minutes: one CLI command if you want automatic HTTPS, or a fifteen line Docker Compose file if you would rather see every moving part. The payoff is a kanban board, backlog, labels, comments and GitHub issue sync that lives entirely on infrastructure you control, under an MIT license with no seat pricing attached.

• Two supported install routes: the drim CLI, which provisions Caddy, Postgres and Kaneo with automatic TLS, or a plain Docker Compose file you write yourself.
• Since v2.6.0 the API and web app ship as a single combined container, so a full deployment is two services plus a proxy, not four.
• Every instance exposes a built-in MCP endpoint at /api/mcp, so Cursor or Claude Desktop can read and create tasks with no extra process running.
• Hardware floor is modest: Docker 20.10 or newer, 2 GB of RAM and 10 GB of disk, which is a $6 VPS.

What is Kaneo and why is it trending?

Kaneo is a TypeScript project management app built by Andrejs Agejevs and a contributor community: a Hono API, a React and Tailwind front end, and PostgreSQL underneath. The pitch in the README is a complaint rather than a feature list. Most project tools fail not because they lack features but because they have too many, and every extra notification and workflow gate pulls a team away from the work. Kaneo ships boards, a backlog, list views, workspace labels, task comments, activity history and per project notification routing to Slack, Discord, Telegram or a raw webhook, then stops.

RelatedOpenWork Setup: Open-Source Claude Cowork in 15 Minutes

The trending spike has a practical driver. Version 2.12.1 landed on July 30, 2026, and the project is now at 5,784 stars under an MIT license, with a v2 line that consolidated the old two container split into one image and added GitHub App integration, Gitea support, S3 compatible attachment storage and an official MCP server. Self hosted Jira alternatives are a crowded field, but most either demand a Kubernetes cluster or bury the free tier. Kaneo is a single docker compose up away, and the topics on the repository say the quiet part out loud: jira-alternative, linear-alternative, self-hosted.

How do you install Kaneo with the drim CLI?

drim is Kaneo's own deployment CLI, written in Go, and it is the fastest path if you want HTTPS handled for you. It generates the Compose file, fills in the environment variables, stands up Caddy for automatic certificates, and manages the service lifecycle afterwards. Install it and run setup:

# install the drim CLI
curl -fsSL https://assets.kaneo.app/install.sh | sh

# deploy Kaneo (prompts for a domain)
drim setup

When it asks for a domain, enter the hostname whose DNS A record already points at this server, for example kaneo.example.com, and Caddy will fetch a certificate on first boot. Press Enter with the field blank instead and you get a local install reachable at http://localhost, which is the right choice for a trial run on your laptop. Three containers come up: PostgreSQL 16, the combined Kaneo container, and Caddy. Day two operations are the rest of the command set:

drim start        # start services
drim stop         # stop services
drim restart      # restart services
drim upgrade      # update Kaneo to the latest version
drim configure    # edit .env, then auto-restart

Note that drim upgrade updates Kaneo while drim update updates the CLI itself. Supported platforms are Linux, macOS and Windows through WSL, and on common Linux distributions drim will install Docker for you if it is missing.

How do you self-host Kaneo with Docker Compose?

If you already run a reverse proxy, or you simply want to read every line of the deployment before it exists, the manual route is short. Save the compose file from the README as compose.yml: a postgres:16-alpine service with a healthcheck and a named volume, plus ghcr.io/usekaneo/kaneo:latest publishing port 5173 and depending on Postgres being healthy. Then copy .env.sample to .env and fill in three values:

# .env, the three settings that actually matter
KANEO_CLIENT_URL=http://localhost:5173
POSTGRES_PASSWORD=your-strong-password
AUTH_SECRET=paste-the-openssl-output-here

# generate a real AUTH_SECRET, do not skip this
openssl rand -hex 32

# bring the stack up
docker compose up -d

Open http://localhost:5173 and create the first account. Two details save you a support thread. Inside Compose, Kaneo reaches the database at the service hostname postgres; if you run the API natively on the host instead, set POSTGRES_HOST=localhost or an explicit DATABASE_URL. And AUTH_SECRET must be a long random value of at least 32 characters, because if you leave it empty Kaneo generates a fresh one at every startup and every session dies with the container. Kubernetes users get an official Helm chart in the repository under charts/kaneo, and there is a one click Railway template if you would rather not own a server at all.

How do you connect Kaneo to Cursor or Claude Desktop?

This is the part that makes Kaneo interesting in 2026 rather than merely competent. Every Kaneo API instance ships a Streamable HTTP MCP endpoint at /api/mcp, with no extra server to run. Point an MCP client at https://your-kaneo-instance.com/api/mcp and you are redirected to Kaneo to sign in and explicitly approve the client; authentication is OAuth 2.1 with PKCE, and every tool call afterwards runs as your user. Clients that insist on stdio transport get a published package instead:

# interactive installer for Cursor or Claude Desktop
npx @kaneo/mcp

# or register non-interactively against your own instance
kaneo-mcp install --target cursor-user -y --api-url https://kaneo.example.com

Both transports expose the same tools for workspaces, projects, tasks, comments and labels. Self hosted installs already allow the kaneo-cli and kaneo-mcp device auth client IDs by default, so nothing extra needs configuring; the stdio path needs Node.js 20 or newer. In practice this means an agent can file, triage and comment on real tickets in your tracker, which is a materially different proposition from an assistant that can only talk about them.

RelatedOpenCut Setup: Self-Host the Free CapCut Alternative

How does Kaneo compare with Jira and Linear?

The incumbents still win on breadth. Jira has two decades of workflow automation, reporting and compliance tooling; Linear has the fastest interface in the category and a roadmap layer Kaneo does not attempt. Kaneo wins on the axes that made people search for an alternative in the first place: no seat tax, no data leaving your infrastructure, and a surface small enough that a new engineer understands it on day one.

What are the gotchas before you rely on it?

Four things worth knowing before this becomes the system of record for real work. First, a blank AUTH_SECRET is the single most common self inflicted wound: sessions will not survive a restart, and it looks like a bug rather than a config error. Second, WebSocket real time updates use an in memory adapter unless you configure Redis, which means running more than one API instance behind a load balancer requires setting REDIS_URL or the Sentinel or Cluster equivalents. Third, file attachments in tasks and comments need S3 compatible object storage such as MinIO, AWS S3 or Cloudflare R2 to be configured separately, so plan that before users start dragging screenshots in. Fourth, this is a young v2 line moving fast, with a documented migration path from v1 and another from the old two container layout to the combined image introduced in v2.6.0; pin an image tag in production rather than tracking latest, and read release notes before you upgrade.

Two smaller notes. Email is optional but shapes the login flow, because once SMTP is configured Kaneo defaults to email verification codes rather than passwords unless you set DISABLE_EMAIL_OTP_SIGN_IN=true. And the notification receivers for ntfy, Gotify and custom webhooks refuse private network addresses by default as an SSRF guard, so a self hosted ntfy on your LAN needs KANEO_ALLOW_PRIVATE_WEBHOOK_DESTINATIONS=true before it will fire.

Our take

The interesting thing about Kaneo is not that it is another open source Jira alternative, because that category is crowded and most entries die of feature envy within two years. It is that the deployment story is genuinely finished. A Go CLI that provisions Caddy, Postgres and the app with one command, plus a Compose file short enough to read in a minute, plus a Helm chart, plus a Railway template, is more operational polish than most projects at ten times the star count. The MCP endpoint is the other signal worth noting: it is built into the API with real OAuth rather than bolted on as a community package, which tells you the maintainers expect agents to be first class users of a tracker rather than visitors.

The honest caveat is depth. If your team lives inside Jira automation rules or Linear cycles, Kaneo will feel thin, and that is by design rather than by accident. But for a small team that wants a board, a backlog, GitHub issue sync and an audit trail on hardware it owns, ten minutes and a $6 VPS is a very short path to being done. Pin your image tag, generate a real AUTH_SECRET, and it will stay boring, which is exactly what you want from a tracker.

Original analysis by GenZTech. Tool documentation: usekaneo/kaneo on GitHub.