Vercelが通常のDockerfileを自動検出：Container runtimeの条件と料金を確認

Vercelは2026年10月27日、プロジェクト直下の通常のDockerfileやContainerfileから、Container runtimeでデプロイできる変更を発表した。別のフレームワークが検出されなければ、Containerの設定が選ばれる。

ただし、Container runtimeはベータで、実行先はVercel Functions。手元のコンテナ環境を、そのまま常時稼働サーバーへ移せるという発表ではないよ。

何を置くと、どの設定が選ばれる？

例えば既存のWebフレームワークを使うリポジトリでは、Dockerfileを足しただけで必ずContainerへ変わるわけではない。現在のFramework Presetと、ビルド時に何が選ばれたかを最初に確認しよう。

明示したい場合の設定

公式発表では、プロジェクトのフレームワークをContainerへ変える方法に加え、vercel.jsonで次の指定を示している。

{
  "framework": "container"
}

これは設定項目だけを示す最小の例。既存の設定ファイルを丸ごと置き換える意味ではないよ。rewritesやheadersなどを使っている場合は、既存内容を保って差分を確認する。編集部ではJSONとして読み込めることを確認したが、Vercelへの実デプロイは行っていない。

コンテナでも、Functionsとして動く

公式資料によると、全プランでベータ提供され、Functionsの制限とActive CPUの料金体系が適用される。CPUが実際に動作している時間を基準とする説明で、無料の常設サーバーが付くという意味ではない。

HTTPサーバーの待ち受けポートは既定で80、PORT環境変数で変更できる。DockerfileのEXPOSEを書いただけで、アプリの待ち受け先まで必ず変わるとは考えないようにしよう。

トラフィックがない場合は自動的にスケールダウンし、終了時はSIGTERMによる後処理の猶予がある。常時稼働するワーカーや、ローカルディスクへ永続保存する前提のアプリは、そのまま移せると判断する前に実行モデルを照合したいね。

また、確認時点の公式資料では、コンテナイメージでSecure ComputeとStatic IPsは未対応。固定IPが接続先の許可条件になっている環境では、重要な確認点になる。

移行候補を判断する順序

以下は編集部の確認案だよ。

1. 現在のコンテナが、HTTPリクエストを処理する用途かを確認する。
2. 待ち受けポート、環境変数、終了処理、永続データの保存先を一覧にする。
3. フレームワークの検出結果と、採用するDockerfileを照合する。
4. 本番から分けた環境で起動・応答・終了・再起動を確認する。
5. Functionsの上限と実際の利用量を基に費用を見積もる。

設定の点検はComposeのconfig確認、待ち受け先はlocalhostと0.0.0.0も参考にしてみよう。