著者 セルフホスト型Trello代替5製品を比較
Planka、Vikunja、Focalboard、Wekan、Kanboardを比較します。RAMの下限、データベース、SSO、Trelloインポートに加え、現在も保守されている製品がわかります。
セルフホスト型のTrello代替製品はどれを選ぶべきですか？
セルフホスト型のTrello代替製品では、3つが有力です。Trelloと同じボード構成とインポートファイルが必要ならPlanka、チームでシングルサインオンとボード以上の機能が必要になったらVikunja、VPS（virtual private server）のリソースが少ない場合はKanboardを選びます。Focalboardで新しいプロジェクトを始めないでください。スタンドアロンサーバーは783日間リリースされておらず、現在のREADMEもメンテナーを募集しています。
Wekanは、ここで紹介する5個のツールの5番目です。動作しますが、他の製品を合わせた場合の数倍のメモリを消費します。以下に示す各バージョン、ライセンス、日付は、2026年8月5日に確認済みです。
各ボードツールに必要な RAM はどのくらいですか？
The data behind this chart
[
{
"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
}
]これらは、インストール直後で利用者がいない状態における、一般的なアイドル時の値です。スタックの起動後 1 分ほどで docker stats が報告するような値です。プランの容量を決める際の目安にし、最終的には自分の環境でも測定してください。正確なメガバイト数より、増え方の傾向が重要です。
Kanboard は PHP と SQLite で構成されるため、70 MB が下限です。長時間実行されるアプリケーションプロセスがボードをメモリ上に保持しないため、リクエストの合間はコンテナがほとんどメモリを使用しません。Vikunja は 110 MB の単一の Go バイナリです。デフォルトのデータベースも SQLite なので、1 個のコンテナだけでスタック全体を構成できます。Planka には Node サーバーと PostgreSQL の 2 個のコンテナが常に必要なため、280 MB が必要です。Planka には SQLite の選択肢がないため、データベースを変更して容量を減らすことはできません。
Wekan は Meteor アプリケーションであるため、750 MB を使用します。Meteor は Node のメモリ上にライブクエリ層を保持し、WebSocket を通じて開いているすべてのブラウザーへボードの変更を送信します。そのため、メモリ使用量は一定ではなく、接続しているユーザー数に応じて増加します。1 GB の VPS では Wekan は起動しますが、数人が大きなボードを開いた時点で停止することがあります。症状として、コンテナが消えてから exit code 137 で再起動します。この状態は docker compose ps で再起動ループとして確認できます。アプリケーションには通知されないため、ホスト上で dmesg -T | grep -i "out of memory" を実行して確認してください。これはカーネルの out-of-memory killer によるものです。
データベースの依存関係によって、バックアップ作業の半分が決まります。各ツールについて 1 行でまとめます。Planka には PostgreSQL が必要です。Vikunja はデフォルトで SQLite を使用し、PostgreSQL と MySQL または MariaDB にも対応します。Kanboard はデフォルトで SQLite を使用し、MySQL、MariaDB、PostgreSQL にも対応します。ドキュメントでは PostgreSQL を推奨し、NFS（network file system）上での SQLite の使用を避けるよう警告しています。Focalboard のデフォルトは SQLite です。Wekan は MongoDB wire protocol に対応しています。現在のデフォルトの Compose ファイルでは、実際の MongoDB サーバーの代わりに、組み込みの SQLite バックエンドを使用する FerretDB v1 が提供されます。MongoDB 7 を使用する場合は、別の MongoDB 7 Compose ファイルがあります。
これらのプロジェクトは、現在も保守されていますか？
The data behind this chart
[
{
"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 は、783 日という点で例外です。単体版の最後のリリースである v8.0.0 は、2024 年 6 月です。Mattermost はボード機能の開発を別リポジトリの plugin に移しており、単体版の README には、現在このリポジトリを保守していないと記載されています。この比較で明確に「いいえ」と言えるのは Focalboard です。それ以外は、トレードオフの判断になります。
Planka の 109 日という値は、年間数回のリリースを行うプロジェクトとしては健全です。Version 2.1.1 は 2026 年 4 月のリリースです。Kanboard は確認の 12 日前に v1.2.53 をリリースしており、その前の 2 つのリリースも 2026 年 3 月と 4 月に行われています。
Vikunja と Wekan は、どちらも確認から 1 日以内にリリースされています。ただし、この 2 つの事実は異なる意味で捉える必要があります。Vikunja は v2.5.0 を通常のマイナーリリースとしてタグ付けしました。Wekan は同じ日に v10.65、v10.66、v10.67 をタグ付けしており、これが通常のリリース頻度です。リリース頻度が高いからといって、安定した採用対象になるとは限りません。Wekan では、変化の速いバージョン番号を追跡することになります。そのため、タグを固定し、更新する前に毎回リリースノートを確認してください。
ボード以外の機能もありますか？
多くの比較記事は「Trello に似ている」と述べるだけです。しかし、締め切りのある作業ではボードは扱いにくいため、この観点は RAM 容量よりも重要です。
- Planka はボード専用のツールです。プロジェクト、ボード、リスト、カード、ラベル、チェックリスト、コメント、添付ファイルを利用できます。2026 年 8 月時点では、カレンダー表示とマップ表示は Pro 機能です。
- Vikunja では、1 つのタスク集合を List、Kanban、Table、Gantt の 4 種類のビューで表示できます。タスクは 1 回だけ作成し、複製する代わりにビューを切り替えます。
- Kanboard は、進行中の作業数の制限、サブタスク、添付ファイル、コメント、自動アクション、小規模なフィルタリング用クエリ言語を備えたボードツールです。公式ホームページには「機能数は意図的に制限されています」とあり、実態を適切に表しています。
- Wekan はスイムレーン付きのボードに加え、チェックリスト、カスタムフィールド、REST (representational state transfer) API、webhook を備えています。
- Focalboard では、同じカードを対象にボード、テーブル、カレンダーのビューを利用できました。ここでは網羅性のために掲載しています。
実際に必要なのが、タスク管理機能を一部備えた wiki であれば、この比較は適切ではありません。BookStack、Wiki.js、Outline ではその構成を扱い、self-hosted の Notion 代替製品 ではオールインワンのワークスペースを扱います。
複数ユーザーのアクセスとシングルサインオン
Planka は、無料の Community エディションで OpenID Connect をサポートしています。公式の Compose ファイルには設定がコメントアウトされた状態で含まれており、OIDC_ISSUER、OIDC_CLIENT_ID、OIDC_CLIENT_SECRET もその中に含まれます。そのため、アップグレードではなくコメントを外して使用できます。組織外のユーザー向けのゲストロールは Pro の機能です。
Vikunja は、複数のプロバイダーによる OpenID Connect を同時にサポートしています。VIKUNJA_AUTH_OPENID_ENABLED=true を設定し、プロバイダーごとに VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* 変数のブロックを1つ追加します。チームとプロジェクト単位の共有機能も備えており、20人規模の組織に実際に必要な機能を利用できます。
Wekan は LDAP（lightweight directory access protocol）、OAuth2、OIDC、SAML をサポートしています。Kanboard には LDAP が組み込まれており、それ以外の用途には汎用 OAuth2 プラグインを使用できます。プロジェクト単位のロールとグループにも対応しています。Focalboard のスタンドアロンサーバーにはシングルサインオンがまったくなく、これも候補から外す2つ目の理由です。
これらはいずれも、自分で運用する Authentik identity provider と組み合わせられます。通常は、20人のユーザーにアプリごとの個別パスワードを持たせるよりも適した方法です。
Trello のボードをインポートできますか？
Planka が最も簡単です。Trello からボードを JSON としてエクスポートし、Planka でボードを作成して、Import をクリックし、Trello を選択します。まず制限を確認してください。実際に制限があります。ユーザーと添付ファイルはインポートされず、各カードから移行できるチェックリストは 1 つだけです。また、Trello のデフォルトの JSON エクスポートは 1,000 件のアクションで停止しますが、切り詰めたことを警告しません。結果を信頼する前に、ファイルを自分で確認してください。
Vikunja では、Settings、続いて「他のサービスからインポート」を選択し、Trello の OAuth フローを通じてインポートします。各マイグレーターは、アイコンが表示される前に設定で有効にする必要があります。また、VIKUNJA_SERVICE_PUBLICURL が正しく設定されていなければなりません。OAuth のリダイレクトはサーバーではなく、ブラウザーで実行されるためです。Vikunja は Todoist、Microsoft To Do、TickTick、Wekan からもインポートできます。
Wekan は、インポート画面に Trello のボード JSON を貼り付けることで受け付けます。Kanboard には Trello の組み込みインポーターがありません。Trello を何年も利用してきた場合に、移行先として Kanboard を避ける主な理由です。
モバイルでの使い勝手はどうですか？
Vikunja は、5 つの中で公式モバイルアプリがある唯一の製品です。Android 版と iOS 版は各リリースと同時に公開されますが、アプリのリポジトリでは alpha と説明されています。そのため、Web インターフェースへの主要なアクセス手段ではなく、補助的なクライアントとして扱ってください。Planka にはプロジェクト公式アプリがありません。ただし、Web インターフェースはレスポンシブ対応で、サードパーティー製クライアントも存在します。Wekan と Kanboard は Web のみで、Kanboard のインターフェースは明らかにデスクトップ画面向けに設計されています。
ライセンスに関する注意点と、Planka が異なる理由
Planka は現在、オープンソースではありません。これは、比較記事の多くが省略している点です。Planka は当初 MIT で提供され、2023 年に AGPL-3.0 へ移行しました。2.0 系列からは、PLANKA Software GmbH が保有する fair-code ライセンスである PLANKA Community License でリリースされています。GitHub がライセンスを「Other」と表示するのは、このライセンスが OSI の承認を受けていないためです。自社の利用者向けにセルフホストする場合は無料で、個人利用、社内利用、非営利利用、教育利用が明示的に許可されています。他社向けにアクセスを再販したり、他社向けのサービスとして運用したりする場合は、商用ライセンスが必要です。
2 人で利用する場合、この条件は妥当です。ただし企業で利用する場合は、20 人分の作業を移行する前に確認すべき条件です。残る 4 製品は通常のオープンソースです。Vikunja は AGPL-3.0、Wekan と Kanboard は MIT、Focalboard は Apache 2.0 と AGPL-3.0 の組み合わせです。
2 つの候補用に固定した Compose ファイル
イメージタグを固定してください。latestでは、次の docker compose pull によってメジャーバージョンをまたぐ可能性があり、メジャーバージョンでは簡単に元へ戻せないデータベースマイグレーションが実行されます。以下の 2 つのファイルは、タグを実際のリリースに固定した upstream 版です。
SQLite を使用する Vikunja、1 コンテナ構成:
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コンテナは UID 1000 で実行され、root が所有するディレクトリには書き込めません。そのため、最初に適切な所有者でデータディレクトリを作成します。
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正常なスタックでは、サービスが running と表示され、info エンドポイントは version フィールドを含む JSON を返します。ここで connection refused になる場合、コンテナは終了しています。docker compose logs vikunja で原因を確認できます。データベースファイルの権限エラーが一般的な原因です。
PostgreSQL を使用する Planka、2 コンテナ構成:
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 は、PostgreSQL がパスワードなしのすべての接続を受け入れる設定です。データベースポートをホストに公開していないため、この設定が安全なのは、同じ Compose ネットワーク上にあるもう一方のコンテナだけが接続できるからです。postgres サービスに ports: のエントリを追加しないでください。
どちらのスタックも、インターネットに直接公開しないでください。両方とも 127.0.0.1 に bind するため、前段に reverse proxy を置き、そこで TLS (transport layer security) を終端します。複数の Compose アプリをホストする場合は、通常 複数の Compose アプリの前段に Traefik を置く方法 で構成します。Docker Compose の基本ガイドでは、このページで省略したファイルの各要素を説明しています。
ボードはデータベースです。バックアップを取得してください
ボードツールは何も表示せずに失敗することがあります。ボリュームが失われるまで、バックアップがないことに気付かない場合があります。また、破損した SQLite ファイルは正常に開けても、database disk image is malformed 週間後にエラーを報告することがあります。
実行中の SQLite ファイルを cp でコピーしないでください。書き込み中の状態をコピーする可能性があるため、アーカイブは完全に見えても、復元すると行が欠落したデータベースになることがあります。コピーに必要な数秒間だけサービスを停止します。
docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunjaPlanka では、実行中の PostgreSQL クラスターのデータディレクトリをコピーせず、PostgreSQL のダンプを取得してください。添付ファイルはデータベースに保存されないため、uploads ボリュームも別途バックアップします。
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 は実際のボリューム名を表示します。これは Compose プロジェクト名に _data を続けた名前です。存在しない名前を渡すと、空のボリュームが作成され、エラーなしで有効な空アーカイブが生成されます。そのため、後でファイルサイズを確認してください。
次に、同じホスト上の一時的なスタックへ一度復元し、覚えているカードを開いて確認します。一度も復元していないバックアップは推測にすぎません。アーカイブはサーバーの外部にも送信してください。保護対象の VPS に保存したコピーはバックアップではありません。VPS からの restic バックアップでその方法を説明しています。
2 つの推奨構成
2 GB の VPS を 2 人で使用する場合は、Planka を実行します。外観と操作性が Trello に最も近く、Trello のインポートもファイルをドラッグするだけで行えます。アイドル時のメモリ使用量は 280 MB なので、2 GB の大部分をリバースプロキシや同じサーバー上の他のサービスに割り当てられます。Community License により、2 人の社内チームであれば無償で利用できます。source-available ライセンスへの依存を避けたい場合は、110 MB の SQLite 上で動作する Vikunja が同じサーバーでのオープンソースの選択肢です。
組織で 20 人が使用する場合は、Vikunja を PostgreSQL 上で実行します。この規模では、20 個のローカルパスワードではなく OpenID Connect が必要です。チーム機能とプロジェクト単位の共有も必要になります。また、作業の多くはボードに収まらないため、List、Table、Gantt ビューは単なる追加機能ではありません。AGPL-3.0 であれば、利用者が増えてもライセンスに関する確認が不要です。SQLite ではなく PostgreSQL を使用し、リバースプロキシの背後に配置します。毎日のダンプはそのサーバー以外の場所に保存してください。
サーバーの RAM が 1 GB 未満の場合、どちらの選択肢も適用できません。70 MB の Kanboard を使用し、Trello のカードは再入力する必要があると割り切ります。節約したメモリは、2026 年のセルフホスティング候補一覧にある別の用途に回してください。選択したツールの詳細なインストール手順は、専用のガイドで扱います。このページの内容は選択だけです。
FAQ
RAMの使用量が最も少ないセルフホスト型Trello代替製品はどれですか？
アイドル時のメモリ使用量が約 70 MB のKanboardです。PHPとSQLiteを使用し、リクエスト間にメモリ上へデータを保持しないためです。次に少ないのは、単一のGoバイナリとして動作し、約 110 MBのVikunjaです。最も重いのは約 750 MBのWekanです。接続中の各ブラウザに対して、MeteorがNodeのメモリ内にライブクエリ層を保持するためです。これらは一般的な値であり、保証値ではありません。スタックがアイドル状態になったら、docker stats を使って実環境の値を測定してください。
Trelloのボードをセルフホスト型ツールへインポートできますか？
PlankaとWekanは、TrelloのJSONボードエクスポートを直接取り込めます。VikunjaはTrelloのOAuthフロー経由でインポートします。インターフェースに表示するには、事前に設定でマイグレーターを有効にする必要があります。Kanboardには組み込みのインポーターがありません。次の2点を考慮してください。Plankaはユーザーと添付ファイルをインポートせず、カードごとに1つのチェックリストしか扱えません。また、TrelloのデフォルトJSONエクスポートは、切り捨てたことを警告せずに1,000件のアクションで停止します。
Focalboardは2026年でも適切な選択肢ですか？
いいえ。最後のスタンドアロンリリースであるv8.0.0は2024年6月のもので、2026年8月5日にこの比較を確認した時点で 783 日前です。READMEには、リポジトリが現在メンテナンスされていないと記載されています。Mattermostは別のリポジトリにあるプラグインとしてのみボード開発を継続しました。そのため、セルフホストするサーバー側の部分は開発が停止しています。代わりにPlankaまたはVikunjaを選択してください。
Plankaは現在もオープンソースですか？
OSIの定義では、オープンソースではありません。PlankaはMITでしたが、2023年にAGPL-3.0へ移行し、バージョン2.0以降はPLANKA Community Licenseでリリースされています。個人利用、社内利用、非営利利用、教育利用でのセルフホスティングは無料です。アクセスの再販売や、第三者向けサービスとしての運用には商用ライセンスが必要です。また、カレンダービュー、ゲストロール、繰り返しカードはProティアに含まれます。OSI承認ライセンスが必須であれば、VikunjaはAGPL-3.0、KanboardはMITです。
PostgreSQLは必要ですか。それともSQLiteで十分ですか？
Vikunja、Kanboard、FocalboardはSQLiteをデフォルトで使用します。1台のサーバーで少人数が利用する場合は、これで十分です。PlankaにはPostgreSQLが必須で、SQLiteの選択肢はありません。同時に複数人が書き込むようになったらPostgreSQLへ移行してください。SQLiteは書き込みを直列化するため、負荷の高いインスタンスでは database is locked が返され始めます。SQLiteファイルをネットワーク共有に置くことも避けてください。Kanboardのドキュメントは、まさにこの理由からNFS上でのSQLite使用を推奨していません。