PlaneをDockerでセルフホスト｜Jira・Asana代替OSSはメモリ約1.1GB・初回起動約4分。日本語化とポート公開の注意点【2026年版】

2026-11-03

※2026年11月1日時点の情報です。弊社のサーバーで Plane v1.4.3（Community Edition）を動かして確認しています。設定項目や画面は版によって変わるため、最新の内容は公式ドキュメントでご確認ください。

Jira や Asana に代わる「自分のサーバーで動かせるプロジェクト管理ツール」を探すと、候補に入るのが Plane です。導入を判断するには、必要なメモリの量、起動までの待ち時間、画面が日本語になる範囲を把握しておきたいところでしょう。そこで弊社の検証サーバーに Docker で構築し、それぞれを確かめました。

結論：PlaneはDockerで初回起動に約4分・メモリ約1.07GB。日本語化は一部

• 初回起動では、up -d の実行開始から API の応答まで237秒（約4分）かかった。空のデータベースの準備（migrator）が完了するまで待つ必要がある。イメージの取得（60秒）は含めておらず、2回目以降の起動は未計測
• 起動後に増えたメモリは約1.07GB（1,071MB。タイトルの「約1.1GB」はこの値を丸めたもの）。稼働中のコンテナは12個で、ディスクの増分は約4.5GB だった
• 公式の compose では80番と443番がサーバーの全アドレスで開く。弊社では公開範囲を 127.0.0.1 に限定した
• 最初の管理者を作る場所は /god-mode/。利用状況の送信（テレメトリ）は既定でオンになっている。メールの確認は求められなかった
• 利用者の画面で言語を日本語にすると、メニューの多くが日本語に切り替わる。一方、管理画面は開いた範囲（General など）では英語のみで、状態名（Backlog など）も英語のまま
• タイムゾーンは既定で UTC になっている。日本で利用する場合は、最初に Asia/Tokyo へ変更する

検証で使用したのは、架空のテスト用アカウント（example.com のメールアドレス）と、Plane が自動作成するデモの作業項目だけです。実際の業務データは登録していません。

Planeとは：Jira・Asanaの代わりになるプロジェクト管理OSS

Plane は、作業項目（課題・タスク）やサイクル（スプリント）、モジュール、ページ（文書）を1つにまとめて扱うプロジェクト管理ツールです。公開先は GitHub の makeplane/plane です。

公式ドキュメントを読む際は、「Docker Compose」のページが冒頭で Commercial Edition の手順を紹介している点に注意が必要です。こちらは Free プラン（ワークスペースごとに12席）から利用でき、ライセンスキーによって有料機能が有効になります。Community Edition の手順は同じページの下のほうに掲載されている setup.sh 方式です。今回検証したのはこちらです。

PlaneをDockerでセルフホストする手順と実測値

検証には、さくらのクラウドの2コア・メモリ8GB・SSD 40GB（Ubuntu 22.04.5、Docker 29.8.2）を使用しました。測定中はほかのコンテナを停止しています。公式ドキュメントに記載された前提は、Commercial Edition の欄では CPU 2コア・メモリ 4GB（本番は 8GB 推奨）。Community Edition の欄では、AWS の EC2 を使う場合は t3.medium／t3a.medium 以上とされています（Docker Desktop を使う選択肢もあり）。今回のサーバーは、Commercial Edition の欄にある推奨にちょうど当たります。

公式の setup.sh では、対話式のメニューを通じて、v1.4.3 のリリースに添付された docker-compose.yml と variables.env を取得します。今回はこの2ファイルを直接取得して compose を書き換え、その後に起動しました（理由は次の節）。.env では、主に以下の値を変更しています。

APP_RELEASE=v1.4.3            # 既定は stable（動くタグ）。版を固定する
LISTEN_HTTP_PORT=19003        # 既定は 80
LISTEN_HTTPS_PORT=19443       # 既定は 443（使わないが空き番号へ）
WEB_URL=http://localhost:19003          # ポートまで書く
CORS_ALLOWED_ORIGINS=http://localhost:19003,http://127.0.0.1:19003
SECRET_KEY=（openssl rand -hex 32 で作った値）        # 既定は change-this-key-on-deployment
LIVE_SERVER_SECRET_KEY=（openssl rand -hex 32 で作った値）  # 既定は change-this-key-on-deployment
AWS_ACCESS_KEY_ID=（ランダムな値）       # 既定は access-key（ファイル置き場）
AWS_SECRET_ACCESS_KEY=（ランダムな値）   # 既定は secret-key
POSTGRES_PASSWORD=（ランダムな値）
DATABASE_URL=postgresql://plane:（同じ値）@plane-db:5432/plane
RABBITMQ_PASSWORD=（ランダムな値）
AMQP_URL=amqp://plane:（同じ値）@plane-mq:5672/plane

起動した直後に API が応答しないのは、api のコンテナがデータベースの準備（migrator）の完了を待っているためです。今回の待ち時間は約4分でした。起動が完了したかどうかは、/api/instances/ が200を返すことを基準に判断しています。この測定値は、空のデータベースを準備する時間も含めた初回の起動のもので、イメージの取得（60秒）は含めていません。2回目以降の起動時間は未計測です。

各コンテナのメモリは、以下の表にまとめました。最も大きな worker でも250MB に収まりますが、コンテナの数が多く、合計では1GB を超えます。api・worker・beat-worker の起動に使われるのは、いずれも plane-backend イメージです。なお、表は docker stats で確認したコンテナごとの値であり、その合計はサーバー全体の増分（1,071MB）とは一致しません。

ファイル置き場のイメージは、v1.4.3 で変更されています。リリースノートでは、Docker Hub から minio の組織が消えて取得できなくなったことを理由に、同梱のストレージを pgsty/silo（タグ固定）へ切り替えたと説明されています（サービス名は plane-minio のまま）。古い版の compose は使い回さないようにしてください。

Planeの公式composeで先に直したい3か所

公式の compose と variables.env（v1.4.3）では、次の3点が気になりました。

1つ目がポートの公開範囲です。前段の proxy のポートには host_ip が指定されていません。そのため、既定では80番と443番がサーバーのすべてのアドレスで開きます。弊社では proxy の2つのポートに以下の1行を加え、公開範囲を 127.0.0.1 に限定しました。

    ports:
      - target: 80
        published: ${LISTEN_HTTP_PORT:-80}
        host_ip: 127.0.0.1     # 追加
        protocol: tcp
        mode: host

Docker Compose の統合の規則では、ポートの「IP・コンテナ側・公開側・プロトコル」の組が異なると、追加として扱われます。compose.override.yaml に 127.0.0.1 付きのポートを記述しても、通常の統合では全アドレス側の設定が残るのはこのためです。ports: !override（Docker Compose 2.24.4 以降）による丸ごとの置き換えも可能ですが、公式 setup.sh は -f でファイルを指定して compose を呼び出すため、compose.override.yaml は読み込みません。こうした理由から、今回は公式ファイルを直接書き換えています。また、公式 setup.sh の Upgrade は compose を取得し直し、古いファイルを archive フォルダに移す仕組みです。したがって、更新のたびに host_ip を書き換え直す必要があります。

2つ目はパスワードの既定値です。variables.env の設定は POSTGRES_PASSWORD=plane、RABBITMQ_PASSWORD=plane で、DATABASE_URL= と AMQP_URL= は空になっています。空の場合は compose 側の既定値 postgresql://plane:plane@plane-db/plane が使われますが、この URL にはパスワード「plane」が直接記述されています。パスワードだけを変更しても URL 内の plane は変わらないため、URL にも同じパスワードを記述します。また、ファイル置き場の資格情報には、既定で access-key／secret-key が使われています。

3つ目に確認したいのが WEB_URL です。variables.env の設定は WEB_URL=http://${APP_DOMAIN}（APP_DOMAIN の既定は localhost）で、compose 側も既定は http://localhost となっています。公式ドキュメントでは、既定の http://localhost を、利用する FQDN に LISTEN_HTTP_PORT を付けた形に変更するよう案内しています。80番以外を使う場合は、ポート番号まで記述します。

このほかに、SECRET_KEY と、api と live で同じ値を使う LIVE_SERVER_SECRET_KEY も確認が必要です。variables.env では、どちらも既定値が change-this-key-on-deployment になっています。ファイル置き場の AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY（既定 access-key／secret-key）も含め、すべてランダムな値へ変更しました。

最初の管理者は/god-mode/で作る：テレメトリは既定でオン

起動後はブラウザで /god-mode/ にアクセスし、インスタンス全体を管理する管理者（Instance admin）を作成します。入力項目は名・姓・メールアドレス・会社名・パスワードです。パスワードには、「8文字以上・大文字・小文字・数字・記号を各1文字以上」という5つの条件が設けられています。

フォーム下部の「Allow Plane to anonymously collect usage events.」（匿名の利用状況の送信）には、あらかじめチェックが入っています。今回はチェックを外して送信しました。その後はすぐに管理画面へ移り、メールの確認は求められませんでした（SMTP は未設定）。

管理画面に並ぶのは、General・Email・Authentication・Workspaces・Artificial intelligence・Images in Plane の6項目です。開いて確認した範囲（General など）では、表示は英語のみでした。テレメトリの設定は、あとから General の画面でも切り替えられます。

招待メールを送るため、公式ドキュメントでは god-mode で早めに SMTP を設定することを勧めています。なお、今回メンバーの招待は試していません。

Planeの画面は日本語？ 既定は英語、切り替えても一部は英語

利用者の画面（/）へは、管理者と同じメールアドレスでログインしました（メール → パスワードの2段階）。その後はプロフィール、ワークスペースの作成（URL 用の名前と人数の選択が必須）、メンバーの招待（後回し可）の順に進みます。

ブラウザの言語設定は日本語でしたが、最初に表示された画面は英語でした。ホームに表示された「Sunday, Nov 1 13:54」は日本時間22時54分に当たり、9時間のずれがあります（タイムゾーンの既定が UTC）。ワークスペースの作成時には、作業項目7件を含むデモプロジェクトも自動で作成されました。

言語の変更は、設定 → 環境設定 → 言語から行います。選択肢は19言語あり、日本語に切り替えるとメニュー・ボタン・設定画面の多くが日本語で表示されました。日本で利用するなら、同じ画面にあるタイムゾーン（既定 UTC）も Asia/Tokyo に変更しておきます。

一方で、「Your Profile」「Developer」「First day of the week」、左側の「Projects」「More」、検索欄の「Search commands…」、一覧の見出しである「Work Items」などは、英語の表示が残りました。

作業項目の一覧でも、状態名（Backlog・Todo・In Progress・Done・Cancelled）は英語のままです。デモの作業項目の名前（「1. Create Projects」など）も英語でした。v1.4.3 のソースコードを見ると、状態名は state.py の DEFAULT_STATES に英語名で固定して記述されており、プロジェクトの作成時にその名前で作られます。自動作成されるデモプロジェクトの場合も、別の初期データ（states.json）から同じ英語名が作られます。いずれもプロジェクトのデータとして保存されるため、UI の言語を変更しても名前は変わりませんでした。公式ドキュメントによれば、プロジェクトの設定にある States からいつでも名前を変更（rename）できますが、今回は確認していません。

社内で導入する場合は、英語を読める人が管理画面を担当することに加え、状態名を日本語に付け直すかどうかも、あらかじめ決めておく必要があります。

Planeを使い始める前に決めたい設定

また、v1.4.3 のリリースノートには、アクセス制御の問題をまとめて修正したことに加え、セルフホストの環境は更新すべきだとの記載があります。構築後も定期的にリリースを確認する前提で、運用を計画してください。

まとめ：PlaneのセルフホストはメモリとUTC・英語の既定に注意

• Plane v1.4.3（Community Edition）は、コンテナ12個でメモリ増分約1.07GB（約1.1GB）。初回起動時は API の応答まで237秒（up -d の実行開始から）かかった
• 公式の compose では80・443が全アドレスで開く。127.0.0.1 に限定し、リバースプロキシを通じて公開する
• DB・キューのパスワードは URL とあわせて変更する。SECRET_KEY・LIVE_SERVER_SECRET_KEY・ファイル置き場の鍵にもランダムな値を使う
• 最初の管理者は /god-mode/ で作成する。テレメトリは既定でオンになっており、メール確認はなかった
• 日本語へ切り替えるとメニューの多くが日本語になる。管理画面（開いた範囲）と状態名は英語のままで、タイムゾーンの初期設定は UTC
• メンバーの招待（SMTP）、状態名の変更、バックアップと復元、多人数での運用は検証していない

OSSMatch では、Plane の概要と、Jira・Asana の代わりになるほかの OSS をまとめています。Jira・Asana の料金やプランは変わることがあるため、比較時には各社の公式サイトをご確認ください。

• Plane の詳細ページ
• Jira の代わりになるOSS一覧
• Asana の代わりになるOSS一覧

「タスク管理を自前のサーバーに移したい」「メモリ1GB 超の構成を載せるサーバーを決めたい」とお考えの方は、合同会社Edel Hearts のOSS導入支援へご相談ください。弊社で実際に構築した際に気づいた、ポートの公開範囲や日本語化の範囲に関する点も含め、率直にお伝えします。

出典

• GitHub makeplane/plane：Release v1.4.3（pgsty/silo への切り替え、セルフホストの更新の呼びかけ）（2026年11月2日確認）
• Plane v1.4.3 docker-compose.yml（ポートの書式、DATABASE_URL・AMQP_URL の既定値）（2026年11月2日確認）
• Plane v1.4.3 variables.env（パスワード・SECRET_KEY・LIVE_SERVER_SECRET_KEY・ファイル置き場の鍵・WEB_URL の既定値）（2026年11月2日確認）
• Plane v1.4.3 setup.sh（compose を -f で指定して呼び出す、Upgrade 時の compose の取得し直し）（2026年11月2日確認）
• Plane Docs：Docker Compose（Commercial／Community の手順、必要なリソース〈Commercial は 2コア・4GB、Community は t3.medium 以上〉、WEB_URL）（2026年11月2日確認）
• Docker Docs：Merge Compose files（ports の統合の規則、!override は Compose 2.24.4 以降）（2026年11月2日確認）
• Docker Docs：How-tos／Merge Compose files（既定で compose.override.yaml を読む、-f でファイルを指定）（2026年11月2日確認）
• Plane Docs：Instance admin and God mode（/god-mode、SMTP の設定、Authentication の「Allow anyone to sign up without an invite」）（2026年11月2日確認）
• GitHub makeplane/plane v1.4.3：instance_config_variables/core.py（ENABLE_SIGNUP の既定値）（2026年11月2日確認）
• GitHub makeplane/plane v1.4.3：db/models/state.py（DEFAULT_STATES の英語の状態名）（2026年11月2日確認）
• GitHub makeplane/plane v1.4.3：app/views/project/base.py（プロジェクト作成時に DEFAULT_STATES で状態を作る）（2026年11月2日確認）
• GitHub makeplane/plane v1.4.3：seeds/data/states.json（デモプロジェクトの状態名）（2026年11月2日確認）
• Plane Docs：Work Item States（プロジェクトの設定の States で名前を変更できる）（2026年11月2日確認）
• 実測値：2026年11月1日に、弊社の検証サーバー（さくらのクラウド、2コア・8GB・SSD 40GB、Ubuntu 22.04.5、Docker 29.8.2）で計測。測定時はほかのコンテナを停止。起動の秒数は、初回起動で up -d の実行を開始した時点から数えた値（イメージの取得は別）。メモリは、API の応答から60秒後に測ったサーバー全体の増分と、docker stats で確認したコンテナ別の値。公開ポートを 127.0.0.1 に限定し、画面は SSH トンネル経由で確認。使用したデータは架空のテスト用アカウントと、Plane が自動作成するデモプロジェクト