Vercel Daemons、service bindings で非公開サービスを呼び出し可能に

何が発表されたか

• Daemon から同一デプロイ内の別サービスを呼び出せる。ルーティング・認証・TLS は Vercel が管理し、呼ばれる側のサービスは公開されないまま維持される。
• 設定は vercel.toml の daemon 配下にバインディングブロックを追加する形。対象サービス名を指定し、format を url にし、サービスのURLを受け取る環境変数名を指定する。Daemon 側はその環境変数を読み、fetch などの通常のHTTPリクエストで呼ぶ。
• バインディングは一方向で、サービス側から Daemon へバインドすることはできない。
• 各 Daemon インスタンスは自分を起動したデプロイを呼び続けるため、プロモーションやロールバックをまたいでも呼び先が一貫する。
• 同日、Daemons に HTTP の liveness check も追加された（異常状態のプロセスを先回りして再起動する）。

開発者への影響

これまで常駐プロセスから内部APIを叩くには、その内部APIを公開エンドポイントにして自前でトークン認証を足すか、別途ネットワークを組む必要があった。公開せずに呼べるようになったことで、認証トークンの発行・ローテーション・漏えいリスクという一式が設計から消える。

受託の制作で効く場面は限られるが、当てはまると大きい。たとえば在庫やCSVの定期取り込み、Webhook の受け口とキュー処理の分離、外部APIのレート制御を一手に引き受ける常駐ワーカー——こうした構成を、これまでは別のVPSや Cloud Run に逃がしていたケースが Vercel 内に収まる。ホスティング先が1つ減ることは、保守案件では請求書と障害対応窓口が1つ減ることと同義。

一貫性の仕様も見逃せない。Daemon が「自分を起動したデプロイ」を呼び続けるため、デプロイ直後に新旧が混在して壊れる類のバグを踏みにくい。ロールバック運用があるクライアントほど安心材料になる。

利用条件

対象サービスは同一デプロイ内に存在する必要がある。料金や同時実行の上限はチェンジログに記載がないため、本番採用前にドキュメントで確認したい。