Cloudflare Workers の運用方法、なんとなくわかってきた(GitHub 連携抜き)

どうも白澤です。最近はバタバタ気味で夏を感じています。
前回の記事で Cloudflare Pages から Cloudflare Workers への移行について書きました。
正直なところ、前回の記事を書いた時点ではドキュメントを漁りきれていなかったこともあり、いまいち「こういったことをしたい時どうするんだろう?」みたいなことがよくありました。
現時点でも Pages の時にできていたことを Workers でどう実現するか、ということはまだまだわからないことが多いのですが、少しずつわかってきたこともあるので、メモとして残しておきます。
ステージング(プレビュー)環境の運用
Pages の時は GitHub と連携させて、PR を作成すると自動的にブランチ名から生成されるサブドメインでステージング環境が作成されていました。
また、それは 1 つの Pages プロジェクト内で完結していて、環境としては production (main) と staging (main 以外) がありました。環境変数はその 2 つの環境で分けて設定できていました。
Workers ではこれをどうするか、というのが前回の記事を書いた時点で感じていた課題でした。
結論として Workers では wrangler.json
に複数の環境を定義することができ、各環境ごとに異なる設定を行うことができるようになっています。
{
"$schema": "node_modules/wrangler/config-schema.json",
"assets": {
"directory": "./dist"
},
"compatibility_date": "2025-04-11",
"compatibility_flags": ["nodejs_compat"],
"env": {
"production": {
"name": "PROJECT_NAME-production",
"observability": {
"enabled": true
},
"preview_urls": false,
"r2_buckets": [{ "binding": "R2_BUCKET", "bucket_name": "BUCKET_NAME" }],
"routes": [{ "custom_domain": true, "pattern": "example.com" }],
"workers_dev": false
},
"staging": {
"name": "PROJECT_NAME-staging",
"observability": {
"enabled": true
},
"preview_urls": true,
"r2_buckets": [{ "binding": "R2_BUCKET", "bucket_name": "BUCKET_NAME" }],
"workers_dev": false
}
}
}
ざっくりですがこの記事を書いている時点ではこんな感じで設定をしてみています。(Astro をデプロイする場合の例)
name
や routes
, preview_urls
などほとんどの設定は env
以下に定義することができ、env
の外に書いたものは全ての環境で共通の設定になります。つまり env
内に書いたものはその環境用に上書きすることもできるということです。
ただし最初に自分が気になっていたのは、デプロイすると env
ごとに Worker が作成されてしまう点でした。
bun run deploy --env=staging
のようにすると PROJECT_NAME-staging
のような Worker が作成されます。Pages ではプロジェクトは 1 つで環境ごとの設定はそのプロジェクト内で完結していたので、初見でこの挙動に戸惑いました。
これ「環境複数立てたい場合は Worker がいっぱいになるじゃんね?」と思ったのですが、これは Google Gemini の Deep Research に聞いてみた結果だと、どうやら意図的な仕様のようでした。Gemini に作成させたレポートが結構長かったので、音声解説を生成してもらいました。
Cloudflare Workers「環境」機能:意図された分離で実現する安全なマルチ環境管理と wrangler.toml 活用術
ざっくりな話としては設計による分離によるもので、環境ごとに Worker を分けることで、各環境の設定やコードを明確に分離し、誤って本番環境に影響を与えることを防ぐためのものだそうです。これで納得がいきました。
Astro の運用
Astro は割とシンプルなので、Workers まわりの運用が楽です。GitHub Actions で main への push をトリガーにデプロイするのも比較的簡単にできました。
steps:
- uses: actions/checkout@v4
- uses: oven-sh/setup-bun@v2
with:
bun-version: 1.2.11
- name: Install dependencies
run: bun install
- name: Build Astro site
run: bun --bun run build
- name: Deploy
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: deploy --env=production
steps
のみを記載しましたが、これだけで main への push で自動的にデプロイされます。
Next.js (OpenNext) の運用
OpenNext はどうしても Next と OpenNext の二段階ビルドしたりとちょっと複雑なので、現時点ではデプロイしたいタイミングでコマンドを叩く運用にしています。
{
"scripts": {
"build": "next build",
"deploy": "opennextjs-cloudflare build && opennextjs-cloudflare deploy",
"upload": "opennextjs-cloudflare build && opennextjs-cloudflare upload"
}
}
bun run deploy -- --env={production|staging}
今後 CI での自動デプロイしたいなと思っていますが、まだそこまで手が回っていません、、、
Observability が便利
wrangler.json
で設定できますが、observability
を有効にしておくと、Workers の実行ログを Cloudflare のダッシュボードから確認できるようになります。これが結構便利というか、ちゃんと動きを追えるので助かります。特に Workers 移行時のサイズ制限のために Sentry を一旦剥がしていたりするので、エラーを確認したい時にここを確認できるだけでも全然違います。
{
"observability": {
"enabled": true
}
}
アクセスログみたいな感じで見られるのですが、見事にサイトが攻撃されているのも確認できました。
PHP とか WordPress だと思われているのか .php ファイルや /wp-admin/
へのアクセスが多いです。ちなみに攻撃されているサイトは Next.js でできているサイトです。残念でしたーとしか言いようがない。
ということで、Cloudflare Workers の運用方法について、少しずつわかってきたことをメモとして残しておきました。他にもなにかわかったことがあれば新しく記事にしていきたいと思います。