Tada Cloud — ハイスペックなサーバーがなくても動く、自分だけのクラウド

🧠 概要

自分のクラウドが欲しかったです。「月額50ドルで他人のサーバーを借りる」タイプではなく、「全部自分のマシンで動かす」タイプです。でも問題があります。セルフホスト型のアプリは、どれも自前のPostgreSQL、自前のRedis、自前のWebサーバーを必要とします。12個もアプリを立ち上げると、インフラのオーバーヘッドだけで16GBのRAMが必要になります。

一番近い既存のソリューションは Cloudron — アプリ間でインフラを共有するセルフホスト型プラットフォームです。考え方は同じで、データベースは一つ、プロキシは一つ、管理は一箇所です。コンセプトは気に入っていましたが、CloudronにはちゃんとしたSSO機能がありません（OIDC/OAuth2プロバイダーがなく、各アプリが独自にユーザーを管理します）。さらにクローズドソースのアプライアンスで、独自のランタイムを持っており、Infrastructure as Codeではありません。バージョン管理ができて、カスタマイズでき、隅々まで理解できるものが欲しかったです。だから自分で作りました。

Tada Cloud がそれです。全アプリが同じデータベース、同じキャッシュ、同じプロキシ、同じログインシステムを共有します。しかし全てはプレーンなDocker Composeファイルで、誰でも読め、フォークでき、カスタマイズできます。結果として、約8つのインフラコンテナ上で12以上のアプリが本番稼働しており、すべて自動HTTPSで v4.io.vn ドメインの配下にあります。docker compose up -d の一発で全てが動き出します。

🎯 5W1H分析

Who（誰が）

Tada（Vuong）です。最初は自分のために作りましたが、今では友達のスタートアップチームのインフラとしても使っています。セルフホスターや、RAMの1メガバイトまで気にするような安いVPSで運用している小さなチームには、共感していただけるかもしれません。

ちなみにドメインの話です。v4.io.vn — これは v[uong] = v4です。自分の名前をドメインハックにしました。

What（何を）

Tada Cloudは、私の個人クラウドインフラ全体をコードとして定義したものです。Docker Composeファイル、環境設定ファイル、初期化スクリプトで構成されています。提供するもの：

共有のPostgreSQL、MySQL、Valkey（Redis互換）インスタンス — アプリごとにデータベースを重複させません
Docker Socketを監視して新しいアプリを自動検出するNginxリバースプロキシ
Let's Encrypt SSLの自動化 — 環境変数を2つ設定するだけでHTTPS化になります
Zitadelによる一元的なSSO認証 — 全アプリに一度のログインでアクセスできます
自作のRustログアウトサービス — 誰も解決していなかったクロスアプリログアウトのために作りました
12個以上のセルフホストアプリ（増加中）

When（いつ）

週末プロジェクトとして始まりました。しかし、週末プロジェクトでは終わりませんでした。現在は24時間365日本番稼働しており、個人利用を超えて友人のスタートアップチームを支えるインフラにまで成長しています。v4.io.vn のインスタンスは自宅ルーターを直接指しているテスト/開発環境（ハッキングしないでください）で、自由に実験してものを壊しています。本番環境は Cloudflareトンネル の背後にある安価なVPS上で独自ドメインで運用しており、Headscale（WireGuardによるVPNアクセス）、Appwrite（開発チーム向けBaaS）、Plane（プロジェクト管理）など、よりチーム向けのツールを追加しています。

チームの誰かが何かを必要とするたびに、あるいは面白いものを見つけて「15分でデプロイできそうだな」と思うたびに、新しいアプリを追加しています。

Where（どこで）

すべて Linuxサーバー（Fedora）上で動いています。AMD GPU（ROCm）によるML推論、動画トランスコード、PDFレンダリングにも対応しています。全サービスはDockerでコンテナ化され、v4.io.vnでHTTPS配信されています（tada.io.vn は認証サービスのエイリアスです。ドメインが1つで十分なのに、なぜ2つ持つかって？持てるからです）。

Why（なぜ）

このプロジェクトを始めた動機は、シンプルな算数です。

一般的なセルフホストアプリは、自前のPostgreSQL（約200〜500MB）、自前のRedis（約50〜100MB）、自前のWebサーバーを実行します。12個のアプリで掛け算すると、インフラの重複だけで3〜7GBのRAMを消費します。個人サーバーには馬鹿げています。

Tada Cloudはこのモデルを逆転させます：

データベースとキャッシュを共有 — PostgreSQL1つ、Valkey1つで終わります
コマンド1つ（docker compose up -d）で全てが起動します
ログイン1回（Zitadel SSO）で全アプリにアクセス — パスワード疲れとはおさらばです
SSL完全自動化 — 新しいアプリは自動でHTTPS化されます
1行追加でアプリ追加、1行削除でアプリ削除できます

How（どのように）

フローは驚くほどシンプルです：

インフラが最初に起動 — PostgreSQL、Valkey、Nginxプロキシ、Zitadel、ログアウトサービスが起動し、専用Dockerネットワークを作成します
アプリが共有ネットワークに接続 — 各アプリのComposeファイルが必要なインフラ（例：infra-postgres、infra-valkey）を宣言し、コンテナ名でサービスと通信します
Nginxがアプリを自動検出 — VIRTUAL_HOST=myapp.v4.io.vn を持つコンテナを配置するだけでNginxが自動設定します。設定ファイルの編集は不要です
ACMEコンパニオンがSSLを処理 — LETSENCRYPT_HOST を検出し、証明書を取得し、永続的に更新します。証明書のことは文字通り考えなくてもいいです
ZitadelがSSOを提供 — Homarr、Forgejo、Nextcloud、Immichが一つのIDプロバイダーで認証されます
ログアウトサービスがセッションを整理 — 自作のRustサービスが「ログアウト」を「本当に全てからログアウト」にします。「IDプロバイダーからだけログアウトして、他の11個のアプリにはログインしたまま」ではありません
Forgejo Actionsがスタックをデプロイ — リポジトリにプッシュすると、CIパイプラインがサーバーにSSHして docker compose pull && docker compose up -d を実行します

🏗️ アーキテクチャ / 設計

全体像

                          ┌─────────────────────────────────────┐
                          │         Internet (that's you!)      │
                          └──────────────┬──────────────────────┘
                                         │ :443
                          ┏━━━━━━━━━━━━━━▼━━━━━━━━━━━━━━━━━━━━━━┓
                          ┃           Home Router               ┃
                          ┃   (Configured with Dynamic DNS)     ┃
                          ┗━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┛
                                         ┃
                          ┌──────────────▼──────────────────────┐
                          │    nginx-proxy + acme-companion     │
                          │ (auto-discovery, SSL termination,   │
                          │   HTTP/3, gzip, reverse proxy)      │
                          └──────┬───────┬───────┬──────────────┘
                                 │       │       │
           ┌─────────────────────┘       │       └─────────────────────┐
           ▼                             ▼                             ▼
  ┌─────────────────┐          ┌──────────────────┐          ┌──────────────────┐
  │   Applications  │          │   Auth Services  │          │  Logout Service  │
  │   (12+ apps)    │          │   (Zitadel SSO)  │          │  (Rust, Valkey)  │
  └─┬──────┬──────┬─┘          └─┬──────────────┬─┘          └───────┬──────────┘
    │      │      │              │              │                    │
    │      │      │              │              │                    │
    │      │      └──────────────┼────────┐     │     ┌──────────────┘
    │      └────────────┐        │        │     │     │
    ▼                   ▼        ▼        ▼     ▼     ▼
┌───────┐          ┌──────────────┐    ┌────────────────┐
│ MySQL │          │  PostgreSQL  │    │     Valkey     │
│       │          │ (+ pgvector) │    │ (Shared Inst.) │
└───────┘          └──────────────┘    └────────────────┘

ネットワーク分離（別名「アプリ同士が盗み見できない仕組み」）

各インフラサービスは独自のDockerネットワークを持ちます：

ネットワーク	用途	接続するサービス
`infra-nginx-proxy`	HTTPルーティング & SSL	全アプリ、Zitadel、ログアウトサービス
`infra-postgres-*`	PostgreSQLアクセス	Zitadel（認証用）、アプリ（全て）**
`infra-mysql-*`	MySQLアクセス	アプリ（必要なもののみ）
`infra-valkey-*`	キャッシュ & セッション	Zitadel、アプリ（全て）、ログアウトサービス
`infra-zitadel`	OIDC/OAuth2認証	SSO対応アプリのみ

**接続の詳細：

Zitadel: PostgreSQL + Valkey（OIDC認証とセッション管理用）
アプリケーション: 全アプリはPostgreSQL + Valkey に接続します。Invoice Ninjaなど必要なアプリは MySQL にも接続します
ログアウトサービス: Valkey にのみ接続（セッションクリーンアップ用）

IT-Toolsは静的サイトなので infra-nginx-proxy だけです。Nextcloudはフルスタックが必要なので複数のネットワークに接続します。どのアプリも、アクセス権のないデータベースに（偶然にも悪意を持っても）接続することはできません。

ディレクトリ構成

tada-cloud/
├── docker-compose.yml              # メインオーケストレーター（includeディレクティブ）
├── compose/
│   ├── infrastructure/
│   │   ├── db/                     # PostgreSQL, MySQL
│   │   ├── cache/                  # Valkey
│   │   ├── proxy/                  # nginx-proxy, acme-companion, logout-service
│   │   └── auth/                   # Zitadel
│   └── apps/
│       ├── _template/              # 新規アプリ用テンプレート
│       ├── homarr/                 # ダッシュボード
│       ├── immich/                 # 写真管理
│       ├── forgejo/                # Gitホスティング
│       ├── nextcloud/              # ファイル同期 & オフィス
│       ├── invoiceninja/           # 請求書管理
│       └── ...                     # 他7個のアプリ
├── config/                         # ランタイム設定ファイル
├── envs/                           # 環境変数ファイル（シークレット）
├── init-db/                        # データベース初期化スクリプト
└── data/                           # 永続ボリューム

「一つのファイルで全てを支配する」パターン

ルートの docker-compose.yml は笑えるほどシンプルです — include ディレクティブのリストだけです：

include:
  # インフラ
  - compose/infrastructure/db/postgres/docker-compose.yml
  - compose/infrastructure/cache/valkey/docker-compose.yml
  - compose/infrastructure/proxy/nginx-proxy/docker-compose.yml
  - compose/infrastructure/auth/zitadel/docker-compose.yml

  # アプリケーション
  - compose/apps/homarr/docker-compose.yml
  - compose/apps/immich/docker-compose.yml
  - compose/apps/forgejo/docker-compose.yml
  # ... 他のアプリ

新しいアプリを追加したいですか？Composeファイルを書いて、ここに1行追加するだけです。削除したいですか？1行消すだけです。Kubernetesもいりません、Helmチャートもいりません、YAMLの悪夢もありません（まあ、YAMLではありますが、管理可能な YAMLです）。

⚙️ 技術スタック

レイヤー	技術	選定理由（本音）
オーケストレーション	Docker Compose（`include`付き）	シンプル、宣言的、12個のアプリにKubernetesは不要
リバースプロキシ	nginx-proxy + acme-companion	コンテナを自動検出してSSL処理 — Nginx設定を触ることがない
データベース	PostgreSQL（pgvector付き）	実績十分、pgvectorでImmichがベクトル検索をネイティブに実行可能
データベース	MySQL	Invoice Ninjaが要求するから（全戦全勝とはいかない）
キャッシュ	Valkey（Redisフォーク）	Linux Foundation管理のRedisフォーク — 同じAPI、ライセンス問題なし
認証	Zitadel	OIDC/OAuth2/SAML完全対応、セルフホスト可能、管理UIが実際に使いやすい
ログアウトサービス	自作Rustバイナリ	クロスアプリログアウトを誰も解決していなかったから自分で作った
SSL	Let's Encrypt（ACME）	無料、自動化、存在すら忘れる（それが狙い）
GPU	AMD ROCm	ML推論、動画トランスコード、PDFレンダリング — 1つのGPUで複数アプリ
プロトコル	HTTP/3（QUIC）、TLS 1.3	モダンなクラウドをレガシープロトコルで配信する理由がない

✨ 主要機能

共有インフラ — これこそが核心

12個のPostgreSQLコンテナがRAMを食い尽くす代わりに：

共有PostgreSQL1つで全アプリに対応します — アプリあたり約200〜500MBのRAM節約
Valkeyキャッシュ1つでアプリごとのRedisを置き換えます — さらにアプリあたり約50〜100MB節約
Nginxプロキシ1つで全てを自動検出します — 設定ファイル不要、リロードコマンド不要

計算してみましょう：12アプリ x 約300MB節約 = 約3.6GBのRAMを無駄にしていません。サーバー1台分のリソースに相当する余裕です。

🔐 協調型クロスアプリログアウト — 自分で作らざるを得なかった機能

これが一番誇りに思っている機能であり、同時に一番作らなければならなかったことに苛立っている機能でもあります。

問題はこうです：ZitadelでSSOを設定して、全てうまくいきます。ユーザーは一度ログインすれば全アプリにアクセスできます。素晴らしいです。そしてユーザーが「ログアウト」をクリックすると……Zitadelからだけログアウトされます。各アプリのセッションCookieはValkey内にそのまま残ります。ユーザーはログアウトしたと思っていますが、実際にはログアウトしていません。これはセキュリティ上の悪夢です。

既存のソリューションではこの問題を適切に処理できなかったので、Rustでログアウトサービスを書きました：

auth.v4.io.vn/logout でログアウトリクエストを受信します
ドメインとサービスの対応表（domains.yaml）を読み取り、アクティブなアプリを特定します
登録済みの全アプリにわたって、Valkey内のユーザーセッションを一掃します
カスタムログアウト処理が必要なアプリ向けに、アプリごとのクリーンアップルーティン（cleanup.yaml）を実行します

ログアウトすれば、本当にログアウトされます。全てのアプリから。確実に。

🌐 HTTP/3（QUIC） — もう2015年ではありません

セルフホスト型プラットフォームの大半は、まだHTTP/2-on-TCPで全てを配信しています。Tada Cloudは全アプリでHTTP/3（QUIC）をデフォルトで有効化しています。なぜこれが重要でしょうか？

0-RTT接続再開 — リピーターはTLSハンドシェイクを完全にスキップします。ページがただ…表示されます。
接続マイグレーション — アップロード中にWi-Fiからモバイルデータに切り替えても、接続が維持されます。Immichへの写真アップロードやNextcloudのファイル同期に革命的です。
ヘッドオブラインブロッキングなし — HTTP/2とは異なり、パケットが1つドロップしても他の並列リクエストがフリーズしません
Mozilla-Modern TLSポリシー — TLS 1.3のみ、レガシーな暗号スイートなし、妥協なし

🔑 シングルサインオン（SSO） — 自前のGoogleアカウント、でも所有権は自分にある

Googleの仕組みを考えてみましょう。Googleアカウントに一度ログインすれば、Gmail、Drive、YouTube、Calendar — 全てに即座にログインされます。サービスごとに別々のアカウントを作る必要はありません。ログアウトすれば、全てからログアウトされます。

Tada Cloudはまさにそれと同じことをしています — ただし、セルフホストで、自分のコントロール下で。

Zitadelが中央のIDプロバイダー（Googleのアカウントシステムのようなもの）として機能し、全アプリがOIDC/OAuth2で接続します：

登録は一度だけです — Zitadelでアカウントを一つ作れば、全アプリで存在します。サービスごとの「アカウント作成」フローは不要です。新しいチームメンバー？アカウント1つで、即座に全てにアクセス可能です。
ログインは一度だけです — auth.v4.io.vn でサインインすれば、Homarr、Forgejo、Nextcloud、Immich — 全てで認証済みです。12個の異なるパスワードを覚える必要はもうありません。「このサービスにはどのメールアドレスを使ったっけ？」ももうありません。
ログアウトは全アプリからです — ログアウトをクリックすれば、自作のRustサービスが全アプリのセッションを一掃します（Googleがうまくやっている部分ですが、ほとんどのSSO環境では完全に失敗しています — 上記セクション参照）。
ロール管理ができます — Zitadelの管理パネルで、誰が何にアクセスできるかを管理できます。開発者にForgejoとPlaneへのアクセスを与えたいがImmichは不要ですか？完了です。誰かの全アクセスを取り消したいですか？ワンクリックです。Google WorkspaceやOktaに期待するような一元的なユーザー管理 — ただし自分のサーバーで動き、月額は0ドルです。

Googleとの違いは？データは自分のもの、インフラは自分のもの、ベンダーロックインはありません。 仮にZitadelが明日消えても、別のOIDCプロバイダーに差し替えるだけです。Googleでそれをやってみてください。

GPU高速化 — 1つのGPU、複数のジョブ

AMD ROCmにより、Immichが写真のAI認識、Stirling-PDFがドキュメントレンダリング、ConvertXがファイル変換 — 全て同じGPUで実行されます
これらのワークロードはバースト的で、めったに重ならないため、共有は実用的に問題ありません

モジュール式の追加/削除 — 簡単すぎるくらい簡単

アプリテンプレート（compose/apps/_template/）があるので、ゼロから始める必要がありません
アプリ追加 = Composeファイルを書く + include 行を1つ追加します
アプリ削除 = include 行を1つ削除します
新しいアプリの追加にかかる時間：大体15分以内です

🚀 実装の詳細

データベース初期化 — 手動SQLセッション不要

毎回SSHで入って CREATE DATABASE を手動実行する代わりに、init-db/apps/<app-name>/ にあるSQLの初期化スクリプトを使います：

docker exec -i postgres psql -U postgres < init-db/apps/my-app/init.sql

シークレットの分離

シークレットは設定から厳密に分離されており、ディレクトリ構成はCompose構成をそのまま反映しています：

envs/
├── infrastructure/db/postgres/.env       # DBのルートパスワード
├── infrastructure/cache/valkey/.env      # キャッシュのパスワード
├── infrastructure/auth/zitadel/.env      # OIDCシークレット
└── apps/immich/.env                      # アプリ固有のシークレット

各Composeファイルは必要な環境変数ファイルだけを読み込みます。ImmichはForgejoのシークレットを読めません。ForgejoはNextcloudのシークレットを読めません。シンプルで、効果的です。

Nginxチューニング — 「スマホから4K動画をアップロードする」ための設定

デフォルトのNginx設定では、ImmichやNextcloudに投げるようなメディアファイルには対応できません。そこで：

CLIENT_MAX_BODY_SIZE=0 — アップロードサイズ制限なし（ゼロは「無制限」を意味します）
600秒のタイムアウト — 大きな動画のアップロードが途中で切断されません
巨大なプロキシバッファ（128 x 256KB） — ストリーミングレスポンスがカクつきません
gzip圧縮、ファイルキャッシュ、TCP最適化 — 定番のパフォーマンス改善
JSONログ — アクセスログをgrepで探すのは辛すぎるからです

📚 学んだこと

インフラ共有は正解でした。 RAM節約だけでプロジェクト全体を正当化できます。docker compose up -d 一発でクラウドが手に入ります。美しいです。
Docker Composeの include は過小評価されています。 みんなKubernetesの話をします。Composeの include がモジュール性、構成可能性、シンプルさを一つのパッケージで提供してくれることは誰も話しません。個人規模のホスティングには最適なツールです。
SSOは設定の苦労に見合います。 各アプリのOIDC設定は面倒です。でも一度やれば？全てに一度のログインでアクセスできます。迷わずもう一度やります。
ログアウトはログインの10倍難しいです。 「ログアウト」をちゃんと動かすためだけにRustのカスタムサービスを書くことになるとは、本気で思っていませんでした。でも現実はそうでした。SSOプロバイダーはログインを解決します。ログアウトには手を出しません。理由がやっとわかりました。
ネットワーク分離はタダのセキュリティです。 サービスごとのDockerネットワークは、アプリが侵害されても全データベースへのアクセスを許しません。設定コストはゼロですが、全てを救える可能性があります。
1つのGPU、複数アプリ、問題ゼロです。 バースト的なMLワークロード + バースト的なレンダリングワークロード = 実際にはほぼ競合なしです。共有は機能します。

🔮 今後の予定

進行中

docker-mailserver — スタートアップチーム向けのセルフホストメール。全てをセルフホストしているのにGmailに頼るのは違和感があります。現在DKIM/DMARC/SPFの設定と格闘中です。
Fail2ban — 侵入防止です。v4.io.vn のインスタンスは自宅ルーターを指しています（覚えていますか？）。SSHへのブルートフォースやログインページへのスパムを自動でBANするのは任意ではありません — 生存戦略です。
oauth2-proxy — アプリの前に配置する認証リバースプロキシで、1バイトも届く前にZitadel SSOログインを強制します。

TODO

自動バックアップ — PostgreSQLとValkeyの定期ダンプとオフサイトレプリケーション。現在は手動でバックアップしています。つまり「たまに」ということです。
モニタリングスタック — Prometheus + Grafana。ダッシュボードを眺める代わりに、全てうまくいっていることを祈るだけの現状を脱却したいです。
ヘルスダッシュボード — 全サービスのヘルスチェックをHomarrに統合して、一目でステータスを把握できるようにしたいです。