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 にアクセスできることが理想的です。自身でレコードとワイルドカード証明書を作成できるためです。CasaOS はベア IP でも動作しますが、その場合は TLS を使用できません。
• ポート。 3 つとも HTTP と HTTPS 用に 80 と 443 を開放する必要があります。Coolify は追加でダッシュボードを 8000 で提供し、リアルタイム通信に 6001、ブラウザー内ターミナルに 6002 を使用します。いずれの場合も、SSH 用にポート 22 を開放してください。

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

Cloudron: 洗練された、方針が明確なアプライアンス

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

インストール。 クリーンなサーバーを要求し、サーバー全体を完全に管理下へ置きます。新規の Ubuntu 24.04 (Noble) サーバーで、他に何も入っていない状態で次を実行します。

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

スクリプトは Docker、nginx、データベース、メールスタックをインストールしてから再起動します。サーバーが復帰したら https://<your-ip> を開き、一時的な自己署名証明書を受け入れて、ブラウザーでセットアップを完了します。ドメインを指定し、DNS プロバイダーを選択すると、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 をインストールしようとすると、何も変更しないままセットアップが中止されます。

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's 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）以外は拒否されます。x86-64 以外の ARM、LXC、OpenVZ はサポート対象外です。

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

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 は、オープンソースの自己ホスト型 platform-as-a-service です。自分のサーバー上で Heroku や Vercel に近い運用ができます。基本単位は「パッケージ化されたアプリをインストールすること」ではなく、「Git リポジトリをデプロイすること」です。リポジトリを接続すると、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 にあります。直ちに管理者アカウントを作成してください。最初のアカウントが作成されるまで登録ページが公開されており、最初にアクセスしたユーザーがサーバーを管理できるためです。次に、インスタンスのドメインを設定し、ワイルドカード DNS レコード（*.example.com または *.apps.example.com）をサーバーに向けます。これにより、Coolify はデプロイした各アプリに固有のサブドメインを割り当てられます。

最初のアプリを追加する。 Git ソース（GitHub、GitLab、または通常の repo URL）を接続し、ブランチを選択して、ドメインを設定してからデプロイします。Coolify に組み込まれた Traefik プロキシがサブドメインへのルーティングを行い、証明書を取得します。既製ソフトウェアの場合は、Services カタログから数回のクリックでデプロイできます。自分で構成する場合に手作業で組み立てる n8n のワークフロー自動化スタックも 1 つの項目として用意されており、ステータスページ監視用の Uptime Kumaも同様です。

TLS とバックアップ。 バンドルされた Traefik を通じて、アプリごとの Let's Encrypt 証明書を自動取得します。デプロイした各サブドメインに証明書が発行されます。バックアップはデータベースを優先します。Postgres と MySQL のダンプを S3-compatible storage にスケジュール保存できます。インスタンス全体のバックアップ（/data/coolify 配下に保存される Coolify の設定自体）は手動作業が多いため、自分でエクスポートして保管してください。

費用とライセンス。 自己ホスト版は完全にオープンソースで無料で、アプリ数の上限はありません。オプションとして有料の Coolify Cloud もあります。これはコントロールプレーンを代わりにホストしますが、アプリは引き続き自分のサーバー上で動作します。便利ですが、必須ではありません。

障害例: アプリはデプロイされるが、ドメインで読み込めない。 http://<ip>:8000 のダッシュボードは正常に動作し、ビルドも成功する一方で、アプリ自身の URL は接続エラーまたは Traefik の 404 page not found を返します。この場合、原因はアプリではなく、プロキシまたは DNS にある可能性があります。よくある原因は 2 つあります。1 つ目は、プロキシの起動時にポート 80 または 443 がすでに使用されていたケースです。そのため、プロキシのコンテナが Docker エラーで停止します。

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 つ目は、ワイルドカード DNS レコードがないケースです。この場合、Traefik はそのホスト名宛てのリクエストを受け取れません。Coolify のサーバーカード全体に 「Server is not reachable」 と表示される場合は、別の障害です。Coolify がサーバーの Docker socket と通信できていません。通常は、停止した Docker daemon または壊れた SSH key が原因です。推測で判断せず、まずログで実際の理由を確認してください。

docker logs coolify-proxy --tail 100

Proxy ページで修正します。Restart Proxy を押すか、プロキシ設定をデフォルトに戻して再度起動します。その後、状態が安定するまで約 2 分待ちます。ポート 8000 は自分の IP からのみ到達できるようにしてください。プロキシが不安定な場合だけ一時的に再開します。ポート 8000 は平文 HTTP でダッシュボードを提供するため、インターネット全体に公開したままにしないでください。Coolify の公式ドキュメントでも、ダッシュボードを独自ドメイン経由で提供した後は、ポート 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 終端を担うリバースプロキシを前段に置く必要があります。平文の HTTP を使用するためです。TLS とバックアップの管理を任せ、その対価を支払う場合は、2アプリまでの無料制限内であれば Cloudron が最も手厚く支援します。

Cloudron は無料ですか？

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

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

Cloudron はできません。クリーンな Ubuntu のホストが必要で、nginx、Docker、または Node がすでにインストールされていると中止します。マシン全体を管理するためです。CasaOS と Coolify は、独自の Docker スタックをインストールするため、原則として同じホストを共有しやすい構成です。ただし、どちらも 80 番ポートと 443 番ポートを使用するため、既存の Web サーバーやプロキシと競合します。すでに他のサービスをホストしている場合、通常はパネルは適したツールではありません。代わりに Traefik と Compose を使用してください。

後からパネルを使わない構成へ移行するにはどうすればよいですか？

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