Cloudflare WorkersでStaticSite + API (Hono)を公開する時に迷ったこと
はじめに
Cloudflare Pagesが非推奨になりCloudflare Workersを使おうね。 という昨今です。
Cloudflare PagesでStatic Siteを公開したことはあるが、Cloudflare Workersだと意外とググっても例が出てこない！困った！
そもそも公式のドキュメントを読むべきだけどStatic Site (+ ちょっとしたAPI)をホスティングする程度のことでガッツリ読み込むのも面倒くさい！
褒められた姿勢ではないですが、こうして臨んだ自分が迷ったことを書いておきます。
対象読者
- Cloudflare PagesやNetlifyやらGithub Pagesは使ったことはあるものの、Cloudflare Workersはまだな人
- フロントエンドに興味はないのに社内の事情でStaticSiteのデプロイ作業を拝命してしまった人
Pagesとのざっくりした違いは？
Cloudflare PagesはStatic Siteのホスティングがメインで、それにPages Functionsを添えて色々できるよ。といったサービスです。
Pages FunctionsはそもそもWorkersで動いています。
Cloudflare WorkersはメインがFunctionsもといCloudflareのエッジで動くサーバーレスJavaScript実行環境になります。
Static Siteもついでに配信できるよ。みたいなイメージです。
どこに料金がかかる？
めちゃくちゃ安く使わせて頂けるCloudflare Workersではありますが、一応自分の中で料金に関して明確にしておく必要がありました。
重ねて公式ドキュメントを見ろという話ではあります。
Honoでリクエストを捌いて返すような処理はやはりお金がかかります。
お金がかかると言っても潤沢な無料枠があるので多くのアクセスを想定しないサイトならあまり意識しないかもしれません。
一方でstatic assetsについては無料です。ええっ無料でいいの？！
Requests to static assets are free and unlimited.
static assetsというものは wrangler.json にて以下のように指定したものを指します。
"assets": {
"directory": "./dist",
"binding": "ASSETS"
}
古式ゆかしきレンタルサーバ (!= VPS) で ./public dirに "Hello world!" と書かれた index.html を置いて公開するようなシンプルなことをしたければ、上記の設定の上で ./dist/index.html みたいな配置をすれば確実に無料で済みます。
static assetsを使わずに、Honoを使って GET / に対してHTMLを返すこともできるけど、こっちは上述の話に当てはまり無料枠付きの有料になります。
デプロイがスムーズに出来すぎて怖い
プロジェクトを作ってコマンドラインから wrangler deploy して言われた通りにしていればヌルっと公開までいきます。怖い！
最初はCloudflareのGUIからポチポチしてGit連携でデプロイするよう設定すると安心かなと思いました。
これまたGUIが分かりやすいので、この規模感ならGUIでいいんじゃないかとIaCの精神の薄れてしまうのが恐ろしいところです。
GUIから設定した環境変数が消えてる！
GUIからGit連携することでデプロイできた。環境変数もGUIから設定した。
その後Git連携で指定したブランチに更新がかかり再度デプロイされて…… 環境変数が消えてる！！
環境変数をGUIから設定したい人は wrangler.json に "keep_vars" = true を書いておかねば同じ轍を踏むことになります。
Github Actionsで丁寧にデプロイワークフローを利用する時にはよくある素直な形で環境変数を渡せばいいんですが、Git連携でふわっとデプロイする場合はこの方法を取ることになるかと思います。
Github Actionsでデプロイワークフローを組む場合や他のケースの環境変数の管理についてはこちらの記事がわかりやすいです。
GUIから環境変数を設定するときにProduction/Previewでそれぞれに設定できない
Cloudflare Pagesではデプロイに際して利用する環境変数を含む諸々の設定値をProduction/Previewで分けることが出来ます。
ところがWorkersではそれが出来ないようです。(少なくとも2025/10/29時点では)
上記の話と被るところがありますが、現状この手のケースではGithub Actions等を使うことになりそうです。
せっかくなのでTurnstileを導入しようとしたがデザインに合わない
Formのsubmitを受け取るようなエンドポイントやbotを防ぎたいページには特に便利な話でCAPTCHAに代わる検証ツールとしてCloudflare Turnstileという素晴らしいサービスが無料で提供されています。
簡単に導入してスパムがいい感じに防げるようになります。
※ ここではWidgetについてのみ触れます
ただ、これを導入するとWeb上にガッツリとTurnstileのバナー/ラベルが埋め込まれることになり、デザインによっては調整が必要になります。
最初からTurnstileが入るようなデザインのサイトとして考えておけるといいんですが……。
サイトの背景色が派手な色だったりするとTurnstileの埋め込みがだいぶ浮いてしまいます。
埋め込みについてオプションでスタイルのLight/Darkを調整したりサイズを変えたり出来ますが柔軟性があるものではないです。
EnterpriseプランになるとCloudflareのロゴを消したり出来るようですが、なかなかそこまではいきませんね。
おわりに
Cloudflare Workersを恐れることはありません！
Gitと連携した簡単なデプロイも思うとレンタルサーバの時代からは大きく変わったなぁと思います。
「いまGithub Pagesを使ってるけどちょっとAPI生やしたいんだよな〜！でもAWS/GCP使うほどの温度感ではないんだよな〜！」という人には特におすすめです。Hono最高！
Discussion