upstream との対応表
upstream Misskey の部品ごとに、misskey-cf での置き換え先をまとめています。各表の下の「違い」は、置き換えによって upstream と挙動が変わる点です。
HTTP サーバー
upstream の Fastify サーバーの役割は、gateway（入口）と api（本体）に分かれています。
| upstream | misskey-cf |
|---|---|
| Vite でビルドした Web クライアントの配信 | gateway の Static Assets |
ClientServerService・views/*.tsx（HTML、/@user などのサーバー描画、manifest、robots） | gateway（client.ts、html.ts、ssr.ts） |
ApiServerService・ApiCallService（認証・権限・レート制限・パラメーター検証） | api の router.ts（callGate） |
| API エンドポイント | api の src/*-pg.ts など |
ActivityPubServerService・WebFinger・NodeInfo | api の src/ap/ |
StreamingApiServerService | api が認証し、stream の StreamHub に WebSocket を渡す |
FileServerService（/files、/proxy） | api + media |
UrlPreviewService（summaly） | api の src/url-preview/（summaly を移植） |
設定ファイル（.config/default.yml） | 各 wrangler.toml の [vars]（INSTANCE_URL など）と secret |
違い
- エンドポイントの権限とパラメーター定義は、upstream のソースから生成した表を使います（
endpoint-meta.gen.ts、endpoint-params.gen.ts）。 - SSR に必要なデータは、gateway が api の RPC（
ApiInternal）から受け取ります。 - 詳細: Gateway、API、ActivityPub
データの保存先
| upstream | misskey-cf |
|---|---|
| PostgreSQL（TypeORM） | PostgreSQL（Hyperdrive 経由、pg + Kysely） |
| ファイル保存（ローカル / S3） | R2 misskey-cf-media |
| Meilisearch / pgroonga | なし（SQL LIKE） |
チャート用テーブル（__chart__*） | 書き込まない（元のテーブルから都度集計） |
| ID 生成（aidx） | packages/id に移植 |
違い
- スキーマは upstream と同じです。Worker は DDL を出さず、upstream のマイグレーションを SQL にしたものを
pnpm db:migrateで適用します（Migrations）。D1 は使いません。 - Hyperdrive の SELECT キャッシュは無効にしています（Hyperdrive）。
- チャートは削除を数えられないため
decは常に 0 です。連合やリクエスト数など、イベントの記録が必要な系列も 0 です。理由は チャート にあります。
Redis の用途
misskey-cf は Redis を使いません。upstream が Redis で行っていることを、用途ごとに置き換えています。
| upstream の Redis の用途 | misskey-cf |
|---|---|
| meta・ロールなどのキャッシュ | isolate ごとのメモリキャッシュ + KV META_CACHE |
| プロセス間のキャッシュ無効化（pub/sub） | なし（キャッシュの有効期限で追従） |
| ストリーミングのイベント配信（pub/sub） | StreamHub（ユーザーごと）へ直接送る。宛先は StreamPresence で絞る |
ノートの更新通知（noteStream:{noteId}） | NoteWatch |
| ホーム・リスト・チャンネルなどのタイムライン | PostgreSQL で同じ結果を返すクエリ |
| アンテナのタイムライン | TimelineShard |
| 通知の保存（Redis Stream） | NotificationBox（ユーザーごと、最大 500 件） |
| レート制限 | RateLimiter |
| ランキング（注目ノート、トレンドのハッシュタグなど） | PostgreSQL で同じ期間を集計 |
| チャットの既読 | chat_message.reads 列 |
| リバーシのマッチング | Reversi |
| リアクションのバッファリング | なし（常に即時反映） |
違い
- 管理画面で meta やロールを変えると、ほかの isolate には最大 30 秒古い値が残ります（API "KV / cache layer"）。
- タイムラインの長さの上限と hibernation は再現しません。
- ランキングは近似です（API 互換性一覧 の 🟡）。
- チャンネルを購読していない WebSocket には、サーバー全体へのお知らせ（絵文字の追加など）が届きません。公式クライアントは常に
mainを購読するため、実際には届きます。 - 詳細: Streaming、Social
ジョブキュー（BullMQ）
| upstream のキュー | misskey-cf |
|---|---|
deliver | Queue mk-deliver |
inbox | Queue mk-inbox |
userWebhookDeliver・systemWebhookDeliver | Queue mk-webhook-deliver（両方） |
db（アカウント削除、エクスポート、インポートなど） | Queue mk-jobs |
endedPollNotification | PollTimer のアラーム |
postScheduledNote | PollTimer のアラーム → mk-jobs |
objectStorage | なし（削除処理の中で R2 から直接削除） |
relationship | なし（フォローなどはリクエストの中で処理） |
system（定期処理） | api の Cron（下の「定期処理」） |
| — | Queue mk-timeline-fanout（投稿のタイムライン配信。misskey-cf で追加） |
違い
mk-jobsは 1 メッセージ = 有限の 1 ステップです。大きな処理は続きを自分で再投入します。relationshipキューを持たないのは、フォロー直後に件数や関係を読み直す操作が多いためです（Queues）。- キュー管理画面（ジョブの一覧や操作）は、consumer が OpsStats に記録した範囲での近似です。見えるのは失敗と遅延のジョブだけです（Queues "admin/queue/*"）。
定期処理
upstream の system キューの定期ジョブは、api の Cron（毎時 17 分）にまとめています。
| upstream | misskey-cf |
|---|---|
| 期限切れミュートの削除 | 毎時 |
| モデレーターの活動チェック | 毎時 |
aggregateRetention・clean（毎日 0:00） | 毎時の Cron のうち UTC 0 時の回 |
| 予約投稿 | PollTimer のアラーム（取りこぼしは毎時の Cron で回収） |
| チャートの集計 | なし（都度集計のため不要） |
| リアクションバッファの反映 | なし（バッファリングしないため不要） |
接続中のユーザーの lastActiveDate は、StreamHub が 5 分ごとに更新します。
外部サービスと Node.js の依存
| upstream | misskey-cf |
|---|---|
| sharp / ffmpeg | media の Container |
| nodemailer（SMTP） | Cloudflare Email Service（mk-jobs 経由で送信） |
web-push ライブラリ | Web Crypto による実装（mk-jobs で 2 秒遅らせて送信） |
| DeepL | DeepL API を直接呼ぶ |
| 外部への HTTP 取得 | safe-fetch.ts（リダイレクトのたびにホスト名を検査） |
違い
- Container が止まっていても、アップロードは成功します。サムネイルが作られないだけで、原本は保存・配信されます（Drive）。
- SMTP の設定項目は保存されますが、使われません。
- Worker は接続先の IP アドレスを見られないため、SSRF 対策はホスト名で判定します。