1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PR: 株式会社なかのひとカンパニー
株式会社なかのひとカンパニーでは一緒に会社を創ってくれるメンバーを募集しています！
About Promotions
@archer2232
in

Cloudflare WorkersでNext.jsを動かしてみた【Cloudflare運用記録 #4】

1
Posted at

Cloudflare WorkersでNext.jsを動かしてみた【Cloudflare運用記録 #4】

はじめに

こんにちは。
なかのひとカンパニーの archer です。

前回は、Cloudflare Tunnelを使って自宅サーバーを外部公開する構成について書きました。

自宅サーバーでは、

Cloudflare
↓
Cloudflare Tunnel
↓
Nginx
↓
Docker
↓
Next.js

という構成でサービスを動かしていました。

これはこれで自由度が高く、面白い構成です。

ただ、Webサービスを公開することが目的なら、

そもそもサーバーを管理しなくてもいいのでは

と思うようになりました。

そこで使い始めたのがCloudflare Workersです。

今回は、Next.jsをCloudflare Workersで動かしてみて、自宅サーバーとの違いや、実際に感じたメリットについてまとめます。

サーバーを管理しない構成へ

自宅サーバーでは、アプリ以外にも管理するものがあります。

  • Proxmox
  • Ubuntu
  • Docker
  • Nginx
  • cloudflared
  • OSアップデート
  • ストレージ
  • サーバーそのもの

一方、Workersではかなりシンプルになります。

GitHub
↓
Build
↓
Cloudflare Workers
↓
利用者

自分でUbuntuを用意する必要はありません。

Dockerもありません。

Nginxもありません。

サーバーへSSHしてデプロイする必要もありません。

コードをCloudflare Workersで動く形にして、デプロイする。

インフラを触る楽しさは減りますが、

サービスを公開することだけを考えるなら、こちらの方がかなり楽でした。

Next.jsをそのまま置くわけではない

Next.jsは、そのままCloudflare Workersへコピーすれば動くわけではありません。

自分の環境では、

OpenNext

を使っています。

OpenNextはNext.jsのビルド結果を、Cloudflare Workersなどで実行できる形へ変換してくれます。

構成としては、

Next.js
↓
OpenNext
↓
Cloudflare Workers

というイメージです。

自分がサービスを構築したときは、この構成を採用しました。

現在はvinextが推奨されている

ここは少し注意が必要です。

2026年9月現在、Cloudflare公式では、新しくNext.jsアプリをWorkersへデプロイする場合は vinext が推奨されています。

一方、既存のOpenNext環境については引き続きドキュメントが提供されています。

そのため、

既存環境
→ OpenNextを継続

新規環境
→ vinextも検討

という考え方がよさそうです。

自分の環境はOpenNextで動いているため、この記事ではOpenNextを使った構成を紹介します。

OpenNextを入れる

既存のNext.jsプロジェクトへOpenNextを追加します。

pnpm add @opennextjs/cloudflare
pnpm add -D wrangler

Cloudflare Workersを操作するCLIがWranglerです。

以前の記事でも少し出てきましたが、

wrangler

を使って、

  • ローカル確認
  • 設定
  • デプロイ
  • Secrets
  • D1
  • R2

などを操作できます。

Wranglerを設定する

Cloudflare Workers側の設定を書きます。

たとえば以下のような形です。

{
  "name": "my-app",
  "main": ".open-next/worker.js",
  "compatibility_date": "2026-09-01",
  "compatibility_flags": [
    "nodejs_compat"
  ],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS"
  }
}

OpenNextで生成されたWorkerを、

.open-next/worker.js

から実行します。

また、Next.jsではNode.js向けのAPIを利用することがあるため、

nodejs_compat

も設定します。

OpenNextの設定

プロジェクト直下に、

open-next.config.ts

を作ります。

基本形はかなりシンプルです。

import { defineCloudflareConfig } from "@opennextjs/cloudflare";

export default defineCloudflareConfig();

ここから必要に応じてキャッシュなどを設定していきます。

BuildしてPreviewする

ローカルのNext.js開発では、

pnpm dev

を使います。

ただし、

Next.jsで動くことと、Workersで動くことは同じではありません。

そのため、本番へ出す前にWorkers向けのビルドでも確認します。

package.jsonに、

{
  "scripts": {
    "preview": "opennextjs-cloudflare build && opennextjs-cloudflare preview",
    "deploy": "opennextjs-cloudflare build && opennextjs-cloudflare deploy"
  }
}

のようなscriptを用意します。

そして、

pnpm preview

でWorkers環境に近い形で確認します。

自分の場合、

pnpm devでは動く
↓
Workers向けにBuild
↓
動かない

ということもありました。

そのため、

ローカルのNext.jsだけではなく、Workersとして動くか確認する

ことが重要でした。

デプロイはかなり簡単

確認できたら、

pnpm deploy

でCloudflare Workersへデプロイできます。

自宅サーバーの場合は、

SSH接続
↓
git pull
↓
Docker Build
↓
コンテナ再起動
↓
確認

という流れでした。

Workersでは、

Build
↓
Deploy

です。

さらにGitHub Actionsと組み合わせれば、

GitHubへpush
↓
CI
↓
Build
↓
Cloudflare WorkersへDeploy

まで自動化できます。

ここはCloudflareへ移して一番楽になった部分でした。

D1やR2もBindingで使える

Workersを使っていて便利なのが、Cloudflareの他サービスと組み合わせやすいことです。

たとえば、

Next.js
↓
Workers
├─ D1
└─ R2

という構成にできます。

D1をデータベース。

R2をファイルストレージ。

Workersをアプリケーション。

という形です。

自宅サーバーなら、

PostgreSQLをどこで動かすか
ファイルをどこへ保存するか
バックアップをどうするか

なども考える必要があります。

Cloudflareでは、それぞれをBindingとしてWorkerへ接続できます。

このあたりは、自宅サーバーからWorkersへ移して大きく考え方が変わったところでした。

サーバーレスでも制限はある

もちろん、Workersなら何でもできるわけではありません。

サーバーを管理しなくてよくなった代わりに、

Cloudflare Workersのルールの中で動かす

必要があります。

Freeプランでは、主に、

  • 100,000リクエスト / 日
  • CPU時間 10ms / リクエスト
  • メモリ 128MB
  • Workerサイズ 3MB（圧縮後）

などの制限があります。

普通のWebサービスなら十分なケースも多いですが、CPUを大量に使う処理には向きません。

つまり、

自宅サーバー
→ 自分で全部管理する代わりに自由

Workers
→ 管理は減る代わりにプラットフォームの制限がある

という違いがあります。

静的ファイルは少し扱いが違う

WorkersでNext.jsを動かした場合でも、すべてのアクセスが同じように課金対象になるわけではありません。

画像やJavaScript、CSSなど、Workers Static Assetsとして配信される静的ファイルへのリクエストは無料です。

一方、

SSR
API
Server Actions

など、実際にWorkerコードが動くリクエストはWorkersの利用量として考える必要があります。

Next.jsでは、

どのページが静的で、どのページでWorkerが動いているのか

を意識すると、料金や負荷も考えやすくなります。

今回使ったサービスの料金

Cloudflare WorkersにはFreeプランがあります。

2026年9月時点では、

100,000リクエスト / 日
CPU時間 10ms / リクエスト

までFreeプランで利用できます。

静的Assetsへのリクエストは無料・無制限です。

小さな個人サービスであれば、

月額0円から本番公開できる

というのはかなり魅力的です。

より多くのリクエストやCPU時間が必要になった場合はWorkers Paidがあります。

最低料金は、

月額 5ドル

です。

Paidでは月1,000万リクエストと3,000万CPUミリ秒が基本料金に含まれ、それを超えると従量課金になります。

個人的には、

まずFreeで公開
↓
実際に使われる
↓
必要になったらPaid

という流れにできることが、個人開発とかなり相性がいいと感じています。

※料金・無料枠・制限は2026年9月時点の情報です。
最新情報はCloudflare公式ドキュメントを確認してください。

自宅サーバーとWorkersはどちらがいいのか

両方使ってみて思うのは、

目的が違う

ということです。

自宅サーバーは、

  • Dockerを触りたい
  • Linuxを触りたい
  • インフラを勉強したい
  • 自由に構成したい

というときに面白いです。

Workersは、

  • Webサービスを早く公開したい
  • サーバー管理を減らしたい
  • GitHubから自動デプロイしたい
  • 小さく無料で始めたい

というときに便利です。

自分の場合、サービスそのものを作りたいときはWorkersを選ぶことが増えました。

まとめ

今回は、Next.jsをCloudflare Workersで動かす構成についてまとめました。

自分の環境では、

Next.js
↓
OpenNext
↓
Cloudflare Workers

という構成を使っています。

自宅サーバーと比べると、

  • Ubuntuを管理しなくていい
  • Dockerを管理しなくていい
  • Nginxを管理しなくていい
  • SSHでデプロイしなくていい
  • GitHubからデプロイしやすい
  • D1やR2と組み合わせやすい

という違いがありました。

一方で、WorkersにはCPU時間やリクエスト数などの制限があります。

つまり、

サーバー管理から解放される代わりに、Cloudflareというプラットフォームの中で設計する。

これがWorkersを使って一番感じた違いでした。

そして自分の場合、その制限よりも、

サービスを作って公開するまでが楽になるメリット

の方が大きく感じています。

次回は、

Cloudflare D1を個人開発で使ってみた

というテーマで、データベースについて書きます。

ローカルと本番の違い、Migration、無料枠、実際に使って感じた注意点などをまとめる予定です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?