Self-hosted Trello alternatives compared

Which self-hosted Trello alternative should you pick?

Three self-hosted Trello alternatives are worth your time: Planka if you want Trello's exact board and its import file, Vikunja once a team needs single sign-on and more than a board, and Kanboard when the VPS (virtual private server) is small. Do not start a new project on Focalboard. Its standalone server has not had a release in 783 days, and its README now asks for a maintainer.

Wekan is the fifth of the 5 tools here. It works, and it costs several times the memory of everything else. Every version, licence and date below was checked on 5 August 2026.

How much RAM does each board tool need?

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

Those are typical idle figures for a fresh install with nobody using it, the kind of number docker stats reports a minute after the stack comes up. Use them for sizing a plan, then measure your own. The shape matters more than the exact megabyte.

Kanboard is the floor at 70 MB because it is PHP with SQLite. No long-running application process holds your boards in memory, so the container idles at almost nothing between requests. Vikunja is a single Go binary at 110 MB, and SQLite is its default database, so one container is the entire stack. Planka needs 280 MB because it is always two containers: a Node server and PostgreSQL. Planka has no SQLite option, so the database is not negotiable.

Wekan sits at 750 MB because it is a Meteor application. Meteor holds a live query layer in Node memory and pushes every board change to every open browser over a WebSocket, so its memory grows with the number of connected people instead of staying flat. On a 1 GB VPS Wekan starts, then dies the first time a few people open a large board. The symptom is a container that disappears and comes back with exit code 137, which docker compose ps shows as a restart loop. Confirm it on the host with dmesg -T | grep -i "out of memory", because the kernel out-of-memory killer never tells the application anything.

Database dependency decides half of your backup work, so here it is in one line each. Planka requires PostgreSQL. Vikunja defaults to SQLite and also speaks PostgreSQL and MySQL or MariaDB. Kanboard defaults to SQLite and also speaks MySQL, MariaDB and PostgreSQL, and its documentation recommends PostgreSQL and warns against SQLite on NFS (network file system). Focalboard defaults to SQLite. Wekan speaks the MongoDB wire protocol, and its default Compose file now ships FerretDB v1 with an embedded SQLite backend instead of a real MongoDB server, with a separate MongoDB 7 Compose file if you want one.

Which of these projects are still maintained?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard is the outlier at 783 days. Its last standalone release, v8.0.0, is from June 2024. Mattermost moved board development into a plugin in a separate repository, and the standalone README says the repository is currently not maintained. That is the one clear "no" in this comparison. Everything else is a trade-off.

Planka's 109 days is healthy for a project that ships a few releases a year. Version 2.1.1 is from April 2026. Kanboard shipped v1.2.53 12 days before the check, and the two releases before it landed in March and April 2026.

Vikunja and Wekan both released within a day of the check, and you should read those two facts differently. Vikunja tagged v2.5.0 as an ordinary minor release. Wekan tagged v10.65, v10.66 and v10.67 on the same day, which is its normal cadence. Frequent releases do not mean a stable target. With Wekan you are choosing to track a fast-moving version number, so pin the tag and read the notes before every bump.

Do you get more than a board?

Most comparison posts stop at "it looks like Trello". This axis decides more than RAM does, because a board is a poor shape for anything with a deadline.

• Planka is a board tool and nothing else: projects, boards, lists, cards, labels, checklists, comments and attachments. Calendar and map views are Pro features as of August 2026.
• Vikunja gives four views over one set of tasks: List, Kanban, Table and Gantt. A task exists once, and you switch view instead of duplicating it.
• Kanboard is boards with work-in-progress limits, subtasks, attachments, comments, automatic actions and a small query language for filtering. Its own homepage says "The number of features is voluntarily limited", which is a fair description.
• Wekan is boards with swimlanes, plus checklists, custom fields, a REST (representational state transfer) API and webhooks.
• Focalboard offered board, table and calendar views over the same cards. It is listed here for completeness.

If what you actually want is a wiki with some task tracking attached, this is the wrong comparison. BookStack, Wiki.js and Outline covers that shape, and the self-hosted Notion alternatives cover the all-in-one workspace.

Multi-user access and single sign-on

Planka supports OpenID Connect in the free Community edition. The official Compose file carries the settings commented out, OIDC_ISSUER, OIDC_CLIENT_ID and OIDC_CLIENT_SECRET among them, so you uncomment rather than upgrade. Guest roles for people outside your organisation are a Pro feature.

Vikunja supports OpenID Connect with several providers at once. Set VIKUNJA_AUTH_OPENID_ENABLED=true, then add one block of VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* variables per provider. It also has teams and per-project sharing, which is what a twenty-person organisation actually needs.

Wekan supports LDAP (lightweight directory access protocol), OAuth2, OIDC and SAML. Kanboard has LDAP built in and a generic OAuth2 plugin for everything else, plus per-project roles and groups. Focalboard's standalone server has no single sign-on at all, which is a second reason to leave it out.

Any of these pairs with an Authentik identity provider you run yourself, which is usually a better answer than giving twenty people a separate password per app.

Can you import your Trello boards?

Planka has the simplest path. Export the board from Trello as JSON, create a board in Planka, click Import and choose Trello. Read the limits first, because they are real: users and attachments are not imported, only one checklist per card comes across, and Trello's default JSON export stops at 1,000 actions with no warning that it truncated. Check the file yourself before you trust the result.

Vikunja imports through Trello's OAuth flow, under Settings and then "Import from other services". Each migrator has to be enabled in the config before its icon appears, and VIKUNJA_SERVICE_PUBLICURL must be correct, because the OAuth redirect happens in your browser and not from the server. Vikunja also imports Todoist, Microsoft To Do, TickTick and Wekan.

Wekan accepts a pasted Trello board JSON in its import form. Kanboard has no built-in Trello importer, which is the main reason to skip it if you have years of Trello history to move.

What is the mobile experience like?

Vikunja is the only one of the five with official mobile apps. Android and iOS builds ship alongside each release, and the app repository describes itself as alpha, so treat it as a companion to the web interface rather than the main way in. Planka has no official app from the project, though its web interface is responsive and third-party clients exist. Wekan and Kanboard are web only, and Kanboard's interface is clearly built for a desktop screen.

The licence question, and why Planka is different

Planka is not open source any more, and this is the fact most comparisons leave out. It started under MIT, moved to AGPL-3.0 in 2023, and from the 2.0 series it ships under the PLANKA Community License, a fair-code licence held by PLANKA Software GmbH. GitHub reports its licence as "Other" because that licence is not OSI approved. Self-hosting it for your own people is free and explicitly permitted, covering personal, internal, non-profit and educational use. Reselling access to it, or running it as a service for other companies, needs a commercial licence.

For two people that is a fair deal. For a company it is a term to read before twenty people's work goes into it. The other four are ordinary open source: Vikunja is AGPL-3.0, Wekan and Kanboard are MIT, and Focalboard is a mix of Apache 2.0 and AGPL-3.0.

Pinned Compose files for the two picks

Pin the image tag. latest means the next docker compose pull can move you across a major version, and major versions run database migrations you cannot easily reverse. Both files below are the upstream ones with the tag fixed to a real release.

Vikunja on SQLite, one container:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

Create the data directory with the right owner first, because the container runs as UID 1000 and cannot write into a root-owned directory:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

A healthy stack shows the service as running, and the info endpoint returns JSON containing a version field. Connection refused here means the container exited. docker compose logs vikunja names the reason, and a permission error on the database file is the common one.

Planka on PostgreSQL, two containers:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust means PostgreSQL accepts any connection without a password. That is safe only because the database port is never published to the host, so the one thing that can reach it is the other container on the same Compose network. Do not add a ports: entry to the postgres service.

Neither stack should face the internet directly. Both bind to 127.0.0.1, so put a reverse proxy in front and terminate TLS (transport layer security) there. Traefik in front of several Compose apps is the usual way to do that once you host more than one thing, and the Docker Compose basics guide covers the parts of these files this page skips.

Your board is a database, so back it up

A board tool fails quietly. Nobody notices a missing backup until a volume is gone, and a damaged SQLite file will open normally and then report database disk image is malformed weeks later.

Never copy a live SQLite file with cp. The copy can catch a write in progress, so the archive looks complete and restores into a database that is missing rows. Stop the service for the few seconds the copy takes:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

For Planka, dump PostgreSQL instead of copying the data directory of a running cluster, and take the uploads volume separately, because attachments do not live in the database:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls prints the real volume name, which is your Compose project name followed by _data. Passing a name that does not exist creates an empty volume and gives you a valid but empty archive with no error, so check the size of the file afterwards.

Then restore it once, into a scratch stack on the same box, and open a card you remember. A backup you have never restored is a guess. Send the archives off the server too, because a copy stored on the VPS you are protecting is not a backup. restic backups from a VPS covers that half.

Two recommendations

Two people on a 2 GB VPS: run Planka. It is the closest thing to Trello in look and behaviour, the Trello import is a file you drag in, and 280 MB of idle memory leaves most of the 2 GB free for the reverse proxy and whatever else you host. The Community License covers a two-person internal team at no cost. If you would rather not depend on a source-available licence, Vikunja on SQLite at 110 MB is the open-source pick for the same box.

Twenty people in an organisation: run Vikunja on PostgreSQL. At that size you need OpenID Connect instead of twenty local passwords, you need teams and per-project sharing, and much of the work will not fit on a board, so the List, Table and Gantt views stop being a nice extra. AGPL-3.0 also means there is no licence conversation as headcount grows. Give it PostgreSQL rather than SQLite, put it behind a reverse proxy, and keep the daily dump somewhere other than that server.

If the box has less than 1 GB of RAM, neither answer applies. Take Kanboard at 70 MB, accept that you will retype your Trello cards, and spend the memory you saved on something else from the self-hosting shortlist for 2026. The deep install for whichever tool you pick belongs in its own guide. This page is only the choice.

FAQ

Which self-hosted Trello alternative uses the least RAM?

Kanboard, at roughly 70 MB idle, because it is PHP with SQLite and holds nothing in memory between requests. Vikunja is next at about 110 MB as a single Go binary. Wekan is the heavy one at about 750 MB, because Meteor keeps a live query layer in Node memory for every connected browser. Measure your own with docker stats once the stack is idle, since these are typical figures and not a promise.

Can I import my Trello boards into a self-hosted tool?

Planka and Wekan both take Trello's JSON board export directly. Vikunja imports over Trello's OAuth flow, and the migrator has to be enabled in the config before it appears in the interface. Kanboard has no built-in importer. Two limits to plan around: Planka does not import users or attachments and handles only one checklist per card, and Trello's default JSON export stops at 1,000 actions without warning you that it truncated.

Is Focalboard still a good choice in 2026?

No. The last standalone release, v8.0.0, is from June 2024, which was 783 days before this comparison was checked on 5 August 2026, and the README says the repository is currently not maintained. Mattermost continued board development only as a plugin in a separate repository, so the server you would self-host is the part that stopped. Choose Planka or Vikunja instead.

Is Planka still open source?

Not by the OSI definition. Planka was MIT, moved to AGPL-3.0 in 2023, and ships under the PLANKA Community License from version 2.0 onward. Self-hosting is free for personal, internal, non-profit and educational use. Reselling access or running it as a service for third parties needs a commercial licence, and calendar view, guest roles and recurring cards sit behind the Pro tier. If an OSI-approved licence is a hard requirement, Vikunja is AGPL-3.0 and Kanboard is MIT.

Do I need PostgreSQL, or is SQLite enough?

Vikunja, Kanboard and Focalboard default to SQLite, which is fine for a handful of people on one server. Planka requires PostgreSQL and offers no SQLite option. Move to PostgreSQL when you have several people writing at once, because SQLite serialises writes and a busy instance starts returning database is locked. Do not put a SQLite file on a network share either: Kanboard's documentation warns against SQLite on NFS for exactly this reason.