Cloudron vs CasaOS vs Coolify 比較 | VPSでの自作サーバー構築

作成するもの

ツールの選定は、インストールと同じくらい重要です。Cloudron、CasaOS、Coolifyの3つのパネルは、VPSをマウス操作だけでアプリをホストできる環境に変えることを目的としています。このガイドでは、これらすべてを新規のUbuntu 24.04にインストールし、最初のアプリを導入します。その後、TLS、バックアップ、アップデート、メモリ消費量、および解約の難易度といった、スクリーンショットには写らない詳細な仕様を検証します。最終的に、どれが最適か、あるいは「どれも使わず、Docker Composeを使うべきか」という判断ができるようになります。

これらのツールに魔法はありません。すべて、手動で操作可能なDocker Engine上で動作しています。パネルが提供するのは、金銭、メモリ、またはベンダーロックインの代償として、以下の4つの作業を自動化することです：ワンクリックでのアプリインストール、自動TLS証明書、スケジュール設定されたバックアップ、およびユーザー管理。これら4つの機能にオーバーヘッドを払う価値があるなら、パネルを導入する価値があります。もし、1つか2つのサービスのみを運用し、サーバー内の構成を完全に把握していたい場合は、まず「これらを使わない」セクションを読み、手間を省いてください。

共通の前提条件と注意点

これら3つの製品はすべて、コンテナ仮想化ではなく KVM VPSであることを前提としています。Dockerには実際のkernelが必要です。また、CloudronはOpenVZおよびLXCを完全に拒否します。systemd-detect-virtで確認してください。kvmまたはqemuは問題ありませんが、openvzまたはlxcは使用できません。KVMプランではコマンドの結果にkvmと表示され、ベアメタルではnoneと表示されます。どちらが表示されても、そのまま続行可能です。

それ以外の仕様は製品ごとに異なり、これが選択の最初の基準となります。

• RAM. CasaOSは1GBで問題なく動作します。Raspberry Pi向けに設計されているため、軽量です。Coolifyは最低2GBのRAMと2つのCPUコアを必要とし、そのうち約600 MBはCoolify自体の使用分です。Cloudronは最低2GBを必要とし、実際には4GBある方が安定します。これは、アプリをインストールする前にメールサーバーとデータベースが動作するためです。
• 管理下にあるドメインとDNS. CloudronとCoolifyは、動作するDNSを持つ実際のドメインを必要とします。Cloudronは、レコード作成やwildcard certificateの自動生成を行うために、DNSプロバイダーへのAPIアクセスを推奨しています。CasaOSはIPアドレスのみでも動作しますが、その場合TLSは利用できません。
• Ports. 3つすべてにおいて、HTTPとHTTPS用に80および443ポートを開放する必要があります。Coolifyは、ダッシュボード用に 8000、リアルタイムチャネル用に6001、ブラウザ内ターミナル用に6002を使用します。すべての環境で、SSH用に22ポートを開放しておいてください。

作業を開始する前に、DNSをサーバーに向けてください。自身のhostnameを解決できないパネルは、証明書を取得できません。そのデバッグに最初の1時間を費やすことになります。サーバーのIPアドレスにA recordを設定してください。Coolifyの場合は、すべてのデプロイ済みアプリにサブドメインを割り当てるため、wildcard record (*.apps.example.com) を追加してください。

Cloudron: 洗練された、ポリシー重視のアプライアンス

概要. Cloudronは、サーバー全体を管理済みアプライアンスに変える商用プラットフォームです。独自のreverse proxy、database、mail stackを実行し、パッケージ化されたアプリ（Nextcloud, WordPress, Gitea, Mattermostなど）の厳選されたApp Storeを提供します。自動アップデート、自動証明書発行、自動バックアップを備えた「管理されたアプリ」を求め、その対価を支払うユーザーを対象としています。

インストール. Cloudronはクリーンな環境を必須とし、サーバーを完全に制御下に置きます。以下のコマンドを、新規のUbuntu 24.04 (Noble) サーバーでのみ実行してください。

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

このスクリプトはDocker、nginx、database、mail stackをインストールし、再起動を行います。再起動後、https://<your-ip>を開き、一時的なself-signed certificateを承認して、ブラウザでセットアップを完了させてください。ドメインを指定し、DNS providerを選択すると、my.example.comにダッシュボードがプロビジョニングされます。

最初のアプリの追加. ダッシュボードでApp Storeを開き、例えばNextcloudをクリックし、サブドメインfiles.example.comを選択してInstallを押します。Cloudronは、設定ファイルを一切操作することなく、DNS recordの作成、Let's Encrypt証明書の要求、databaseのプロビジョニング、SSOの構成、バックアップのスケジュール設定をすべて自動で行います。これがCloudronの核となる価値です。

TLSとバックアップ. 3つの主要機能の中で最も強力な機能です。すべてのアプリのサブドメインにはLet's Encrypt証明書が自動的に割り当てられ、自動更新されます。バックアップは標準でスケジュールされており、ローカルディレクトリ、S3、またはその他のリモートストレージを対象にできます。アプリごとのリストアや、新しいサブドメインへのアプリのワンクリッククローニングも可能です。

コストとライセンス（導入前に必ずお読みください）. Cloudronは制限付きの無料枠がある有料製品です。無料プランでは2つのアプリまで利用可能です。3つ目のアプリをインストールしようとすると、有料プランへの移行が必要です。有料サブスクリプション（ProまたはMax、月払いまたは年払い、どちらもアプリ数は無制限）で機能が解放されます。これがCloudronに関する最も重要な事実です。Cloudronが洗練されているのはビジネスモデルに基づいているためであり、無料枠は拡張された試用期間に近いもので、規模が拡大するスタックの永続的なホームとしては設計されていません。

失敗パターン1：クリーン環境の原則. すでに他のサービスが動作しているサーバーに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 server、Docker、手動で設定したfirewallすら存在しない状態にしてください。誤ったイメージで起動した場合、セットアップは拒否されます。サポートされているのはx86-64上のUbuntu LTS (22.04または24.04) のみです。ARM、LXC、OpenVZはサポートされていません。

失敗パターン2：ワイルドカード証明書にはDNS APIが必要. セットアップ時にAPI tokenの代わりに"Manual" DNSオプションを選択すると、CloudronはDNS recordやワイルドカード証明書を作成できません。その場合、新しいアプリを追加するたびに、証明書発行前に手動でDNS recordを追加する必要があり、ダッシュボードはその完了を待機状態になります。サポートされているDNS provider（Cloudflare, Route 53, DigitalOceanなど）へのAPIアクセス権をCloudronに与えれば、すべてのフローがワンクリックになります。

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

概要. IceWhaleが開発したCasaOSは、Docker上で動作する無料のオープンソース・ダッシュボードです。ホーム画面、アプリストア、ファイルマネージャーを提供します。ホームサーバー向けに設計されており、セットアップが迅速で、使いやすいUIを持ち、複雑な手順を必要としません。Dockerに優れたインターフェースを、コストをかけずに導入したいユーザーを対象としています。

インストール. 以下のコマンドを実行します。既存の環境でも動作します。

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）に公開します。ストアには一般的なホームサーバー向けアプリが揃っており、VPS上のJellyfinメディアサーバーやセルフホストのImmichフォトライブラリも数クリックで導入できます。また、任意の docker-compose.yaml をインポートすることも可能です。これがCasaOSの強みです。アプリは独自の形式ではなく、標準的なコンテナとして動作します。

TLSとバックアップ（注意点）. ここが「無料」ゆえの制限です。CasaOSは、ダッシュボードを含むすべての通信がデフォルトでプレーンなHTTPで行われます。Let's Encryptの組み込み機能や、スケジュール設定によるバックアップ機能はありません。データは /DATA のDockerボリューム内に保存されるため、バックアップ（cronを使用した restic や tar など）はユーザー自身で行う必要があります。

失敗のパターン：TLSなしのサイレントなリスク. エラーは発生しません。アプリをインストールして http://<your-ip>:8080 を開くと、ブラウザに "Not Secure" と表示される暗号化されていない接続で正常に動作します。パスワードやセッションクッキーは平文で送信されます。さらに、CasaOSのダッシュボードには、リモートコード実行の脆弱性が実際に発見されています（CVE-2023-37265およびCVE-2023-37266。認証バイパスからホストの完全な制御につながるもの）。そのため、HTTPポートを直接インターネットに公開することは、単なる好みの問題ではなく、重大なリスクです。対策として、CasaOSを直接公開しないでください。CertbotのLet's Encrypt証明書を使用したnginx、Caddy、またはCloudflare Tunnelなどのリバースプロキシを前面に配置してTLSを終端し、ローカルネットワーク内のCasaOSへ転送してください。なお、CasaOSは既にport 80を使用しているため、先にCasaOSのポートを変更しない限り、プロキシとポートが競合します。

コスト. 完全に無料であり、アプリの数に制限もありません。その代わり、TLSの設定、バックアップ、セキュリティの強化は、すべてユーザー自身が管理する必要があります。

Coolify: セルフホスト型 PaaS

概要. Coolifyは、HerokuやVercelのように、自身のサーバー上で動作するオープンソースのセルフホスト型 Platform-as-a-Serviceです。基本単位は「パッケージ化されたアプリのインストール」ではなく、「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でアクセス可能です。すぐに管理者アカウントを作成してください。最初のユーザーが作成されるまで登録ページは公開されており、最初にアクセスした者がサーバーを制御できてしまうためです。その後、インスタンスのドメインを設定し、Coolifyがデプロイされた各アプリにサブドメインを割り当てられるよう、ワイルドカードDNSレコード（*.example.comまたは*.apps.example.com）をサーバーに向けてください。

最初のアプリの追加. Gitソース（GitHub、GitLab、またはリポジトリのURL）を接続し、ブランチを選択して、ドメインを設定し、デプロイします。Coolify内蔵のTraefikプロキシがサブドメインへのルーティングと証明書の要求を行います。既製品のソフトウェアについては、Servicesカタログから数クリックでデプロイ可能です。例えば、手動で構築する必要があるn8nワークフロー自動化スタックや、ステータスページ監視用のUptime Kumaも、項目として用意されています。

TLSとバックアップ. 組み込みのTraefikを通じて、アプリごとにLet's Encryptによる自動証明書取得が可能です。バックアップはデータベースが中心となります。PostgresやMySQLのダンプをS3互換ストレージへスケジュール実行できます。インスタンス全体のバックアップ（/data/coolifyに保存されているCoolifyの設定自体）は手動での操作が必要なため、自身でエクスポートして保存してください。

コストとライセンス. セルフホスト版は完全にオープンソースで無料であり、アプリの数に制限はありません。オプションとしてCoolify Cloud（有料）があり、アプリは自身のサーバーで動作させたまま、コントロールプレーンのみをホストできます。これは便利ですが、必須ではありません。

トラブルシューティング：アプリはデプロイされたがドメインが読み込めない. ダッシュボードはhttp://<ip>:8000で正常に動作し、ビルドも成功（green）しているが、アプリの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デーモンが停止しているか、SSHキーが壊れていることが原因です。推測する前に、ログで実際の原因を確認してください。

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 は、自身のサポートコンテナ（app, Postgres, Redis, realtime service, Traefik）を複数実行するため、デプロイ前のアイドル状態で約 600 MB ～ 1 GB を消費します。
• Cloudron は、使用の有無に関わらず nginx、データベース、メールスタック、モニタリングを実行するため、アイドル時の負荷が最も高いです。アイドル状態で 1 ～ 1.5 GB のメモリを確保してください。そのため、最低 2GB のメモリが必要であり、4GB あれば余裕を持って動作します。

2GB の小型 VPS では、CasaOS が最もアプリケーション用の空き領域を多く残し、Cloudron が最も少なくなります。2GB のプランで、メールサーバーを含む Cloudron を使用する場合は、マシンのアップグレードを検討してください。

アップデート、バックアップ、およびロックインの比較

Updates. Cloudronは、テスト済みのスケジュールに従ってプラットフォームとすべてのappを自動更新します。これは手間が最も少なく、管理が容易な方法です。Coolifyは、ダッシュボード上のボタンを1回押すだけで自身を更新します。CasaOSは、install scriptまたは apt を通じてパネルを更新しますが、インストールしたappの更新は、ユーザー自身でpullおよびrestartを行う必要があります。

Lock-in, 2年目に問題となる要素. CasaOSは、ロックインが最も少ない構成です。appは通常のComposeプロジェクトであるため、docker-compose.yaml と /DATA 配下のvolumeを別のホストにコピーするだけで移行が可能です。Coolifyは、その中間に位置します。デプロイ内容は独自のDockerfileとrepoに基づきますが、設定情報はCoolifyのdatabaseに保存されています。そのため、ホストを移行する場合は、移行先でプロジェクトを再作成する必要があります。Cloudronは、最もロックインが強い構成です。appはCloudron専用のパッケージ形式になっています。優れたbackup機能によりdataは問題なく抽出できますが、パッケージ構成は抽出できません。そのため、移行先では再デプロイが必要です。データはポータブルですが、構成（plumbing）はポータブルではありません。

どれを選ぶべきか

簡潔な結論を述べます。

Cloudron は、サーバー管理の手間を最小限に抑えたい場合に適しています。パッケージ化された複数のアプリを実行でき、TLS、バックアップ、アップデートの管理費用として年間料金が発生します。

CasaOS は、自身のネットワーク内のホームラボやリバースプロキシとして使用する場合に適しています。Docker を直感的に操作でき、費用を一切かけたくない場合に適しています。

Coolify は、Git から自身のコードをデプロイする場合に適しています。ホスティング型 PaaS のようなコストをかけずに、自動 TLS を備えた push-to-deploy を実現できます。

これら 3 つのいずれにも当てはまらない場合は、次のセクションを確認してください。

次の3つの手順をスキップする場合...

運用規模を正確に把握してください。アプリが1つか2つのみの場合、またはサーバー上の構成を完全に把握・制御したい場合は、パネルの使用をスキップしてください。 小規模で安定したスタックにおいて、オーバーヘッドやロックインのデメリットは大きすぎます。DIYによる構成は、自身の Compose file の前に reverse proxy を配置する方法です。Traefik with automatic TLS in front of several Docker Compose apps を使用すれば、パネルのような負荷をかけずに、ワンクリックと同等の HTTPS 環境を構築できます。バックアップは、構造を理解している cron 実行の restic job で行います。

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

単一の主要アプリを運用する場合は、さらに明確です。Nextcloud install on Docker with TLS and its own backup routine は、1つの Compose file と1つの certificate で完結します。これらを実行するためだけに、専用の appliance を構築するのはコストに見合いません。運用方法を決める前に「何を」運用するかを検討している場合は、guide to what is worth self-hosting in 2026 から始めることを推奨します。

FAQ

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

パネルが自動化する4つの機能（ワンクリックインストール、自動TLS、スケジュールバックアップ、ユーザー管理）が必要な場合のみ、導入を検討してください。1つか2つのサービスを動かすだけであれば、Traefikの背後でDocker Composeを使用する方が、オーバーヘッドが少なく、ベンダーロックインもありません。多くのアプリを運用しており、パネルの消費メモリよりも作業時間を優先したい場合に、パネルの導入価値があります。

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

インターネットに公開しないホームラボであれば、CasaOSが最も簡単です。コマンド1つで導入でき、使いやすいUIを備え、費用もかかりません。ただし、CasaOSはHTTPのみで動作するため、外部に公開する前にTLSを終端するリバースプロキシを設置する必要があります。TLSやバックアップの管理を自動化し、その対価を支払う用意がある場合は、Cloudronが最も手厚いサポートを提供します（無料枠は2アプリまで）。

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のパッケージ構成は引き継げず、データのみが移行対象となります。そのため、バックアップから新しいプラットフォーム上の新規インストール済みアプリへデータを復元してください。いずれの場合も、古い環境を削除する前に、テスト用のマシンで復元テストを行ってください。