著者 VPSにCloudronをインストールする方法
新規Ubuntu VPSへCloudronを導入する手順を解説します。ワイルドカードDNS、セットアップスクリプト、初回起動、2～10個のアプリに必要な容量、メール、証明書、バックアップを確認できます。
VPS に Cloudron をインストールする: 簡易版
VPS に Cloudron をインストールするには、新規の Ubuntu サーバー、少なくとも 2 GB の RAM、そして DNS レコードを編集できるドメインが必要です。インストール自体は 3 つのコマンドを実行して 1 回再起動するだけです。問題の大半は、その前段階（ベースイメージや仮想化方式の誤り）またはインストール後（DNS、メール、バックアップ）に発生します。
wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setupCloudron はセルフホストアプリのインストール、更新、バックアップ、TLS（transport layer security）証明書の発行を行います。各アプリは Docker 上で動作し、すべてのアプリの前段に nginx が配置されます。また、各アプリにはドメインのサブドメインが割り当てられます。DNS の設定を最初に行うのは、この仕組みのためです。
Cloudron がベース OS に厳格な理由
セットアップスクリプトは、何もインストールする前にサーバーを確認します。チェックに失敗すると、新しいサーバーを契約し直すことになります。イメージを選ぶ前に、次の条件を確認してください。
- Ubuntu のみ対応し、対象リリースも 3 つだけです。それ以外の場合は
Cloudron requires Ubuntu 20.04, 22.04, 24.04で終了します。Debian、Rocky、Alpine はサポートされません。Ubuntu 24.04 には Cloudron 8 以降が必要で、スクリプトが自動的に確認します。 - 64-bit の Intel または AMD のみ対応します。
Error: Cloudron only supports amd64/x86_64が必要です。ARM VPS では実行できません。 - 完全なハードウェア仮想化のみ対応します。コンテナベースの VPS では、
systemd-detect-virt --containerによってコンテナを検出するため、スクリプトはError: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualizationで停止します。KVM は使用できます。OpenVZ と LXC は使用できません。 - root ファイルシステムは
ext4またはxfsである必要があります。それ以外の場合はError: Cloudron requires '/' to be ext4 or xfsが表示されます。btrfs と zfs のイメージで発生する失敗もこれが原因です。 - RAM は少なくとも 941 MB、
/の空き容量は 20 GB 必要です。RAM はfree -m、ディスク容量は root ファイルシステムのサイズで測定します。 - 完全に新規のサーバーが必要です。
nginx、docker、nodeのいずれかがすでにインストールされている場合、スクリプトはError: Some packages like nginx/docker/nodejs are already installed.で拒否します。
最後のチェックについては議論になることが多いため、その理由を説明します。Cloudron は Docker、nginx、Node.js、MySQL の固定バージョンをインストールし、ホストするすべてのアプリの nginx 設定を書き込み、iptables のファイアウォールルールを自ら管理します。昨日インストールした Docker は適切なバージョンではなく、既存の nginx のサイトファイルは置き換えられます。Cloudron はマシン全体を管理するため、専用の VPS を用意してください。
見落としやすいチェックがもう 1 つあります。AVX（advanced vector extensions）を搭載していない古い CPU では、スクリプトに CPU has no AVX support. MongoDB will be disabled が表示されます。その場合、MongoDB を必要とするアプリはすべてインストールできません。契約する前に grep -m1 -o avx /proc/cpuinfo で CPU を確認してください。対応しているホストでは avx が表示され、古いホストでは何も表示されません。
Cloudron に必要な RAM 容量
Error: Cloudron requires atleast 1GB physical memory のため、スクリプトは 941 MB 未満では実行できません。ドキュメントでは RAM 2 GB とディスク 20 GB が必要とされています。これらはプラットフォーム単体の最低要件であり、プラットフォームとアプリの合計に対する要件ではありません。アプリを1つもインストールしていない段階でも、Cloudron はすでに Docker、nginx、独自の box サービス、アプリに提供するデータベースコンテナ（MySQL、PostgreSQL、MongoDB）、Redis、メールスタックを実行しています。新規インストールで docker ps を実行し、コンテナ数を確認してください。
アプリのメモリ制限は、このベースの使用量に加算されます。各アプリパッケージには低めのデフォルト制限が設定されており、アプリの Resources ビューにあるスライダーで引き上げられます。アプリが制限を超えると再起動し、OOM（out of memory）通知が送信されます。そのため、1つのアプリが繰り返し再起動するサーバーでは、バグよりも制限値が原因であることが一般的です。
私なら、次の構成で発注します。これらは、翌月に再構築する必要がないサーバー向けの推奨値です。実測したベンチマーク結果ではありません。
The data behind this chart
[
{
"label": "2 apps (free tier)",
"vcpu": 2,
"ram_gb": 4,
"disk_gb": 60
},
{
"label": "5 apps",
"vcpu": 4,
"ram_gb": 8,
"disk_gb": 120
},
{
"label": "10 apps",
"vcpu": 6,
"ram_gb": 16,
"disk_gb": 240
}
]アプリ2個なら、RAM 4 GB とディスク 60 GB で余裕があります。アプリ10個前後では、RAM 16 GB とディスク 240 GB が必要です。プラットフォームのベース使用量は減らず、アプリごとに Docker イメージ、データベース、固有のデータが追加されるためです。ディスクは予想より速く埋まります。バックアップをサーバー外へ移すまでは、イメージ、アプリデータ、ローカルバックアップが1つのボリュームを共有するためです。
Cloudron はすべてのアプリに無制限の swap を提供します。そのため、設定したメモリ制限が適用されるのは RAM だけです。swap ファイルのない VPS イメージでは、swapon --show は何も出力しません。この場合、メモリが逼迫するとアプリの動作が遅くなるのではなく、OOM による再起動が直接発生します。swap 2 GB を追加するのは安価な保険ですが、実メモリの代わりにはなりません。VPS プラン間の料金差は、制限値の調整に費やす時間と比べれば小さいため、VPS の実際の料金を確認して、1つ上のサイズを選んでください。
DNS：アプリのサブドメインを機能させるワイルドカードレコード
Cloudron は my.example.com にダッシュボードを配置し、各アプリを専用のサブドメインで公開します。そのため、DNS の設定は後回しにできず、必須の前提条件です。初回にダッシュボードを開く前に、以下のレコードをサーバーのパブリック IP アドレスへ向けてください。
my.example.comを A レコードとして設定します。これはダッシュボードです。*.example.comを A レコードとして設定します。これによりアプリのサブドメインが機能するため、アプリをインストールするとwiki.example.comとgit.example.comがすぐに名前解決されます。- ベアドメインでアプリを使用する場合だけ、
example.comを A レコードとして設定します。
ワイルドカードレコードは明示的なレコードより優先度が低いため、別の場所を指す既存の www.example.com はそのまま機能します。
セットアップ中に、以後 Cloudron が DNS を処理する方法を選択します。
- API プロバイダー。Cloudron に Cloudflare、DigitalOcean、Route53、Hetzner、Porkbun、Linode、deSEC、Gandi、Namecheap など約 20 のサービスのトークンを保存し、メール用レコードを含むすべてのレコードを自動的に作成させます。
- ワイルドカード。
*レコードを手動で追加します。Cloudron はレコードを作成しません。 - 手動。Cloudron が各レコードを表示するので、アプリをインストールするたびに、すべてのレコードを追加するまで待機させます。
ワイルドカード DNS レコードは、ワイルドカード証明書ではありません。 デフォルトの証明書プロバイダーは Let's Encrypt Prod - Wildcard です。DNS によってドメインの所有権を証明するため、API プロバイダーでのみ機能します。ワイルドカードまたは手動のバックエンドでは、HTTP 経由で検証するアプリごとの証明書に切り替わります。この場合、受信ポート 80 を常に開放しておく必要があります。レジストラーまたは DNS ホストが API の一覧にある場合は、それを使用してください。メール用レコードと証明書の管理を、どちらも自分で行う必要がなくなります。
先に進む前に確認してください。dig +short my.example.com と dig +short anything.example.com は、どちらもサーバーの IP アドレスを出力する必要があります。ワイルドカードの問い合わせ結果が空の場合、ダッシュボードは正常に動作しても、後でアプリが失敗します。
ドメインが Cloudflare の背後にある場合は、レコードを DNS only に設定してください。プロキシが転送するのは HTTP と HTTPS だけなので、メール用ポートが機能しなくなります。また、各アプリからは訪問者のアドレスではなく Cloudflare のアドレスが見えるようになります。
セットアップスクリプトを実行する
wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setuproot として実行するか、sudo 経由で実行してください。そうしない場合、最初に This script should be run as root. と表示されるためです。インストールには数分かかります。実行中は、apt の出力と Docker の pull がログファイルに書き込まれるため、画面にはほとんど何も表示されません。別の SSH セッションから次のコマンドで監視します。
tail -f /var/log/cloudron-setup.log最後に After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. とサーバーのアドレスが表示され、続いて The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] と尋ねられます。yes と回答してください。再起動を予約する必要がある場合は --skip-reboot フラグを使用できます。ただし、サーバーが再起動して戻るまで Cloudron は使用できません。
初回起動: ドメイン、DNS バックエンド、管理者アカウント
https://<server-ip>を開き、ブラウザーの警告を受け入れます。Cloudron はまだドメインを認識していないため、認証局に証明書を要求できません。そのため、証明書は自己署名です。Chrome ではAdvanced、続いてProceed to <ip> (unsafe)をクリックします。Firefox ではAdvanced、続いてAccept the Risk and Continueをクリックします。
最初の画面でドメインを入力します。example.comを入力すると、ダッシュボードの URL はmy.example.comになります。代わりにcloudron.example.comのようなサブドメインも使用でき、その場合のダッシュボードはmy.cloudron.example.comになります。DNS バックエンドを選択し、API トークンがある場合は貼り付けます。次に、実際に確認できるメールアドレスを使用して管理者アカウントを作成します。Let's Encrypt の登録とプラットフォームからのすべてのアラートに、そのメールアドレスが使用されます。
保存すると、Cloudron は証明書を要求し、ダッシュボードをhttps://my.example.comへ移動します。この時点で IP アドレスの URL は使用できなくなるため、新しい URL をブックマークします。
証明書: 更新される対象と、更新が停止するタイミング
証明書の更新は自動で行われ、認証局が公開するスケジュールである ACME Renewal Information (ARI) に従います。通常は有効期限の約1か月前に更新されます。更新に失敗すると管理者アカウントにメールが届き、証明書の有効期限が切れると、組み込みの自己署名証明書にフォールバックします。昨日まで動作していたサイトでブラウザーに警告が表示される場合、実際にはこのフォールバックが発生しています。
主な原因は2つです。HTTP 検証には受信ポート 80 が必要です。そのため、「どうせすべて HTTPS だから」と 80 番ポートを閉じると、Wildcard または Manual DNS バックエンドを使用するすべてのアプリで更新に失敗します。DNS 検証には、書き込み権限が残っている API token が必要です。そのため、token をローテーションしたり権限を縮小したりすると、警告メールが届くまで更新の失敗に気付けないことがあります。
Domains ビューには、更新を直ちに試行する Renew All ボタンと、テスト用の Let's Encrypt Staging provider があります。Staging 証明書は、意図的にブラウザーから信頼されません。これにより、production の rate limit を消費せず、必要な回数だけ再試行できます。
組み込みのメールサーバーを使用すべきですか？
Cloudron には、IMAP メールボックス、submission、Sieve フィルター、DKIM（domainkeys identified mail）署名を備えた完全なメールスタックが含まれています。ダッシュボードの Email で、ドメインごとに有効化します。メールを確実に配信することが難しい点であり、その難しさは Cloudron に起因するものではありません。
- ほとんどの VPS プロバイダーは、スパム対策として送信元ポート 25 をブロックしています。サポートチケットを送信すると、ブロックを解除してもらえる場合があります。サーバーから
nc -zv aspmx.l.google.com 25でテストします（コマンドがない場合はnetcat-openbsdをインストールします）。開いているポートはsucceededと表示され、ブロックされたポートはタイムアウトするまで応答しません。 - PTR レコード（逆引き DNS）は DNS ホストではなく VPS プロバイダーが設定します。また、メールホスト名と一致させる必要があります。一般的な PTR が設定されたアドレスからのメールは、迷惑メールフォルダーに振り分けられます。
- SPF、DKIM、DMARC レコードは、API DNS バックエンドでは自動で作成されます。Wildcard または Manual バックエンドでは手動で追加します。DKIM レコードがない場合、署名したすべてのメッセージを検証できません。
多くのユーザーに適した構成は、Cloudron でメールを受信し、SendGrid、Postmark、Mailgun、Amazon SES などのリレー経由で送信する方法です。リレーは、ドメイン上の任意のアドレスを送信元として許可する必要があります。許可されていない場合、送信者が異なるアプリ通知が拒否されます。サーバーを購入する主な理由がメールである場合は、Mailcow などの専用メールサーバーを、固有の IP レピュテーションを持つ別のマシンで運用してください。
Cloudron Email をまったく使用しない場合は、プロバイダーのファイアウォールでポート 25、465、587、993、4190 をブロックします。サーバー上ではなくプロバイダー側で設定してください。Cloudron は iptables ルールを自動的に作成し、それらを自身で管理する前提だからです。これは通常の VPS とは逆です。通常の VPS では、ufw ルールを自分で管理します。
必要になる前にバックアップ先を設定する
バックアップの保存先はデフォルトでは /var/backups のローカルファイルシステムで、ほかのデータと同じディスク上になります。ドキュメントにも、「プラットフォームサーバーと同じ物理ディスクにバックアップを保存するのは危険です」と明記されています。ディスクが1台故障すると、アプリとバックアップが同時に失われます。
Backups を開き、次に Backup Sites を開いて、初日から別の保存先を指定します。通常は S3互換のオブジェクトストレージを使用します（Backblaze B2、Wasabi、Cloudflare R2、DigitalOcean Spaces、または 2台目のサーバー上の MinIO バケット）。SSHFS、NFS、CIFS、通常のファイルシステムの保存先もサポートされています。
このバックアップを実際に役立つものにするかどうかは、次の3つの設定で決まります。
- Format。
tgzはアプリごとに圧縮アーカイブを1つ作成し、実行のたびに全体を再アップロードします。rsyncは変更されたファイルだけをアップロードするため、大規模な Nextcloud では大幅に安価です。ただし、ストレージ API へのリクエスト数は大幅に増えます。 - Encryption。ファイルの内容とファイル名の両方を対象にする AES-256 暗号化を任意で有効にできます。Cloudron はパスワードのコピーを保持しないため、パスワードを失うと、あなたを含めて誰もバックアップを復号できません。保存をクリックする前に、自己ホスト型のパスワードマネージャーに保存してください。
- Retention。7 daily や 4 weekly のように、保持する世代数で指定します。オブジェクトストレージで長期間保持すると毎月料金が発生するため、継続して支払える数を選択してください。
次に、復元をテストします。小規模なアプリをインストールし、ダッシュボードから復元して、データを含めて正常に戻ることを確認します。一度も復元したことのないバックアップは、単なる推測にすぎません。
無料プランの制限
2026 年 8 月時点で、無料プランにインストールできるアプリは 2 つまでです。アプリの更新、アプリごとのバックアップ、ファイアウォール、メールサーバー、シングルサインオンはすべて利用できます。3 つ目のアプリを追加する時点でライセンスが必要です。有料プランではアプリ数の上限がなくなり、上位プランではユーザーグループとロール、ディレクトリサーバー、複数のバックアップサイトも追加されます。料金は変更されるため、チュートリアル内の数字ではなく、Cloudron の料金ページを確認してください。
1 つのライセンスで対象になるのは 1 つの Cloudron インストールです。そのため、小規模なサーバー 2 台では、大規模なサーバー 1 台の 2 倍の費用がかかります。この料金体系のため、多くの利用者はサービスを複数のマシンに分散する一般的な推奨とは反対に、より大きな VPS 1 台を選びます。後から分割すると費用が 2 倍になるため、この点を考慮してサーバーの規模を決めてください。
障害が発生した場合
まず、組み込みのチェックを実行します。DNS、証明書、ディスク、メモリ、各サービスを順に確認し、どのテストが失敗したかを示します。
sudo cloudron-support --troubleshootその後、通常の systemd（システムおよびサービスマネージャー）ツールを使用します。systemctl status box は Cloudron サービス自体の状態を報告し、journalctl -u box -n 100 は直近のログを表示し、journalctl -u docker は基盤のコンテナランタイムを確認します。インストール中に発生した問題の記録は /var/log/cloudron-setup.log に残ります。
ダッシュボードを読み込めない場合、原因は通常 Cloudron ではなく、DNS またはプロバイダーのファイアウォールです。dig +short my.example.com をラップトップから実行し、プロバイダーのネットワークファイアウォールで 80 番ポートと 443 番ポートが開いていることを確認します。これはサーバー自身のルールとは別の制御です。最初からやり直す場合、スクリプトは Error: Cloudron is already installed. To reinstall, start afresh により 2 回目の実行を拒否するため、サーバーを再構築するのが確実です。
Cloudron が適さない構成
Cloudron は、インフラではなくアプリケーションを運用したい場合に適しています。独自の方法でコンテナを運用したい場合は適していません。nginx、Docker、ファイアウォールを Cloudron が管理し、そこに追加した設定を上書きするためです。Compose ファイルをまとめたディレクトリを運用する計画であれば、独自の Docker Compose スタックの前段に Traefik を置くことで、プラットフォームを介さずに同じ自動 TLS とサブドメインルーティングを利用できます。まだ選定していない場合は、Cloudron、CasaOS、Coolify の比較で各製品を並べて確認できます。また、インストールガイドよりも、セルフホストできるものの幅広い一覧から始める方が適しています。
FAQ
Cloudron には VPS 上でどれだけの RAM が必要ですか？
セットアップスクリプトは 941 MB 未満では実行を拒否し、ドキュメントでは 2 GB を求めています。ただし、これはアプリを配置していないプラットフォームの最低容量です。Cloudron は初回起動時から Docker、nginx、独自の box サービス、データベースコンテナ、メールスタックを実行します。2 個のアプリには 4 GB、約 10 個には 16 GB を確保し、swap ファイルも追加してください。Cloudron はアプリに無制限の swap を割り当てるため、swap がないサーバーではメモリ不足が再起動につながります。
Debian、またはすでに Docker を実行しているサーバーに Cloudron をインストールできますか？
どちらも使用できません。スクリプトはリリースを確認し、Cloudron requires Ubuntu 20.04, 22.04, 24.04 で停止するため、Debian、Rocky、Alpine は対象外です。また、nginx、docker、node のいずれかがすでに存在する場合も停止します。これらすべての固定バージョンをインストールし、nginx の設定と iptables のルールを自ら作成するためです。KVM VPS 上の新しい Ubuntu イメージから始めてください。
ダッシュボードは動作するのに、アプリのサブドメインが失敗するのはなぜですか？
ワイルドカード DNS レコードがありません。セットアップでは my.example.com の A レコードを作成するか、事前に設定しておく必要があります。そのためダッシュボードは名前解決できますが、wiki.example.com は NXDOMAIN を返し、ブラウザーにはサイトが見つからないと表示されます。*.example.com の A レコードを追加してサーバーの IP アドレスを指定し、アプリをインストールする前に dig +short wiki.example.com で確認してください。
Cloudron のメールサーバーを使用する必要がありますか？
いいえ。受信メールを無効にして、Postmark、Mailgun、Amazon SES などの外部リレー経由で送信できます。これは、プロバイダーが送信元ポート 25 をブロックしている場合や、IP アドレスにメールの評価がない場合に、より安全な選択です。Cloudron Email を完全に使用しない場合は、サーバー上ではなくプロバイダーのファイアウォールでポート 25、465、587、993、4190 を閉じてください。
無料プランで 2 個のアプリ制限に達するとどうなりますか？
ダッシュボードは 3 個目のインストールをブロックし、ライセンスキーを要求します。すでに実行しているアプリには影響しません。更新、バックアップ、証明書の維持は引き続き行われます。ライセンスを追加すれば、再インストールせずに制限を解除できます。そのため、無料プランは実際のドメインでプラットフォームを試す方法として適しています。