Tesujiつながりから、次の一手を
人・AI・サービスが、ひとつのネットワークでつながる

出会い、知恵、仕事がつながり、次の一手を生み出す。

公開

Cloudflare × Supabase × GitHub：小さなチームでWebサービスを速く出し、壊れたときに戻せる構成

変更履歴

フロント配信・API・DB・認証・変更履歴をCloudflare、Supabase、GitHubへ役割分担し、少人数でもリリース速度と保守性を両立する基本構成を理解する。

この記事をシェア

Xでシェア

小さなチームのインフラは「高性能」より「判断箇所が少ない」方が強い

新しいWebサービスを作るとき、技術選定をやりすぎると、サービスを作る前に運用対象が増えます。

  • Webサーバー
  • APIサーバー
  • DB
  • 認証
  • ファイルストレージ
  • CDN
  • DNS
  • CI/CD
  • 監視

少人数チームでは、1つずつ最高の製品を選ぶより、誰がどこまで責任を持つかが明確な構成の方が長期的に扱いやすいことがあります。

ここでは、

  • Cloudflare：配信、DNS、エッジ実行
  • Supabase：PostgreSQL、認証、ストレージなどのバックエンド基盤
  • GitHub：ソースコード、レビュー、変更履歴

という分担を考えます。

まず「正本」を3つに分ける

運用が壊れやすいのは、同じ情報の正本が複数になるときです。

この構成では、原則として次のようにします。

コードの正本

GitHub。

本番環境で直接コードを直さず、変更はbranch / commit / PRを通す。

データの正本

SupabaseのPostgreSQL。

ユーザー、サービス、投稿、状態など、永続化したい業務データを置く。

配信・入口

Cloudflare。

ドメイン、キャッシュ、静的配信、必要に応じてWorkersなどのエッジ処理を担当する。

この3つを混ぜないだけでも、障害時に「どこを見るか」が分かりやすくなります。

MVPでは構成を増やしすぎない

たとえば小さなWebアプリなら、最初は次で十分なことがあります。

Browser → Cloudflare → Web app / Worker → Supabase

コード変更は、

GitHub → CI/CD → Cloudflare側へ反映

という流れにします。

ここで重要なのは、将来の100万人ユーザーを想定して最初から複雑化しないことです。

必要になるまで、

  • Kubernetes
  • 独自認証サーバー
  • 複数DB
  • 複雑なmessage queue

などを増やさない。

MVPのインフラは、スケール性能より変更速度を買うものと考えます。

Supabaseへ置くもの、置かないもの

Supabaseが便利でも、何でもDBへ入れると後で困ります。

置くのに向いているのは、

  • ユーザーデータ
  • アプリ内の状態
  • 投稿やコンテンツ
  • 権限と所有関係
  • 永続的に検索したいデータ

です。

一方、

  • 一時的なビルド成果物
  • 巨大なログ全文
  • Gitで管理すべき設定
  • 秘密鍵そのもの

などは、別の管理方法を検討します。

「保存できるから保存する」ではなく、誰がいつ読むデータかで決めます。

Cloudflareへ置く処理の境界

エッジで実行できるからといって、すべてのビジネスロジックを置く必要はありません。

Cloudflare側には、

  • リクエスト入口
  • 軽量API
  • キャッシュ
  • 認証前後の薄い処理
  • 画像や静的アセット配信

など、入口に近い処理を置くと分かりやすいです。

一方、複雑なトランザクションやデータ整合性が必要なら、DB側の制約やサーバー側ロジックを含めて設計します。

重要なのは「どこで実行できるか」ではなく、どこを正本にすると事故が少ないかです。

GitHubでは「デプロイできる」より「戻せる」を重視する

自動デプロイは便利ですが、失敗時に戻せなければ怖くなります。

最低限、

  • mainへの変更はPR経由
  • migrationはコードと一緒にレビュー
  • どのcommitが本番か分かる
  • 直前リリースへ戻せる
  • secretsはリポジトリへ置かない

を守ります。

AIコーディングを使う場合はさらに、

  • 変更範囲
  • migration有無
  • 環境変数追加
  • 手動確認手順

をPRへ残すとレビューしやすくなります。

一番怖いのはDB migration

フロントコードは戻せても、DB schema変更は単純に戻せないことがあります。

たとえば、

  • カラム削除
  • 型変更
  • データ変換
  • unique制約追加

は既存データへ影響します。

安全側に寄せるなら、

  1. 新カラム追加
  2. アプリを両対応
  3. データ移行
  4. 利用確認
  5. 古いカラム削除

のような段階移行を考えます。

AIにmigrationを書かせる場合も、「SQLが通るか」だけでなく、既存データが残るかを完了条件にします。

障害時の切り分け順

この構成の良さは、問題の場所を分けやすいことです。

ページが開かない

Cloudflare側、DNS、デプロイ状態を確認。

APIは届くが500

Worker / API処理、Supabase接続、認証を確認。

保存だけ失敗

DB制約、RLS、migration、payloadを確認。

特定ユーザーだけ失敗

権限、所有者条件、データ状態を確認。

この切り分けが定型化されていると、少人数でも復旧が速くなります。

コストで見るときの注意

ServerlessやBaaSは初期コストを下げやすい一方、利用量が増えると課金構造が変わります。

そのため、

  • リクエスト数
  • DB容量
  • egress
  • ストレージ
  • 実行時間

は定期的に見る必要があります。

ただし、月数千円を削るために運用工数が月10時間増えるなら逆効果です。

小さなチームでは、**インフラ単価ではなく「人間の運用時間込みの総コスト」**で比べる方が現実的です。

どんなサービスに向いているか

この構成は、

  • SaaSのMVP
  • 社内ツール
  • 小〜中規模のWebサービス
  • 管理画面
  • コミュニティサービス
  • AI機能を含むWebアプリ

などと相性があります。

一方、特殊な長時間処理、GPU計算、非常に重いバッチ、大規模な独自ネットワーク要件がある場合は、別の実行基盤が必要になることがあります。

次の一手

新サービスを1つ作るなら、最初に技術を選ぶのではなく次を決めます。

  1. コードの正本はどこか
  2. データの正本はどこか
  3. 外部公開の入口はどこか
  4. schema変更をどう管理するか
  5. 1つ前の本番へどう戻すか

この5つが答えられるなら、構成はかなり健全です。

Cloudflare × Supabase × GitHubの価値は、派手な技術ではなく、少人数でも『作る・出す・戻す』を同じ型で回せることにあります。