NodeFlareの仕組み

汎用コンテナではなく、MCPのために作られている

MCPサーバーとは、AIモデルに「呼べる道具」（Web検索・DB照会・API呼び出しなど）を渡す小さなプログラムです。多くは手元のマシンで動かす前提で書かれ、Claude Desktopのようなアプリが起動し、stdio（標準入出力＝コマンドラインのプログラムが読み書きする入力・出力の流れ）でやり取りします。NodeFlareは、その同じプログラムをコード変更なしでクラウドで動かし、AIクライアントがHTTPのURLで繋げるエンドポイントに変えます ― 認証・ツール単位のアクセス制御・トークン削減の仕組みを上乗せして。

汎用ホスト（Heroku・Fly・Renderなど）は「コンテナとポート」を渡して終わりで、認証もHTTP化も、stdioのプログラムをHTTPに合わせる作業も自分で書く必要があります。NodeFlareはMCPというプロトコルを理解しているぶん、そこまで面倒を見ます ― JSON-RPC（簡易なリクエスト/レスポンスのメッセージ形式）に載る initialize / tools/list / tools/call といったメソッドや、継続するMCPセッションの概念まで含めて。

このページは、それを成り立たせる4つの部品 ― ビルド専用サービス、stdio→HTTPの橋渡し、リクエストの入口、コードサンドボックス ― を順に見ていきます。`Builder` や `Proxy` は単なる内部コンポーネントの呼び名で、初出の箇所で意味を説明します。抽象的なマーケティング表現ではなく、あなたのサーバーを動かしている実コードに直接対応しています。

クイックスタート

MCPサーバーを3ステップでデプロイし、クライアントに接続します。Dockerfileもサーバーコードの変更も不要です。

1. 1

   リポジトリを指定

   ダッシュボードでGitHubリポジトリ（モノレポのサブディレクトリも可）を選ぶだけ。検出がマニフェストとソースを読み、ランタイム・トランスポート・起動コマンドを判定します。

2. 2

   デプロイ

   Builderがリポジトリをクローンし、Firecrackerイメージをビルド、micro-VMを起動して MCP の initialize ハンドシェイクを検証。認証付きのHTTPS URLが発行されます。

3. 3

   クライアントを接続

   URLとAPIキーをMCPクライアント（Claude / Cursor / 自作エージェント）に設定するだけ。Streamable HTTP と従来のSSE の両方に対応します。

MCPクライアント設定の例:

{
  "mcpServers": {
    "my-server": {
      "url": "https://<your-server>.nodeflare.tech/mcp",
      "headers": { "Authorization": "Bearer <YOUR_API_KEY>" }
    }
  }
}

全体アーキテクチャ

1つのリクエストを4つのコンポーネントが処理します。下の図で上から下へ1本たどれます。Builder はリポジトリを稼働中のサーバーに変えます。stdioアダプタは、stdioしか話せないサーバーにHTTPを話させる小さな橋渡しです。Proxy はすべてのリクエストが通る入口で、あなたが誰で何を許可されているかを確認してからサーバーへ転送します。Runner はAIが書いたコードを走らせる任意のサンドボックスです。前の3つは常に経路上にあり、Runner はコードモードが有効なときだけ使われます。

本文には2つの用語が繰り返し出てきます。Firecracker マイクロVM は軽量な仮想マシンで、1秒未満で起動し、メモリ消費が少なく、通常のコンテナより各サーバーを強く隔離します。「ベアメタル」は、これらのサービスが他社クラウドの中ではなく、私たちが運用する専用の物理サーバー上で動くことを指すだけの言葉です。

各サーバーはコンテナ名から算出される固定の内部ポートを持つため、proxyは再起動後も必ず到達先が分かります。stdioアダプタはどの言語でも同じ挙動なので、Python・Go・RustのサーバーもNodeと全く同じようにHTTPへ橋渡しされます。

Builder：GitHubリポジトリから稼働中のMCPへ

Builderは、GitHubリポジトリを「稼働中のサーバー」に変えるビルド専用サービスです。リポジトリを指定すると、ビルド・起動方法を自動で判定し、コンテナイメージにまとめて起動し、サーバーが実際に応答するかまで確認します ― Dockerfileもデプロイ設定も書かずに。各デプロイで起きることは次のとおりです：

1. 1

   ソース取得

   GitHub Appのtarball（または公開git）でクローン。root_directoryはパストラバーサル対策付きで解決し、モノレポ（npm/yarn/pnpmワークスペース）を自動検出して、リポジトリ直下に巻き上げられた依存も正しく解決できるようにします。

2. 2

   ランタイムとコマンドの判定

   manifest（package.json、pyproject.toml / requirements.txt / uv.lock、go.mod、Cargo.toml、pom.xml / build.gradle、*.csproj）から node / python / go / rust / java（Maven・Gradle、Kotlin含む）/ C#-.NET / docker を推定します。パッケージマネージャ（npm / pnpm / yarn / bun）や起動・ビルドコマンドも自動導出します（Nodeは scripts.start → main → bin、Pythonは [project.scripts] や server.py/main.py など）。明示した entry_command / build_command は常に優先されます。モノレポではデプロイ可能なサブパッケージを列挙して選べるようにし、lockfileのトランジティブな engines.node がより新しいメジャーを要求する場合はDockerfile内のNode.jsバージョンも自動で引き上げます。

3. 3

   Dockerfile生成

   Dockerfile（コンテナイメージを組み立てる手順書）をランタイム別に生成します（あるいは持ち込みのDockerfileを検証・ラップ）。stdioサーバーの場合、stdioアダプタをコピーしてコンテナのエントリポイント（コンテナ起動時に走るプログラム）に設定し、あなたのサーバーを子プロセスとして起動させます。

4. 4

   シークレット注入

   環境変数はDBから復号し、ビルド引数やargvには一切渡さず、VMの起動時に環境変数として注入します。既知のトークン形状を伏せ字にするredaction処理がビルドログをクライアントへストリームする前に走ります。

5. 5

   ビルドと起動

   コンテナイメージを nerdctl / containerd でビルドし、任意でプライベートレジストリへpushし、Firecrackerマイクロ VMとして起動します。内部ポートはコンテナ名から算出（ハッシュ）されるため、proxyは常に到達先が分かり、ポート割り当てサービスなしで再起動をまたいでもルーティングが安定します。

6. 6

   本物のinitializeで検証

   VMが起動しただけではMCPサーバーが動いている証明になりません。builderは本物のMCP initialize ― どのMCPクライアントも最初に行う起動ハンドシェイク ― を送ります（最大8回、バックオフあり）。アダプタの背後で子プロセスがクラッシュループしていればデプロイは失敗扱いにし、偽の成功ではなく実際のサーバーエラーを提示します。

# What the Builder emits for a stdio MCP server (any language):
CMD ["node", "stdio-adapter.cjs", "npm", "start"]         # Node
CMD ["node", "stdio-adapter.cjs", "python", "server.py"]  # Python
CMD ["node", "stdio-adapter.cjs", "./server"]             # Go / Rust binary
CMD ["node", "stdio-adapter.cjs", "npx", "-y", "pkg"]     # npx package

stdio → Streamable HTTP アダプタ

ここでいうアダプタとは、小さな橋渡しプログラムのことです。解決する問題はこうです ― 多くのMCPサーバーは、Claude Desktopがローカルで起動するときのように、stdio越しの会話しか知りません。それこそがネットワークに載せにくい理由です。NodeFlareのアダプタ（1つのNode.jsファイル stdio-adapter.cjs）はビルド時にイメージへ追加され、VMの中で最初に起動するプログラムになります。

アダプタはあなたのMCPサーバーを子プロセスとして起動し、2つの世界を翻訳します ― 片側はサーバーのstdioメッセージ、もう片側はHTTP（Streamable HTTP＝MCP現行のHTTPトランスポート、および古いクライアント向けに旧2024-11-05のHTTP+SSE）。サーバーが何語で書かれていても関係ありません。stdio越しのJSON-RPCメッセージを読み書きするだけだからです。

// Each client request gets a private JSON-RPC id, so concurrent
// callers never collide on the one shared child process.
const internalId = `nf-${n++}`;
child.stdin.write(JSON.stringify({ ...msg, id: internalId }) + "\n");
// On reply, the caller's original id is restored before responding.

// Health: /health returns 503 once the restart budget is spent,
// so the platform marks the VM unhealthy instead of silently 500-ing.

Proxy：認証・スコープ・MCPを理解したルーティング

Proxyは、ホスティング済みサーバーへの全リクエストが通る入口です。どのサーバー宛か（リクエストのサブドメインから）を判別し、呼び出し元が誰かを確認し、その正確な呼び出しが許可されているかを確認し、その上であなたのサーバーのVMへ転送します ― 戻り道ではMCPが必要とする箇所でレスポンスを調整します。

MCPを理解しているため、素のリバースプロキシにはできないことができます：個々の tools/call をツール名で許可/拒否し、呼び出し元が使えないツールを tools/list から隠し、MCPセッションを起動したそのVMに固定し、そもそもリポジトリが有効なMCPサーバーかを判定します。

スコープ文法

*                        full access
tools:list               list tools
tools:call               call any tool
tools:call:get_weather   call only the get_weather tool
resources:read:<uri>     read one specific resource
prompts:get:<name>       get one specific prompt

MCPトークン最適化機能

大きなツールカタログはコンテキストを浪費します。60個のツールを公開するサーバーは、モデルが何かする前に tools/list だけで数千トークンを使いかねません。NodeFlareはMCPの表面をトークン節約の形へ作り替える、サーバー単位の4つのスイッチを備えています ― すべてproxy側で透過的に適用され、あなたのサーバーのコードには手を加えません。

検索モード（tool_search_mode）は GEMINI_API_KEY を設定すると意味検索（embedding）へ自動アップグレードします。ツール名と説明をベクトル化し、search_tools のクエリと意味的に一致させます ― 未設定や失敗時は字句検索へ穏当に縮退し、リクエストは決してブロックされません。より正確なツール発見は無駄な試行呼び出しを減らし、結果としてコンテキストを小さく保ちます。

コードモードとサンドボックスRunner

tool_code_mode が有効なとき、モデルはツールを1つずつ呼ぶ代わりに、JavaScriptのブロックを run_code ツールへ送れます。NodeFlareはそのコードをサンドボックスで実行します ― proxyとは別のDenoサービスが、リクエストごとに厳重に隔離したサブプロセスで走らせます。ファイルシステムアクセスなし・環境変数なし・他プログラムの起動なし、ネットワークの到達先は1つだけ（proxyのツールコールバックエンドポイント）です。

サンドボックス内では、各ツールが非同期関数 tools.NAME(args) として使えます。呼び出すと、その実行専用の使い捨てトークンを携えてproxyへリクエストが戻ります。サンドボックスがあなたの実際の資格情報やサーバーURLを見ることはありません。

課金への効き方：NodeFlare自体はLLMを呼ばないパススルーproxyなので、これらのトークン削減は主に呼び出し側のLLM費用を下げます。加えて、コードモードで作業が早く終わるほどサーバーは早くアイドル（Scale-to-zero）へ入り、Compute（¥5/GB-時）の課金時間も縮みます。egress と Chromium は無課金です。

// tool_code_mode: the model writes JavaScript instead of many
// round-trips. tools.* is injected; every call is scope-checked
// server-side and counts against a per-run tool-call budget.
const top = await tools.searchVideos({ query: "rust async", maxResults: 5 });
const details = await Promise.all(
  top.map(v => tools.getVideoDetails({ videoIds: [v.id] }))
);
return details.filter(d => d.likeToViewRatio > 0.04);

1. 1

   短命トークンを発行

   proxyは使い捨てのUUIDトークンを発行し、server_id・target_url・呼び出し元スコープを（実行タイムアウト + 10秒）のTTLでRedisに保存し、JavaScriptをランナーサービスへ送ります。

2. 2

   隔離環境で実行

   新しいDenoサブプロセスが --allow-net をコールバックエンドポイントホストのみに制限して起動します。ファイルシステムなし・環境変数なし・サブプロセス生成なし。実時間タイムアウトを超えるとSIGKILLされます。

3. 3

   ツール呼び出しごとにスコープ再チェック

   コールバックエンドポイントはトークンを引き、このサーバーに束ねられていることを確認し、スコープ（例：tools:call:search_videos）を再検証してから本物の tools/call を上流へ転送します。サンドボックス側のラッパーは決してセキュリティ境界ではなく、proxyがそれを担います。

4. 4

   結果を返す

   ツールエラーはモデルが同一実行内でcatch・リトライできるようラップされ、最終の戻り値はシリアライズされて run_code の結果として返ります。

スケーリング: scale-to-zero・常時起動・オートスケール

MCPサーバーはバースト型です。長く暇で、エージェントが動き出した瞬間に忙しくなる。NodeFlareはその形に合わせて容量を自動調整します。

各サーバーは専用のFirecracker micro-VMで動作します。並行処理は水平方向で捌き、1レプリカあたりの同時数上限を超えると、準備済みスナップショットから追加のレプリカVMをforkします（プラン/ホスト上限まで）。

メモリと右サイズ

各サーバーにはメモリサイズがあります。小さすぎればメモリ不足で落ち、大きすぎれば使わない余剰に課金される。NodeFlareは実際のワーキングセットを実測して適正サイズを提案します——ただし、あなたの承認なしに勝手に変更はしません。

右サイズは約1か月（初期の安定化期間は除外）観測し、直近の最も忙しい1週間を基準に提案します。静かなテスト期間だけを見て過小サイズにする、という事故を防ぎます。

1. 1

   実測

   サーバー稼働中、実使用メモリ（回収可能なキャッシュを除く）をサンプリング。目標は観測ピーク＋余裕で、実際に必要だった量を絶対に下回りません。

2. 2

   提案

   十分なデータが貯まると、縮小の提案がサーバー詳細ページに通知として表示され、[適用]/[却下]を選べます。自動では何も変わりません。

3. 3

   適用と自動復帰

   [適用]で新サイズが次回デプロイから有効に。もし小さくしてメモリ不足になったら、自動で前のサイズへ戻し、以後そのサイズは二度と提案しません。

永続ストレージ

既定ではサーバーのファイルシステムは一時的で、scale-to-zero・再デプロイ・VM終了でリセットされます。永続ディスクを有効にすると、それらを越えてデータが残ります。

ディスクはホスト上のオーバーレイ上位層です。永続サーバーは単一VM（single-writer・並行forkなし）で動くため、書き込みの整合性が保たれます。

料金と課金

NodeFlareは実際に使った分だけ課金します。サーバー稼働中のコンピュートと、永続ストレージです。egress（外向き通信）や同梱のマネージドブラウザに課金はありません。

Freeアカウントは月間のコンピュート枠込み、有料プラン（Pro・Team）はより大きな枠込みで超過分のみ従量課金（任意で上限設定可）です。

サーバーの作成と設定

サーバー作成は1つのフォームで完結します。GitHubリポジトリ（またはモノレポのサブディレクトリ）を指定すれば、あとは検出が埋めます。以下はすべて作成時に選べ、後から変更もできる ― builderとproxyが代わりに強制するサーバー単位の機能で、あなたが配線するものではありません。

セキュリティモデル

認可はproxyとコールバックエンドポイントが強制します ― クライアントでも、サンドボックスのラッパーでも、あなたのサーバーでもありません。

• ✓スコープはリクエストごとに正確なMCPメソッドと対象に照合され、拒否時はサーバーに到達する前にJSON-RPCエラーを返します。
• ✓キャッシュとリクエストコアレッシングのキーは呼び出し元の識別子を含むため、スコープやサブスクリプションでフィルタされた結果が資格情報をまたいで漏れることはありません。
• ✓コード実行トークンは用途が単一で、1サーバーに束ねられ、短命（TTL＝実行タイムアウト + 10秒）で、ツール呼び出しのたびにスコープを再チェックされます。
• ✓コードサンドボックスのサブプロセスはファイルシステムなし・環境変数なし・行き先1つのネットワーク許可リストのみ。保持するのは実行毎トークンだけで、あなたの資格情報は持ちません。
• ✓シークレットは保存時に暗号化し、VMの起動時に環境変数として注入されます。ビルド引数やイメージレイヤーには一切書き込まれず、ビルドログからは既知のトークン形状を伏せ字にします。
• ✓外向き通信はサーバー単位のEgress許可リストで制限でき、ホスト側（DNS + nftables）で強制します ― observeモードはログのみ、enforceモードはリスト外を遮断します。
• ✓デプロイは本物のMCP initializeが往復して初めて「成功」です。クラッシュループするサーバーは、静かにHTTP 500を返す代わりにデプロイを失敗させます。
• ✓APIキーのルックアップはRedisキャッシュ（5分TTL）付きで、総当たりロックアウトを実施します。あるIPから間違ったキーが繰り返し使われると、そのIPを10分間ロックします。

ネットワークアクセス制御

既定ではサーバーはどこからでも到達可能です（認証は必須）。特定ネットワークからのみ到達させたい場合、送信元IPで受信を制限できます。

ポリシーを restricted にし、許可するCIDR（例: 社内VPNのegress IP）を列挙します。proxyがエッジで——認証前・VM起動前に——強制し、リストが空なら fail closed（全拒否）します。

カスタムドメイン

各サーバーには nodeflare.tech のサブドメインが付きます。自分のドメインを向けることもできます。

サーバー設定に表示されるターゲットへ CNAME を追加すると、DNSで検証してから配信します。TLSは自動発行です。

1. 1

   ドメインを追加

   サーバー設定にホスト名を入力。作成すべき CNAME ターゲットが表示されます。

2. 2

   CNAMEを作成

   DNSプロバイダで、そのターゲットへ CNAME を向けます。

3. 3

   検証して配信

   レコードを確認し証明書を発行。以後、あなたのドメインへのリクエストがサーバーへ届きます。

Egress 制御（外向き通信の許可リスト）

MCPサーバーは信頼できない依存やコードを含みうるため、既定では任意の外部ホストへ接続・データ送信ができてしまいます。Egress制御は、サーバーVMが到達できる宛先をホスト側のネットワーク層で制限し、データの持ち出しを防ぎます ― サーバーのコードを信用するのではなく、境界をネットワークで引きます。

# Allowlist entry formats
api.github.com        # exact hostname
*.openai.com          # single leading wildcard (subdomains; not the apex)
10.0.0.5              # IPv4 / IPv6
# rejected: https://host  ·  host:443  ·  host/path   — bare host only, max 100 entries

1. 1

   サーバー詳細 > Settings

   Egress control セクションでモード（off / observe / enforce）を選びます。

2. 2

   許可リストにホストを追加

   入力してEnter（または＋）。タグとして並び、×で削除できます。ホスト名・先頭ワイルドカード（*.example.com）・IPが使え、最大100件です。

3. 3

   observeで学習 → enforceへ

   数日 observe で稼働させ、Logs > Egress で実際の宛先を確認・ワンクリック許可してから enforce に切り替えます。

リクエストログ

MCPサーバーへの全リクエスト（JSON-RPC）を記録し、成否・レイテンシ・セキュリティ結果まで保持します。Logsページでサーバーを選び、行をクリックすると Request / Identity / Result の詳細が開きます。

主なユースケース

post-install とデプロイ後のエラー

MCPサーバーはGitリポジトリからビルドし、Firecracker microVM で実行されます。「post-install」には2つの意味があります。

1. 1

   ビルド出力をスキャン

   unzip: command not found のような不足ツールの兆候を検出します。

2. 2

   安全なツールのみ導入

   unzip・xz-utils・git・build-essential・cmake・python3 など、既知の安全なツールだけを apt で導入。

3. 3

   再試行（最大3回）

   Dockerfileにパッチを当てて再ビルドします。

Pending ─▶ Building ─▶ (Pushing) ─▶ Deploying ─▶ Succeeded | Failed | Cancelled
after boot, a real MCP initialize is sent:
  Verified      valid JSON-RPC response
  Broken        5xx / no connection   (OOM · crash · not listening)
  Inconclusive  responded but initialize failed   (possible cold start)