Deploy Kaneo

Deploy and Host Kaneo on Railway

Deploy Kaneo on Railway when your team wants focused project management without the administration burden of a large work-management suite. Kaneo is an MIT-licensed, self-hostable app for boards, backlogs, lists, priorities, labels, due dates, time tracking, workflow rules, Gantt planning, integrations, API clients, and MCP tools. It is a practical open-source alternative to Jira, Linear, Trello, GitHub Projects, and Plane for teams that want to own their planning data.

Self-host Kaneo with a Railway architecture: two Kaneo replicas serve the web app and API from one public origin, Postgres stores durable application data, Redis distributes realtime WebSocket events between replicas, a Railway bucket stores uploaded task and comment assets, and Mailpit captures invitation mail in a password-protected inbox. Every database, cache, SMTP, and storage connection stays on Railway's private network except the two web interfaces.

Getting Started with Kaneo on Railway

Open the Kaneo public URL after all services show healthy. The first person to create an account becomes the instance administrator; there are no shipped default credentials. Registration is already locked to that first-admin bootstrap, so subsequent users must join through a valid workspace invitation. Create a workspace, add a project, and place a task on the board to confirm the database-backed workflow is ready. Invite a teammate from the Members screen, then open the Mailpit public URL with the kaneo username and the password stored in its MAILPIT_PASSWORD variable to inspect the invitation. Password sign-in remains enabled even though SMTP is configured, while invitation messages still pass through Mailpit. Add an image to a task description or comment to verify the Railway bucket path, then refresh or redeploy Kaneo and confirm the board and session remain intact.

About Hosting Kaneo

Kaneo keeps planning close to the work. Workspaces contain projects, projects switch between board and list views, and tasks share one state across backlog, calendar, Gantt, filters, comments, and time entries. Its smaller surface lets a team start without designing an enterprise workflow scheme first.

Key capabilities include:

• Boards, lists, backlogs, calendars, and Gantt timelines
• Roles, invitation-only onboarding, and project access controls
• Priorities, labels, dates, assignees, subtasks, relations, and comments
• Time tracking, notifications, workflow rules, and webhooks
• GitHub, Gitea, chat, OAuth, and OpenID Connect integrations
• API keys, device authorization, MCP, and private file uploads

The combined image serves React and the Hono API from one origin. Postgres is the system of record, Redis relays realtime events between app replicas, the Railway bucket handles presigned uploads with private reads through Kaneo, and Mailpit persists invitations until you connect an outbound relay.

Why Deploy Kaneo on Railway

Railway turns Kaneo into a maintainable team service:

• One public URL for the app and API
• Managed Postgres, Redis, and object storage
• Health-checked replicas with rolling deploys
• Private service-to-service networking
• Persistent invitation mail for immediate setup
• No external credentials required to get started

Common Use Cases

• Product delivery: plan a backlog, prioritize tasks, and move work through review to release.
• Engineering coordination: connect repositories, link development activity, and automate status changes.
• Agency and client work: separate projects inside a workspace while keeping ownership and due dates visible.
• Internal operations: manage onboarding, launches, recurring procedures, and cross-functional work without repository-bound issues.

Dependencies for Kaneo on Railway

• Kaneo — ghcr.io/usekaneo/kaneo:latest: public application and API, running two replicas on port 5173.
• Postgres — ghcr.io/railwayapp-templates/postgres-ssl:18: durable users, workspaces, projects, tasks, sessions, integrations, and asset metadata.
• Redis — redis:8.2: private Pub/Sub transport for realtime updates shared by both app replicas.
• Mailpit — axllent/mailpit:latest: private SMTP listener and protected public inbox with a persistent SQLite database.
• Railway bucket — kaneo-uploads: private S3-compatible storage for task and comment attachments.

Environment Variables Reference

Deployment Dependencies

• Kaneo source repository
• Kaneo documentation
• Mailpit runtime configuration

Hardware Requirements for Self-Hosting Kaneo

Kaneo's official drim installer documents 2 GB RAM and 10 GB disk as its local baseline. Railway separates the app, database, cache, inbox, and object storage, so each component can be observed and resized independently. A small team should begin with the defaults, watch memory and database growth, then raise app resources or storage before increasing replica count further.

Self-Hosting Kaneo with Docker

Kaneo publishes a combined multi-architecture image. A local install needs Kaneo and PostgreSQL; add Redis when running multiple app instances. This compact Compose file covers that core shape:

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: kaneo
      POSTGRES_USER: kaneo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes: [postgres_data:/var/lib/postgresql/data]

  redis:
    image: redis:8.2

  kaneo:
    image: ghcr.io/usekaneo/kaneo:latest
    ports: ["5173:5173"]
    environment:
      KANEO_CLIENT_URL: http://localhost:5173
      AUTH_SECRET: ${AUTH_SECRET}
      DATABASE_URL: postgresql://kaneo:${POSTGRES_PASSWORD}@postgres:5432/kaneo
      REDIS_URL: redis://redis:6379
      DISABLE_REGISTRATION: "true"
    depends_on: [postgres, redis]

volumes:
  postgres_data:

Generate strong secrets before the first boot, start the stack, and verify the app health endpoint:

export POSTGRES_PASSWORD="$(openssl rand -hex 24)"
export AUTH_SECRET="$(openssl rand -hex 32)"
docker compose up -d
curl --fail http://localhost:5173/api/health

For attachments, add the documented S3_* variables with a browser-reachable endpoint. Configure SMTP for invitations. Track latest: Kaneo supports the newest release and does not backport security fixes.

How Much Does Kaneo Cost to Self-Host?

Kaneo is free under the MIT license with no self-hosted seat limit or paid feature edition. The hosted Kaneo Cloud service starts at $4 per month, but it is not required for this deployment. On Railway, you pay only for the compute, database, Redis, volume, and object-storage usage your project consumes. Optional external services such as OAuth providers, outbound SMTP, and Sentry may have their own costs.

FAQ About Kaneo on Railway

What is Kaneo?

Kaneo is an MIT-licensed project manager for boards, tasks, timelines, roles, integrations, APIs, and MCP tools.

What does this Railway template deploy?

Two Kaneo replicas, Postgres, Redis, persistent Mailpit, and an object-storage bucket. Only Kaneo and the protected inbox are public.

Why does self-hosted Kaneo need Postgres and Redis?

Postgres stores durable data and sessions. Redis broadcasts realtime changes between app replicas.

Why is object storage included with Kaneo?

It stores task and comment attachments outside app containers so uploads survive redeploys.

How do I create the first Kaneo administrator?

Create the first account at the public URL. It becomes administrator; later users need invitations.

How do I enable GitHub integration in self-hosted Kaneo?

Create a GitHub App and set GITHUB_APP_ID, GITHUB_PRIVATE_KEY, and GITHUB_WEBHOOK_SECRET. GitHub sign-in uses a separate OAuth App.

Can I use a real SMTP provider instead of Mailpit?

Yes. Point SMTP_* at the provider, or configure Mailpit to relay while retaining a copy.

How should I upgrade Kaneo on Railway?

Back up Postgres, review release notes, and redeploy latest; startup applies database migrations.