Kanera runs on your own server from one Docker Compose file, with the same feature set as hosted Kanera and no Kanera per-seat fee.
Kanera brings its own database, cache, migrations, worker, and web tier. Nothing here is a managed service you have to buy first, and the browser only ever talks to the web container.
Your infrastructurewebThe built app behind nginx. The only service a browser needs to reach.
apiBoard traffic and Socket.IO, proxied internally by web. Two replicas by default.
workerSchedulers, notifications, webhook delivery, and cleanup. Exactly one of these.
postgresApplication data on a persistent volume. No managed database to buy first.
valkeyRealtime fanout, presence, and shared rate limits across replicas.
migrateRuns pending schema changes once, before the app services start serving.
public-apiREST, webhooks, and the OpenAPI reference. Expose it only if you want it.
mcpStreamable HTTP for AI clients, backed by the public API.
db-backupOptional scheduled Postgres dumps, GPG encrypted, pushed to S3-compatible storage.
Uploads live on a Docker volume, or S3-compatible storage when you configure it. A Prometheus, Grafana, and Loki profile ships in the same file, off unless you opt in.Environment, domains, and health checks
Kanera is light at team scale. These are the baselines the deployment guide starts from, so you can price a machine now rather than after the first import.
Planning baselines, not measured guarantees. Concurrent activity matters more than the number of registered accounts, and file retention usually drives disk before Kanera does. The optional Prometheus and Grafana profile adds roughly 0.7 to 1.5 GiB of memory on top.
| Typical team | Server | Disk |
|---|---|---|
| Personal or light use | 1 vCPU, 1 GiB | 10 GiB |
| 1 to 25 active users | 1-2 vCPU, 2 GiB | 20 GiB |
| 26 to 100 active users | 2-4 vCPU, 4 GiB | 40 GiB |
| Over 100 active users | 4+ vCPU, 8+ GiB | 80+ GiB |
The self-hosted edition builds from the same codebase as hosted Kanera Pro. There is no community tier with the useful parts removed.
Hosted Free caps users, boards, automations, and shared storage. A self-hosted organisation has no seat count, board limit, or plan check, agent connections carry no plan restriction, and attachment storage is your own disk or S3 bucket.
Trello has no self-hosted edition, so the move is an export and an import. The importer runs the same on your server as it does on ours, and it hands every mapping decision back to you.
One board per JSON export, up to 50 MB. The Trello board is never changed by any of this.
Workspace settings → Import walks the lists, labels, custom fields, and members, and each one is created, reused, or skipped on your say. Confirming is the first thing that writes data.
Set TRELLO_API_KEY in the environment file and users can connect Trello during an import so uploaded attachments are copied. Without it, links back to Trello are kept.
Trialling hosted Kanera first? Export each board to JSON and import the archive into your own install. The route runs in both directions.The Trello import in detail
Running Kanera is not the hard part; keeping it running is. Everything below moves from us to you the moment you deploy, and there is no support contract that quietly covers it.
Two current limits either way: Kanera has no single sign-on today, and the interface is English only. Where Kanera does not fit.
Docker Compose on your own server, your database, your files, your network boundary. There is no Kanera licence or per-seat fee, and the server does not contact us for update or licence checks.
Best when deployment control is a requirement you can staff.Read the deployment guideHosted Kanera Pro is $5 per user per month, or $49 per user per year, and every workspace starts on a 30-day trial. Updates, backups, mail, storage, and uptime are ours.
Best when nobody on the team should own infrastructure.See hosted pricingKanera is source available under Elastic License 2.0. You can read, modify, and run it for your own organisation. You cannot provide it to third parties as a hosted or managed service.The licence text
A server with Docker and Docker Compose, a domain pointing at it, and HTTPS in front through Caddy, Traefik, nginx, Dokploy, or a cloud load balancer. Kanera brings its own PostgreSQL and Valkey, so there is no managed database to provision first.
SMTP credentials are optional but recommended, since invites, verification, and notification email need them. Plan how the database volume and the uploads volume get backed up before you invite anyone.
The deployment guide starts from 1 vCPU and 1 GiB of RAM for personal use, 1 to 2 vCPU and 2 GiB for up to 25 active users, 2 to 4 vCPU and 4 GiB up to 100, and 4 or more vCPU with 8 GiB or more beyond that.
Those are planning baselines rather than measured limits. Concurrent activity matters more than the number of registered accounts, file retention usually drives disk before Kanera does, and the optional Prometheus and Grafana profile adds roughly 0.7 to 1.5 GiB of memory.
None. The self-hosted deployment builds from the same codebase as hosted Kanera Pro, including Table reporting, Global Work views, nested notes, automations, board guests, notifications through email, push, ntfy, Gotify, and personal webhooks, Slack, Discord, Telegram, and Zulip chat destinations, the REST API, managed webhooks, and the MCP server.
A self-hosted organisation also has no seat count, board limit, automation limit, or plan check, and attachment storage is your own disk or S3-compatible bucket rather than a plan quota.
No. The self-hosted server does not call us for update checks or licensing, and hosted billing checks are not active in normal self-hosted mode.
Outbound traffic is what an administrator configures: SMTP, S3-compatible storage, webhooks, chat destinations, the notification receivers users choose, browser push, OAuth or MCP clients, Trello attachment copying, and monitoring alerts.
Pull the repository and rebuild the services with Docker Compose. The one-shot migration service applies pending schema changes before the API, worker, and public API start serving traffic.
On Dokploy, redeploy the application after pulling the latest code and it rebuilds from the same compose file.
Two things need backing up: the PostgreSQL data volume and the uploads volume, unless you have moved files to S3-compatible storage. A manual dump is a single pg_dump through Docker Compose.
Kanera also ships an optional backup service that dumps PostgreSQL on a schedule, encrypts it with GPG symmetric AES-256, uploads it to S3-compatible storage, and prunes old copies. Keep the encryption passphrase somewhere durable outside the deployment, and test a restore before you rely on it.
Yes. The Trello JSON importer is part of the product, so it runs the same reviewable mapping flow on your server as it does on hosted Kanera.
To copy uploaded Trello attachments as well as their links, set a Trello API key in the environment file. Users then connect Trello during the import so Kanera can fetch the files.
Yes. Expose the MCP service on its own domain and point compatible clients at its /mcp address. Clients authenticate with a personal or workspace API key, or through browser-based OAuth once the public OAuth URLs are configured.
Self-hosted deployments have no plan restriction on agent connections.
Not today. Kanera authenticates with email and password, and has no SAML, OIDC, LDAP, or SCIM support. Some IT teams treat that as a gate, so confirm it before planning a wide rollout.
The OAuth support in Kanera is for AI agents and API clients connecting to Kanera, not for signing users in from an identity provider.
No. Elastic License 2.0 lets you run and modify Kanera for your own organisation, but not provide it to third parties as a hosted or managed service. Talk to us if you need different terms.
The deployment guide covers environment, domains, health checks, updates, and backups.
Docker Compose, source available under Elastic License 2.0, no Kanera per-seat fee