Q.EmDashはCloudflareに依存しないと使えないのですか？

Node.jsが動くサーバーであれば、Cloudflare以外でも動きます。PHP専用のレンタルサーバーでは動きませんが、Node.js対応の仮想マシンやクラウド環境なら導入が可能です。WordPressから乗り換える人は、今のサーバーでNode.jsが使えるかを先に確かめてください。

必要なNode.jsの版はNode.js向けの導入ガイドに載っていて、v22.22.0以上です。Astro 7.3以前を使う場合だけはv22.16.0でも足ります。データベースにSQLiteを選ぶなら、再起動してもデータが消えない永続ディスクを用意しておきましょう。

また、Cloudflare環境ではD1を使いますが、一般的なサーバーであればSQLite、Turso/libSQL、PostgreSQLから選べますね。画像やバックアップなどのファイル保存先についても、ローカルのファイルシステムだけでなく、AWS S3や各種S3互換ストレージを接続できます。

プラグインのうち、ほかと切り離して動かす隔離型のものも、Node.jsで使えます。Cloudflare上ではDynamic Workerを使いますが、Node.js環境ではworkerdの子プロセスとして実行する仕組みです。この実行には専用パッケージの導入が必要になります。

新しくサイトを作るときは、npm create emdash@latestから始めます。このコマンドで始まるのはサイトの作成までなので、本番公開にはこのあとサーバー側の準備が必要です。

D1、R2、Workersと名前が三つ並ぶと、どれが何をしているのか分かりにくいですよね。役割は単純で、Workersがサイトを動かし、D1が記事などのデータを保存し、R2が画像などのメディアを保存します。設定ファイル上では、D1の接続名が「DB」、R2の接続名が「MEDIA」として指定されます。

運用面で注意したいのが予約公開の設定ですね。Cloudflare上で指定日時に記事を自動公開するには、Cron TriggerとWorker側のscheduledハンドラーの両方が揃っていなければなりません。どちらか一方でも設定が抜けていると、予定時刻になっても記事は公開されないままになります。手元で予約公開がうまくいっても、本番の設定がそろっている証拠にはなりませんね。

ところで、既定のautoモードでは、デプロイ後に最初のアクセスが来た時点で、まだ適用されていない基本の移行処理が走ります。ただし、記事データなどの大規模な移行については、手動でemdash migrateを実行するまで反映されず、その間は503エラーが返される仕様です。

もう一つ見落としやすいのが、バックアップの置き場所です。EmDashでは自動JSONバックアップがメディアと同じバケット内のbackups/という場所に保存されます。R2バケットを公開設定にするなら、ストレージの説明のとおり、この部分を公開対象から外してください。

なお、ステージングなどのプレビュー環境を作る場合は、本番用のD1データベースやR2バケットとは完全に分けた専用の保存領域を用意します。本番のものをプレビューにつなぐのは避けてください。

隔離型のプラグインを使わなければ、Workersの無料プランで動かせます。初期作成時のテンプレートではWorker Loaderの設定がコメントアウトされているため、追加の隔離設定を有効にしなければ無料枠の範囲で稼働します。ただし、これはWorkersの話で、サービス全体の費用が必ずゼロになるという意味ではありません。

一方、隔離型プラグインを使いたいなら、話は変わります。この仕組みはDynamic Workersの上で動いていて、Dynamic Workersの料金案内にあるとおり、Workers Paidプランでしか使えません。marketplace、registry、sandboxedのどれも使わないサイトなら、設定からsandboxRunnerとLOADERバインディングを外せます。導入例にはLOADERが入っているので、無料プランで運用するときは設定ファイルを一度見直しておきましょう。

デプロイの流れは次のとおりです。

1. テンプレートと依存パッケージを用意する
2. pnpm wrangler loginでCloudflareにログインする
3. wrangler.jsoncのD1とR2の設定を確認する
4. pnpm buildを実行する
5. pnpm wrangler deployを実行する

まだ作っていないD1やR2は、最初のデプロイのときにWranglerが作成します。

本番公開が完了した後は、通常の公開ページが見えるか、管理画面のURLである /_emdash/admin にログインできるかを確かめます。テスト用の画像はアップロードするだけでなく、取り出せるところまで見てください。定期実行の処理は、pnpm wrangler tailでログを追えば動いているかが分かります。

Cloudflareから離れる道は、ちゃんと用意されています。ソースコード全体がMITライセンスのもとで公開されているオープンソースソフトウェアだからです。Node.js環境を選べば、PostgreSQLを組み合わせて完全に自前のインフラで運用可能です。PostgreSQLに接続する場合は、EmDash側のpostgresアダプターを指定し、依存関係にpgパッケージを追加して接続文字列を記述します。

さらに、プラグインの隔離も、Cloudflareだけの機能ではありません。Cloudflare上ではDynamic Worker Loadersを利用しますが、Node.js環境であればオープンソースのランタイムであるworkerdの子プロセスとしてサンドボックスを起動します。

一方で、懸念の声もあります。WordPressの共同創設者であるMatt Mullenweg氏は、EmDashへの意見を公開し、EmDashはCloudflareのサービスをもっと売るために作られたという見方を示しました。開発元がクラウド事業者である以上、そう感じる人がいるのは自然なことでしょう。

気をつけたいのは、対応しているデータベースがあることと、D1に入れたデータをそのまま移せることは別の話だという点です。Cloudflareで始める場合も、いつか移す可能性があるなら、その作業は自分で見込んでおく必要があります。

導入事例として分かりやすいのは、開発元であるCloudflare自身です。同社は2026年8月に、自社の公式ブログを従来のCMSからEmDashへと全面的に移行しました。

Cloudflareブログの移行報告では、移行前の検証として、毎秒7,000リクエストをいきなり送り込む負荷試験をしています。本番環境へ移行した後の初期実績としても、最大で毎秒850リクエストを処理しながら、エラーの減少と高速な応答を維持できたと報告されました。7,000 RPSはあくまで試験でかけた負荷で、移行後の実績とは分けて読んでください。また、この数字はCloudflare上での結果なので、Node.jsサーバーで動かした場合にも同じ性能が出るとは限りませんね。