push → edge
GitOps Deployment Pipeline

コードを push する。
数十秒後、世界に出る。

GitHub と Cloudflare Workers をつなぐ初期設定ガイド。一度組めば、あとは git push するだけで、自動ビルド・デプロイが走り、独自ドメインには常に最新版が映ります。

Deploy pipeline
STAGE 01
LOCAL
コード編集
STAGE 02
GITHUB
git push
STAGE 03
CLOUDFLARE
build & deploy
STAGE 04
DOMAIN
独自ドメインで公開

What you get

この構成でできること

接続方式は2通りありますが、設定が最も簡単な Workers Builds(Cloudflare 純正の Git 連携) を推奨構成として解説します。API トークンの管理が不要で、ダッシュボード操作だけで完結します。

01

push が唯一のトリガー

本番ブランチへの push を検知して自動でビルド・デプロイ。手動のデプロイ作業がなくなります。

02

独自ドメインに自動反映

ドメインは常に最新の本番デプロイを指すため、ビルド完了後そのまま反映されます。

03

GitHub で状態確認

デプロイの成否はコミット横のチェックに表示。画面を離れずに監視できます。

Prerequisites

前提条件

項目内容
GitHub アカウントリポジトリを作成できること
Cloudflare アカウント無料プランで可
独自ドメインCloudflare の DNS(ゾーン)配下にあること。 ネームサーバーを Cloudflare に向けて移管済みである必要があります
Node.jsLTS 版を推奨。node -v で確認
Gitgit --version で確認
*.workers.dev のサブドメインだけで試す場合、独自ドメインの前提は不要です。

Setup · 6 steps

構築手順

上から順に進めれば、push するだけで本番反映される状態が完成します。

01

ローカルで Worker プロジェクトを作成

Cloudflare 公式のスキャフォールドツール(C3)で雛形を生成します。対話プロンプトでテンプレートと TypeScript の利用有無を選ぶと、設定ファイル wrangler.jsonc を含むプロジェクトが作られます。

bash
npm create cloudflare@latest your-app
cd your-app

静的ファイル(HTML/CSS/JS)も配信する場合は、アセット用ディレクトリを指定します。

wrangler.jsonc
{
  "name": "your-app",
  "main": "src/index.ts",
  "compatibility_date": "YYYY-MM-DD",  // 作成日を入れる
  "assets": { "directory": "./public" }
}

ローカル確認は npx wrangler dev で行えます。

02

Git を初期化し、GitHub へ push

GitHub 側で空のリポジトリを1つ作成しておきます。

bash
git init
git add -A
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/your-account/your-repo.git
git push -u origin main
重要: 機密値(API キー・パスワード等)や .env / .dev.vars をコミットしないこと。.gitignore.dev.vars*.env* を追加しておきます。
03

Cloudflare と GitHub を連携する

Cloudflare ダッシュボードで Workers & PagesCreate applicationImport a repository の順に進み、Git アカウントを選択します。初回は GitHub アプリ「Cloudflare Workers and Pages」の認可を求められます。続いてデプロイ対象のリポジトリを選択します。

セキュリティ: 認可時は「Only select repositories」を選び、ビルド対象のリポジトリだけにアクセスを限定します。全リポジトリへの許可は避けてください。

設定ファイルが無いリポジトリを接続した場合、Cloudflare がフレームワークを自動検出し、設定を追加する Pull Request を自動作成します。C3 で雛形を作っていれば設定済みのため不要です。

04

ビルド / デプロイ設定

接続時の設定画面で以下を指定します。

設定項目値の例備考
Production branchmainこのブランチへの push がトリガー
Build commandnpm run buildビルド不要なら空欄でも可
Deploy commandnpx wrangler deploy既定値のまま使えることが多い

Save and Deploy を選択すると、初回ビルドとデプロイが走ります。

05

初回デプロイを確認

完了すると https://your-app.<your-subdomain>.workers.dev の URL が払い出されます。ブラウザでアクセスして動作を確認します。ビルドログは Deployments タブ最下部の View build history から見られます。

06

独自ドメインを割り当てる

「独自ドメインで即確認」の核心です。対象ドメインが Cloudflare のゾーン配下にあることが前提です。対象の Worker を開き、Settings → Domains & Routes → Add → Custom Domain から使用するホスト名(例:app.example.com)を入力して保存します。

Cloudflare が必要な DNS レコードと TLS 証明書を自動で発行・設定します。以降、このドメインは常に最新の本番デプロイを指すため、push → ビルド完了 → 自動反映のループが完成します。

初回アクセスで DNS エラーが出る場合は、伝播待ち(数分)か、別端末・別回線で再確認してください。

Daily flow

日常の運用フロー

構築後は、これだけで本番が更新されます。デプロイの成否は GitHub のコミット横のチェックから確認できます。

— terminal —
# ローカルでコードを編集
$ git add -A
$ git commit -m "Update layout"
$ git push
# → 数十秒〜数分後、独自ドメインに自動反映

Optional

環境変数・Secrets・データベース

Worker に値を渡す3つの方法

種類中身Git に載るか用途
vars(変数)平文の設定値載るAPI ホスト名など、秘密でない設定
Secrets暗号化された秘密文字列載らないパスワード・API キー・外部 DB の接続文字列
BindingsCloudflare リソースへの参照参照情報は載るD1・KV・R2 などへの接続

機密値はコードや設定ファイルに書かず、Secrets として登録します。コードからは環境変数として読めます。ローカル開発用の値は .dev.vars に記述し、必ず Git 管理から除外します。

bash
npx wrangler secret put SECRET_NAME
# → 値の入力を求められる。値はリポジトリに残らない

データベース(D1)を使う

リレーショナル DB が必要なら、Cloudflare 純正の D1(サーバーレス SQLite)が最も手軽です。DB は Secrets ではなく バインディングで接続するため、パスワード管理は不要です。

bash
npx wrangler d1 create your-db

出力された database_idwrangler.jsonc に追記します(ID は秘密情報ではないため Git に載せて問題ありません)。

wrangler.jsonc
{
  "d1_databases": [
    { "binding": "DB", "database_name": "your-db", "database_id": "..." }
  ]
}
再デプロイで DB の中身は消えません。 push で入れ替わるのは Worker のコードだけで、バインディング先のデータは保持されます。
コストの注意点: D1 は「読み取り行数=スキャンした行数」で課金されます。無料枠(目安:5GB/読み取り500万行・書き込み10万行 per day)の範囲なら小規模アプリは無料ですが、インデックスのないクエリで全件スキャンが多発するとコストが膨らみます。頻出クエリには必ずインデックスを張ってください。

Troubleshooting

動作確認とトラブルシュート

症状確認ポイント
push してもデプロイされないpush 先ブランチが Production branch と一致しているか
ビルドが失敗するDeployments → ビルドログでエラー内容を確認
独自ドメインで表示されないドメインが Cloudflare ゾーン配下か/DNS 伝播待ち
Secrets が読めないwrangler secret put で登録済みか、名前が一致しているか

Best practices

セキュリティのベストプラクティス

  • GitHub アプリのアクセス範囲は「Only select repositories」で対象リポジトリのみに限定する
  • 機密値(API キー・トークン・DB 認証情報)はソースコードや wrangler.jsonc に絶対に書かずwrangler secret put で登録する
  • .dev.vars / .env.gitignore に追加し、コミットしない
  • 本番・ステージング・開発で別々の値を使う場合は、環境(environments)ごとに Secrets を分離する

Appendix

代替方式:GitHub Actions を使う

CI 内でテストや Lint を挟みたい場合は、Workers Builds の代わりに GitHub Actions + 公式アクションでデプロイできます。この場合は Cloudflare の API トークンを GitHub Secrets に登録する必要があります。

.github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
API トークンはリポジトリに直書きせず、必ず GitHub の Secrets 機能に保存してください。トークンのスコープは、デプロイに必要な権限に限定して発行します。

まずは Workers Builds で運用を始め、CI に独自処理を足したくなった段階で Actions へ移行するのが無理のない流れです。