Cloud in a Bottleとは何か——Umbrel・CasaOS・YunoHost・Coolifyとの違いを解説

Cloud in a Bottleは、米Imbueが2026年9月5日にAGPL-3.0ライセンスで公開したオープンソースのセルフホスト基盤である。1台のUbuntuマシンにインストールすると、Python製の制御プレーンがダッシュボードを配信し、届いたHTTP(S)リクエストを、rootless（非root）かつハードニングされたPodmanコンテナ上の各アプリへ振り分ける。最大の特徴は、ダッシュボードに一度ログインすれば、連携済みのアプリごとに個別ログインし直す必要がなくなる統合認証である。

アーキテクチャの中心にあるのは、HTTPS終端を担うCaddyと、ワイルドカードサブドメインを発行するCoreDNSである。この2つの組み合わせにより、アプリを追加するたびに自動でHTTPS付きの専用サブドメインが割り当てられる。各アプリはcloudinabottle.tomlというマニフェストファイルで定義され、コンテナ化さえされていればDockerfileベースの既存アプリを本体をフォークせずに追加できる、と公式は説明している。

- 統合認証: ダッシュボードへの1回のログインで、連携済みの全アプリにアクセスできる
- コンテナ隔離: アプリごとにrootless・ハードニングされたPodmanコンテナで実行し、アプリ間の権限を分離する
- 自動HTTPS: CaddyとCoreDNSの組み合わせで、アプリごとに専用サブドメインとTLS証明書を自動発行する
- アプリカタログ: cloudinabottle.org/apps から選んで導入できるが、公式は「UXの水準を保つためあえて絞っている」と説明しており、2026年9月時点では対応アプリ数は限定的である

公式ドキュメントが明記している要件は、新規インストールしたUbuntu 24.04と、idmapped mountsに対応するルートファイルシステム（ext4・xfs・btrfsのいずれか）のみである。必要なRAM・CPU・ディスク容量の具体的な下限値は、2026年9月7日時点では公式に公表されていない。デプロイ先としては、クラウドVPS・自宅の専用サーバー・家族と共有する自宅マシンの3パターンを、ドキュメントがそれぞれ個別ページで案内している。

このプロビジョニングスクリプトは、権限を絞ったホスト用ユーザーの作成、必要パッケージとrootless Podmanのインストール、Cloud in a Bottle本体のクローン、systemdサービスの登録までを一括で行う。自分でサーバーを用意したくない場合は、Imbueが提供するマネージドホスティング（初回$10クレジット付き）を選ぶこともできる。ダッシュボードにログインすれば自分の権限で各アプリを扱えるようにするという発想は、開発環境そのものをセルフホストするCoderのアプローチとも重なる部分がある。

- ドメインを1つ用意し、AレコードをサーバーのIPアドレスに向ける
- 上記のprovisionスクリプトを実行し、Ubuntu機を「ホスト」として初期化する
- ブラウザでダッシュボードにアクセスし、オーナーアカウントを作成する
- アプリカタログから使いたいアプリを選んで起動する。以後は同じログインで全アプリに入れる

セルフホスト基盤としては、家庭用NASに近い操作感のUmbrelやCasaOS、コミュニティ運用で長い実績を持つYunoHost、開発者向けPaaSに近いCoolifyがすでに存在する。Cloud in a Bottleがこれらと最も違うのは、統合認証を最初から前面に押し出している点である。ただしYunoHostも独自のSSO機構（SSOwat）とLDAP連携により、対応アプリに限れば統合ログインを実現しており、統合認証自体はCloud in a Bottleだけの発明ではない点には注意が必要である。

- 向いている: 複数の自作・OSSアプリを1台にまとめ、ログインを一本化したい個人開発者
- 向いている: Ubuntuやコンテナの基礎知識があり、サーバー管理を自分でこなせる技術者
- 向いていない: 対応アプリ数がまだ限定的なため、特定の業務アプリをそのまま動かしたい組織
- 向いていない: サーバー運用の知識がなく、障害時の一次対応も自分では行いたくない人（マネージド版を使わない場合）

公開前、Imbueの関係者とみられるアカウントが、所属を明かさないまま無関係の複数リポジトリに対してcloudinabottle.toml対応を求めるIssueを11件前後立てていたことが、Hacker Newsの議論（2026年9月時点で600点前後・約300コメント）で指摘された。開発者のZack Polizzi氏はこれを認め、「実名かつ所属を明示したアカウントから行うべきだった」「大規模なスパム活動ではなく判断ミスだった」という趣旨のコメントを残している。セルフホスト系プロジェクトは個人データや家族の写真、パスワード管理まで預けてもらう性質上、信頼が特に重視される分野であり、この経緯は事実として記録しておく価値がある。

セルフホストは、クラウドサービス利用料を抑えられる一方で、これまでクラウド事業者が肩代わりしていた運用責任がすべて自社に戻ってくる選択でもある。クラウドとローカル・自社運用のどちらにコストが寄るかという判断軸は、クラウドとローカルLLMのハイブリッド運用で扱われている「どこまで自社で持つか」という論点とも重なる。導入を検討する際は、少なくとも次の点を自社で誰が担うのかを事前に決めておく必要がある。

- バックアップ: 障害・誤操作・ランサムウェア対策として、サーバー本体とは別の場所への定期バックアップを自社で設計・検証する責任が生じる
- 停電・回線断: 自宅や自社オフィスに置く場合、停電や回線障害がそのままサービス停止に直結する
- セキュリティ更新: OSやコンテナランタイムの脆弱性対応・パッチ適用のタイミングは、クラウド事業者ではなく自社の判断に委ねられる
- 固定IP・ドメイン管理: 外部公開にはドメインと安定した回線が前提となり、契約や設定変更の管理も自社の作業になる