VPSのCloudron・CasaOS・Coolifyを比較

構築するもの

ツールはインストールするだけでなく、選択するものでもあります。素の VPS をポイントアンドクリックで操作できるアプリホストに変えると謳うパネルは、Cloudron、CasaOS、Coolify の3つです。このガイドでは、同じ新規の Ubuntu 24.04 環境にそれぞれをインストールし、最初のアプリを導入します。そのうえで、スクリーンショットでは語られない TLS、バックアップ、更新、メモリ使用量、そして離脱の難しさを詳しく確認します。最後まで読めば、どれが自分に合うのか、あるいは「どれも使わず、Docker Compose を使う」という正直な答えにたどり着けます。

どれも魔法ではありません。3つとも、その下では手動で操作できるものと同じ Docker Engine を使用しています。パネルが料金、RAM、またはロックインという形で提供するのは、次の4つの作業を代行することです。ワンクリックでのアプリインストール、自動 TLS 証明書、スケジュール済みバックアップ、ユーザー管理。この4つに実際のオーバーヘッドを払う価値があるなら、パネルを導入する意味があります。1つか2つのサービスだけを運用し、サーバー上で何が動いているかを正確に把握したい場合は、まず「3つとも使わない」セクションを読んで、余計な手間を省いてください。

共通の前提条件と、事前に把握しておくべき注意点

3 つとも、コンテナ仮想化ではなく KVM VPS を前提としています。Docker には実カーネルが必要で、Cloudron は OpenVZ と LXC を明確にサポートしていません。systemd-detect-virt で確認できます。kvm または qemu なら問題ありませんが、openvz または lxc なら使用できません。KVM プランではコマンドの出力が kvm になり、ベアメタルでは none になります。どちらも続行できます。

それ以外の要件は異なります。これが選択を左右する最初のポイントです。

• RAM。 CasaOS は 1GB で問題なく動作します。Raspberry Pi のハードウェア向けに発展してきたため、軽量です。Coolify は最低 2GB と 2 個の CPU コアを必要とし、そのうち約 600 MB を Coolify 自体が使用します。Cloudron は最低 2GB を必要とし、4GB の方が明らかに快適です。アプリを 1 つもインストールしていない状態でも、メールサーバーとデータベースを実行するためです。
• 管理できるドメインと DNS。 Cloudron と Coolify には、正常に動作する DNS を設定した実ドメインが必要です。Cloudron では、DNS プロバイダーの API にアクセスできることが理想的です。これにより、Cloudron がレコードとワイルドカード証明書を自動作成できます。CasaOS は IP アドレスだけでも動作しますが、その場合は TLS を利用できません。
• ポート。 Cloudron と Coolify では、HTTP と HTTPS 用に 80 と 443 を開放する必要があります。CasaOS はダッシュボードを平文 HTTP で提供するため、必要なのは port 80 だけです。Coolify はさらにダッシュボードを 8000 で提供し、リアルタイム通信に 6001、ブラウザー内ターミナルに 6002 を使用します。3 つとも SSH 用に port 22 を開放してください。

開始前に、DNS をサーバーに向けてください。自分のホスト名を名前解決できないパネルは証明書を要求できません。そのため、ソフトウェアではなく DNS の問題を最初の 1 時間かけて調べることになります。A レコードをサーバーの IP アドレスに向けます。Coolify では、デプロイした各アプリに独自のサブドメインを割り当てられるよう、ワイルドカードレコード（*.apps.example.com）も追加します。

Cloudron: 洗練された独自仕様のアプライアンス

概要。 Cloudron は、サーバー全体を管理対象のアプライアンスに変える商用プラットフォームです。独自のリバースプロキシ、データベース、メールスタックに加え、パッケージ化されたアプリの厳選 App Store（Nextcloud、WordPress、Gitea、Mattermost など）を提供します。アプリを自動更新し、証明書とバックアップも自動で管理してほしい人を対象としています。その対価を支払うことが前提です。

インストール。 クリーンなサーバーを要求し、サーバー全体を完全に管理下に置きます。新規の Ubuntu 24.04 (Noble) サーバーで、次のコマンド以外は何も実行しないでください。

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

このスクリプトは Docker、nginx、データベース、メールスタックをインストールしてから再起動します。サーバーが戻ったら https://<your-ip> を開き、一時的な自己署名証明書を受け入れ、ブラウザーでセットアップを完了します。ドメインを指定し、DNS プロバイダーを選択すると、Cloudron は my.example.com に独自のダッシュボードを用意します。

最初のアプリを追加する。 ダッシュボードで App Store を開き、例えば Nextcloud をクリックし、サブドメイン files.example.com を選択して Install を押します。Cloudron は DNS レコードを作成し、Let's Encrypt 証明書を要求し、データベースを用意し、シングルサインオンを接続し、バックアップをスケジュールします。これらはすべて、設定ファイルに触れずに実行されます。これが Cloudron の中核となる価値であり、実際にそのとおりに動作します。

TLS とバックアップ。 3 つの中で最も強力です。各アプリのサブドメインに Let's Encrypt 証明書が自動で割り当てられ、更新も自動で行われます。バックアップはスケジュールされ、機能として組み込まれています。保存先にはローカルディレクトリ、S3、その他のリモートストレージを指定でき、アプリ単位のリストアや、新しいサブドメインへのワンクリック複製にも対応します。

料金とライセンス。契約前に確認してください。 Cloudron は無料枠に上限がある有料製品です。無料プランで利用できるアプリは2 個です。3 個目のアプリをインストールすると、支払いが必要になります。有料サブスクリプション（Pro または Max。月払いと年払いがあり、どちらもアプリ数は無制限）にすると、追加機能が利用できます。これが Cloudron について最も重要な事実です。Cloudron が洗練されているのはビジネスとして提供されているからであり、無料枠は成長するアプリ構成の基盤というより、長期化された試用版に近いものです。

失敗例、クリーンなサーバーが必要な理由。 既存のサービスが動作しているサーバーに Cloudron をインストールしようとすると、何も変更しないままセットアップが中止されます。

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of its installation.
Please start with a fresh Ubuntu install and run this script again.

これは単なる過剰な制約ではありません。Cloudron は nginx、Docker、Node の特定バージョンを固定し、それらを深く統合します。そのため、独自にインストールした同じソフトウェアとは共存できません。対処方法は、新規の Ubuntu 24.04 イメージだけを使用することです。Web サーバー、Docker、手動で設定したファイアウォールも用意しないでください。誤ったイメージを起動した場合も、サポート対象の Ubuntu LTS（22.04、24.04、26.04）以外は拒否されます。x86-64 以外、ARM、LXC、OpenVZ はサポート対象外です。Cloudron 10 以降（2026 年 9 月）は、新規インストールのデフォルトが Ubuntu 26.04 です。そのため、現在ゼロから始める場合はこのイメージを選択してください。

2 つ目の失敗例、ワイルドカード証明書には DNS API が必要。 セットアップ中に API token を Cloudron に渡さず、DNS オプションで "Manual" を選択すると、Cloudron は DNS レコードやワイルドカード証明書を作成できません。新しいアプリを追加するたびに、証明書を発行する前に DNS レコードを手動で追加する必要があり、ダッシュボードはそのレコードを待機します。サポート対象の DNS プロバイダー（Cloudflare、Route 53、DigitalOcean など）への API アクセスを Cloudron に付与すれば、この処理全体を 1 回のクリックで完了できます。

CasaOS: 無料のホームラボ用ダッシュボード

概要。 IceWhale が提供する CasaOS は、Docker の上に構築される無料のオープンソースダッシュボードです。ホーム画面、アプリストア、ファイルマネージャーを利用できます。ホームサーバーの用途から発展したため、ホームラボ向けの設計です。セットアップが速く、UI が使いやすく、複雑な運用を必要としません。費用をかけずに Docker を扱いやすい画面で管理したいユーザーを対象としています。

インストール。 1 行で実行でき、初期状態のサーバーを要求しません。

curl -fsSL https://get.casaos.io | sudo bash

インストーラーは、複数の systemd サービス（casaos、casaos-gateway、casaos-app-management など）を追加します。ブラウザーを開く前に、ゲートウェイが起動したことを確認してください。

systemctl status casaos-gateway

起動すると、ダッシュボードは http://<your-ip> で利用できます（暗号化されていない HTTP、port 80）。ローカルアカウントを作成すれば利用を開始できます。

最初のアプリを追加する。 App Store を開き、アプリを選択して Install をクリックします。CasaOS は内部で Docker Compose プロジェクトを作成し、たとえば http://<your-ip>:8080 のようにホストの port でアプリを公開します。ストアには一般的なホームサーバー向けアプリがそろっているため、VPS 上の Jellyfin メディアサーバーや セルフホスト型 Immich フォトライブラリも数回のクリックで導入できます。まだフォトサーバーを決めていない場合は、PhotoPrism と Immich を分ける RAM の最低要件とスマートフォンアプリを先に読むとよいでしょう。1GB の CasaOS 環境では、その選択によってアプリが起動できるかどうかが決まるためです。任意の docker-compose.yaml をインポートすることもできます。これが CasaOS の本当の強みです。アプリは独自形式ではなく、通常のコンテナとして動作します。

TLS とバックアップの弱点。 「無料」の限界が表れるのはここです。CasaOS はデフォルトで、独自のダッシュボードを含むすべての通信を 暗号化されていない HTTP で提供します。組み込みの Let's Encrypt 機能はなく、定期バックアップ機能もありません。データは /DATA 配下の Docker volume に保存され、バックアップは自分で実施する必要があります（cron で実行する restic または tar）。

障害時の状態、TLS なしでもエラーにならない。 エラーは表示されません。アプリをインストールして http://<your-ip>:8080 を開けば、ブラウザーに 「安全ではありません」 と表示される暗号化されていない接続で動作します。パスワードとセッション Cookie は平文でネットワーク上を送信されます。さらに、CasaOS のダッシュボードでは実際にリモートコード実行の脆弱性が発見されています（CVE-2023-37265 と CVE-2023-37266。認証バイパスを経てホスト全体の侵害につながる脆弱性です）。そのため、この HTTP port をインターネットへ直接公開することは、単なる好みの問題ではなく、現実的なリスクです。対策として、CasaOS を直接公開しないでください。Certbot で Let's Encrypt 証明書を取得する nginx、Caddy、Cloudflare Tunnel など、TLS 終端を担うリバースプロキシを前段に置き、ローカルネットワーク内の CasaOS へ転送します。CasaOS はすでに port 80 をバインドしているため、先に CasaOS を別の port へ移さないと、プロキシと CasaOS が port を奪い合うことに注意してください。

コスト。 完全に無料で、アプリ数の上限もありません。代わりに、TLS、バックアップ、ハードニングは自分で管理する必要があります。

Coolify: セルフホスト型 PaaS

概要。 Coolify は、Heroku や Vercel のような機能を自分のサーバーで提供する、オープンソースのセルフホスト型 platform-as-a-service です。基本単位は「パッケージ化されたアプリをインストールすること」ではなく、「Git repository をデプロイすること」です。repository を接続すると、Coolify は Nixpacks または独自の Dockerfile を使ってビルドし、デプロイします。push のたびに再デプロイすることもできます。ワンクリックで利用できるデータベースやサービスもあります。自分のコードをデプロイし、PaaS を借りずに push-to-deploy を実現したい開発者を対象としています。

インストール。

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

このスクリプトは Docker をインストールし、Coolify 自身のコンテナスタックを起動します。先に進む前に、コンテナが正常な状態か確認してください。

docker ps --format 'table {{.Names}}\t{{.Status}}'

coolify、coolify-db、coolify-redis、coolify-realtime、coolify-proxy がすべて Up と報告されることを確認します。ダッシュボードは http://<your-ip>:8000 にあります。すぐに admin account を作成してください。最初の account が作成されるまで registration page が公開されており、最初にアクセスした人がサーバーを制御できるためです。次に instance domain を設定し、wildcard DNS record（*.example.com または *.apps.example.com）をサーバーに向けます。これにより、Coolify はデプロイした各アプリに専用の subdomain を割り当てられます。

最初のアプリを追加する。 Git source（GitHub、GitLab、または通常の repo URL）を接続し、branch と domain を選択してデプロイします。Coolify に組み込まれた Traefik proxy が subdomain をルーティングし、証明書を要求します。既製のソフトウェアは、Services catalogue から数回のクリックでデプロイできます。手作業で構築することもある n8n workflow-automation stack も、status-page monitoring 用の Uptime Kuma も、カタログの項目です。

TLS とバックアップ。 組み込みの Traefik を通じて、アプリごとに Let's Encrypt の証明書を自動取得します。デプロイした各 subdomain に証明書が付与されます。バックアップはデータベースを優先します。Postgres と MySQL の dump を S3-compatible storage に定期保存できます。インスタンス全体のバックアップ（/data/coolify 以下に保存される Coolify configuration 自体）は手動作業が多いため、自分で export して保存してください。

コストとライセンス。 セルフホスト版は完全にオープンソースで無料で、アプリ数の上限もありません。任意で Coolify Cloud（有料）も利用できます。これは control plane を代わりにホストしますが、アプリは引き続き自分のサーバーで実行します。便利ですが、必須ではありません。

障害例: アプリはデプロイされるが、domain で読み込めない。 ダッシュボードは http://<ip>:8000 で正常に動作し、build も成功しているのに、アプリ固有の URL が connection error または Traefik の 404 page not found を返す場合があります。この場合、原因はアプリではなく proxy または DNS にある可能性があります。よくある原因は2つです。1つ目は、proxy が起動しようとした時点で port 80 または 443 がすでに使用されていた場合です。その結果、container が次の Docker error で停止します。

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

2つ目は、hostname がサーバーに解決されない場合です。アプリが wildcard で生成された subdomain を使っているのに wildcard DNS record がないか、custom domain にサーバーを指す独自の DNS record がない可能性があります。この場合、Traefik はその hostname 宛ての request を受信できません。Coolify の server card 全体に "Server is not reachable" と表示される場合は、別の障害です。Coolify がサーバーの Docker socket と通信できていません。通常は Docker daemon が停止しているか、SSH key が壊れています。推測で判断する前に、ログで実際の理由を確認してください。

docker logs coolify-proxy --tail 100

Proxy page から修正します。Restart Proxy を押すか、proxy configuration を default に戻して再起動し、安定するまで約2分待ちます。port 8000 は自分の IP からのみ到達可能にしてください。proxy に問題がある場合だけ一時的に再開し、インターネット全体には公開しないでください。この port は plain HTTP でダッシュボードを提供します。Coolify の公式ドキュメントでも、ダッシュボードを独自の domain 経由で提供する場合は、port 8000、6001、6002 を閉じられると説明されています。

同じ VPS でのリソース消費

実際のワークロードをデプロイする前に、同じ 4GB のサーバーでアイドル時の消費量を測定しました。単一の数値だけを信用せず、free -m と docker stats --no-stream で自分の環境も確認してください。合計値はアプリの構成によって変動します。

• CasaOS が最も軽量です。パネルは少数の Go サービスで構成されており、実行するコンテナとは別に、オーバーヘッドとしておよそ 150 から 300 MB を見込んでください。
• Coolify は、アプリ、Postgres、Redis、realtime サービス、Traefik など複数のサポート用コンテナを実行します。そのため、何もデプロイしていないアイドル時でも、およそ 600 MB から 1 GB を消費します。
• Cloudron は、停止状態で最も多くのリソースを消費します。使用しているかどうかに関係なく、独自の nginx、データベース、メールスタック、監視機能を実行するためです。アイドル時に 1 から 1.5 GB を見込んでください。そのため、最小要件は 2GB で、4GB なら余裕を持って運用できます。

小規模な 2GB VPS では、実際のアプリ用に最も多くの余裕が残るのは CasaOS で、最も少ないのは Cloudron です。2GB のプランで、メールサーバーを実行する Cloudron を使う場合は、サーバーのアップグレードを計画してください。

更新、バックアップ、ロックインの比較

更新。 Cloudron は、検証済みのスケジュールに従ってプラットフォームとすべてのアプリを更新します。手間が最も少なく、案内も最も充実しています。Coolify は、専用ダッシュボードからボタン1つで自身を更新できます。CasaOS は、インストールスクリプトまたは apt を使ってパネルを更新します。ただし、インストールしたアプリの取得と再起動は自分で行う必要があります。

2年目に問題になりやすいロックイン。 CasaOS は最もロックインが少ない選択肢です。アプリは通常の Compose プロジェクトなので、docker-compose.yaml と /DATA 配下のボリュームを別のホストへコピーして、そのまま移行できます。Coolify は中間的な位置付けです。デプロイには自分の Dockerfile とリポジトリを使用しますが、設定は Coolify のデータベースに保存されます。そのため、ホストを移行する場合は、移行先でプロジェクトを再作成する必要があります。Cloudron は最もロックインが強い選択肢です。アプリは Cloudron 用にパッケージ化されており、優れたバックアップ機能によって データ は問題なく移行できますが、パッケージは移行できません。そのため、移行先のプラットフォームで再デプロイする必要があります。データは移行できますが、運用基盤は移行できません。

どれを選ぶべきか

結論と、別の選択肢を示します。3 つの中で、サーバーの手作業を最小限に抑えたい場合、パッケージ化されたアプリを複数運用する場合、管理された TLS、バックアップ、更新のために年額料金を支払う場合は、Cloudron を選びます。自宅のネットワークまたはリバースプロキシの背後にあるホームラボで、Docker を扱いやすい画面で管理したい場合、料金を一切支払いたくない場合は、CasaOS を選びます。Git から独自のコードをデプロイし、ホスティング型 PaaS より低コストで、TLS の自動設定を含む push-to-deploy を実現したい場合は、Coolify を選びます。3 つのどれにも当てはまらない場合は、次のセクションが率直な答えです。

3 つすべてを省略すべき場合

規模を正直に見積もってください。運用するアプリが 1 つか 2 つだけの場合、またはサーバー上に何があるかを正確に把握して制御したい場合は、パネルを省略してください。 小規模で安定した構成では、オーバーヘッドとロックインに見合う価値がありません。自分で構築する場合は、自分の Compose ファイルの前段にリバースプロキシを置きます。複数の Docker Compose アプリの前段に Traefik を置き、自動 TLS を設定する方法を使えば、パネルの負荷なしで、ワンクリック操作に相当する HTTPS を利用できます。バックアップには、内容を自分で理解している cron 実行の restic ジョブを使います。

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

主要なアプリが 1 つだけなら、この判断はさらに明確です。TLS と独自のバックアップ手順を備えた Docker 上の Nextcloud のインストールは、1 つの Compose ファイルと 1 つの証明書で構成できます。これを実行するためだけにアプライアンス全体を構築しても、コストが増えるだけでメリットはありません。どのように運用するかを決める前に、まだ何を運用するかを検討している場合は、2026 年にセルフホストする価値があるもののガイドから始める方が適しています。

FAQ

セルフホスティング用のパネルは本当に必要ですか？

パネルが自動化する次の4つの機能を、複数のアプリで重視する場合に限り必要です。ワンクリックインストール、自動 TLS、スケジュールバックアップ、ユーザー管理です。サービスが1つか2つであれば、Traefik の背後に通常の Docker Compose を置くだけで、はるかに少ないオーバーヘッドで同じ TLS 処理を実現でき、ベンダーロックインもありません。多数のアプリを運用し、パネルのコストとなる RAM より自分の時間のほうが高価な場合に、パネルの導入効果が得られます。

初心者にはどのパネルが最適ですか？

外部の危険なインターネットに何も公開しないホームラボであれば、CasaOS が最も始めやすい選択肢です。1つのコマンドで導入でき、使いやすい UI があり、料金もかかりません。ただし、公開する前に TLS 終端を担うリバースプロキシを前段に置く必要があります。CasaOS は平文の HTTP を使用するためです。管理 TLS とバックアップを任せる代わりに料金を支払うのであれば、2 アプリまでの無料制限内では Cloudron が最も手厚くサポートします。

Cloudron は無料ですか？

一部は無料です。無料プランでは 2 アプリを利用できるため、試用や非常に小規模な構成には適しています。それを超える場合、Cloudron は月額または年額の有料サブスクリプションとなり、有料プランではアプリ数に制限がありません。Cloudron は無料ソフトウェアではなく、無料プランに上限がある商用製品です。スタックを拡張する予定がある場合は、予算に含めてください。

既存のアプリと同じホストでこれらのパネルを実行できますか？

Cloudron は実行できません。クリーンな Ubuntu ボックスが必要で、nginx、Docker、Node がすでにインストールされていると中止します。マシン全体を管理するためです。CasaOS と Coolify は、独自の Docker スタックをインストールするため、原則として同じホストで運用できます。ただし、CasaOS はダッシュボード用にポート 80 を必要とし、Coolify のプロキシはポート 80 と 443 の両方を必要とします。そのため、これらのポートをすでに使用している Web サーバーやプロキシと競合します。すでに他のサービスをホストしているマシンでは、通常、パネルは適切なツールではありません。代わりに Traefik と Compose を使用してください。

後でパネルから移行するにはどうすればよいですか？

必要になる前に移行計画を立ててください。CasaOS からは、アプリの docker-compose.yaml と /DATA のボリュームを新しいホストへコピーし、そこで再度起動します。Coolify からは、各プロジェクトの設定をエクスポートし、移行先で同じリポジトリを参照させます。Cloudron からは、バックアップからデータを新しいプラットフォームに新規インストールしたアプリへ復元します。Cloudron のパッケージは移行できず、移行できるのはデータだけだからです。いずれの場合も、古いホストを廃止する前に、使い捨てのホストで復元をテストしてください。