EmDash CMS セルフホスト Node デプロイリファレンス

SQLite から PostgreSQL、オブジェクトストレージへと進む段階的アーキテクチャで、自前のインフラ上で EmDash を動かします。

セルフホストが適している場合

運用、法務、アーキテクチャ上の制約があるときにセルフホストを選びます。

  • データ所在地の要件が厳しい
  • すでに社内で共有プラットフォームサービスを運用している
  • ランタイム、プロセスモデル、ネットワーク経路を完全に制御したい
  • 初期段階でマネージドクラウドへの結合を避けたい

セルフホストが自動的に安いわけではありません。通常、よりコントロールしやすいだけです。

推奨する段階的モデル

最初から最大の複雑さから始めないでください。段階的な展開を使います。

  1. Node.js + SQLite + ローカルファイルストレージ
  2. マルチインスタンスの安全性と耐久性のための PostgreSQL
  3. メディアの移植性のための S3 互換オブジェクトストレージ
  4. プロセス監視とオブザーバビリティの強化

この順序で移行ショックを最小化しつつ、クリーンな本番への道を保ちます。

ベースラインアーキテクチャ(ステージ 1)

単一ノードの本番または初期公開向け:

  • アプリランタイム: Node アダプター(standalone
  • データベース: 永続ディスク上の SQLite ファイル
  • メディア: ローカルのアップロードディレクトリ
  • リバースプロキシ: Nginx または Caddy

この構成は、ランタイムインスタンスが一つの、低〜中程度の編集負荷で足ります。

# 本番ビルドと起動
npm install
npm run build
npm run start

ステージ 2 のアップグレード基準(PostgreSQL へ)

次のいずれかが現れたらデータベースをアップグレードします。

  • 同時書き込みの競合が頻繁になる
  • バックアップ/復旧目標がファイルコピー戦略を超える
  • より安全なマルチインスタンスデプロイが必要

水平方向にアプリをスケールする前に PostgreSQL を使います。SQLite のままアプリノードを増やすと、運用リスクがすぐに高まります。

ストレージ戦略:ローカルファイルとオブジェクトストレージ

ローカルファイル(ここから始める)

単一インスタンスで、ストレージ増加が予測しやすい環境向け。

S3 互換オブジェクトストレージ(スケールのためにここへ)

次のときに使います。

  • 複数のアプリインスタンスが共有メディアアクセスが必要
  • バックアップと災害復旧を標準化しなければならない
  • CDN とエッジキャッシュ戦略が安定したオブジェクト URL に依存する

プライベートインフラでは、S3 互換の挙動に MinIO を使えます。

ランタイムプロセスとプロキシのベースライン

プロセス管理

次のいずれかを使います。

  • Linux ネイティブのサービス制御には systemd
  • プロセス指標と迅速な再起動を望むチームには pm2

リバースプロキシ

プロキシで TLS を終端し、Node アプリに転送します。

  • HostX-Forwarded-* ヘッダを保持する
  • ヘルスチェックパスを設定する
  • アップロード方針に沿ったボディサイズ上限を設定する

バックアップと復旧方針

バックアップ方針は公開後のタスクではなく、公開をブロックする条件として扱います。

最低限のベースライン:

  • スケジュールされたデータベーススナップショット
  • メディアストレージのバックアップまたはレプリケーション
  • 公開前に少なくとも一度はリストア訓練を行う

テストで一度も復元したことのないバックアップは、統制ではなくです。

運用準備チェックリスト

本番切り替えの前に確認します。

  • コールド再起動が手編集なしで動く
  • アプリログが集約され検索可能である
  • 5xx のアラートが有効である
  • ディスク使用量とストレージ増加が監視されている
  • シークレットローテーションの手順が文書化されている

Cloudflare 志向のセットアップからの移行メモ

プロジェクトが Cloudflare 前提で始まった場合:

  • ランタイム設定からクラウド専用のバインディングを削除する
  • D1/R2 アダプターを Node 互換のデータベースとストレージアダプターに置き換える
  • リバースプロキシ背後の認証とコールバック URL を再検証する

移行リスクの大半はページレベルのコードではなく、環境の前提にあります。

チーム向けの判断フレームワーク

次のルールを使います。

  • 速度と最小運用が必要ならマネージドクラウドの道を優先する
  • 制御と既存インフラとの統合が必要ならセルフホストの道を優先する

環境ごとにデフォルトの道を一つ選びます。ハイブリッドも可能ですが、認知負荷とサポート負担が増えます。