VercelがDockerfileサポートを発表、任意のHTTPサーバーをデプロイ

VercelがDockerfileサポートを発表、任意のHTTPサーバーをデプロイ

VercelがDockerfileサポートを発表、任意のHTTPサーバーをデプロイ

VercelがDockerfileサポートを発表、任意のHTTPサーバーをワンコマンドでデプロイ可能に

VercelがDockerfileサポートを発表、任意のHTTPサーバーをワンコマンドでデプロイ可能に

2026年6月30日、VercelはDockerfileサポートを正式に発表した。プロジェクトにDockerfile.vercelというファイルを追加するだけで、Vercel上でコンテナイメージのビルド、保存、デプロイ、そしてオートスケールが完結する。

従来、Vercelはフロントエンドとサーバーレス関数のプラットフォームだった。今回の発表で、Express、Rails、Spring Boot、FastAPIといったフル機能を持つHTTPサーバーも、同一のプラットフォームで運用できるようになる。バックエンドとフロントエンドの垣根は、ほぼゼロになった。

この記事では、Dockerfile.vercelの仕組み、対応スタック、Fluid computeによる運用面の利点、そしてVercelが10年越しでこの機能を実現した理由について解説する。

Dockerfile.vercelの基本的な使い方

Dockerfile.vercelの基本的な使い方

最小限のHTTPサーバーをデプロイする手順

仕組みを理解するため、Goで書かれた最低限のHTTPサーバーを例に見ていこう。このサーバーは環境変数PORTからポート番号を読み取り、全リクエストに挨拶文を返すだけのシンプルなものだ。

package main

import (
	"fmt"
	"net/http"
	"os"
)

func main() {
	port := os.Getenv("PORT")
	if port == "" {
		port = "80"
	}

	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "Hello from a container on Vercel 👋")
	})

	http.ListenAndServe(":"+port, nil)
}

このコードを動作させるため、Dockerfile.vercelをプロジェクトルートに置く。内容は次のような2段階ビルドだ。ビルドステージでバイナリをコンパイルし、軽量なAlpineイメージにコピーして実行する。

FROM golang:1.24-alpine AS build
WORKDIR /src
COPY . .
RUN go build -o /server main.go

FROM alpine:3.20
COPY --from=build /server /server
CMD ["/server"]

あとはvercelコマンドを実行するだけだ。

vercel deploy
Vercel CLI
✓ Building image from Dockerfile.vercel
✓ Stored image in your project's registry
✓ Deployed to Fluid compute
Production: https://my-server.vercel.app

たった2ファイルで、本番公開まで完了する。git pushのたびにイメージが再ビルドされ、プレビューURLも自動生成される。ブラウザでそのURLを開けば、すぐに応答が返ってくるはずだ。

従来のコンテナデプロイ(Before)
Dockerfile作成イメージビルドレジストリプッシュ
クラスタ設定スケーリング設定ロードバランサ設定
ドメイン設定TLS証明書取得
※多数の手順が必要で、インフラ管理が負担となる
Vercel Dockerfileデプロイ(After)
Dockerfile.vercel作成vercel deploy 実行
ビルド・保存・デプロイ自動化
※インフラ管理はVercelが担当。ドメイン・証明書も自動設定

この例ではGoを使ったが、仕組みはどの言語でも同じだ。サーバーが$PORTで待ち受けること、これが唯一のルールである。HTTPプロトコルを話すサーバーであれば、すべてVercel上で動作する。

すべての言語とフレームワークに対応

すべての言語とフレームワークに対応

VercelのDockerfileサポートは、特定の言語やフレームワークに縛られない。Rails、Spring Boot、Express、Laravel、ASP․NET、FastAPI、そしてnginxの背後にあるウェブサーバーまで、同じ手順でデプロイできる。記事によれば、JavaもPHPも例外ではない。

対応する主なスタック例
Go Ruby on Rails Spring Boot Express Laravel ASP.NET FastAPI PHP Java
唯一のルール
サーバーが $PORT で待ち受ける デフォルトは 80

フレームワーク自動検出がVercelの主軸だが、検出対象外のフレームワークや、FFmpegやChromiumのようなシステムライブラリを必要とするサービスは、Dockerfileで直接定義できる。既存のアプリケーションを、今の構成のまま移行したい場合の受け皿にもなる。

Fluid computeがもたらす自動スケールとコスト最適化

Fluid computeがもたらす自動スケールとコスト最適化

コンテナはVercelプラットフォームのファーストクラス市民として扱われる。フロントエンドや他のVercelサービスと同一のコンピュート基盤、Fluid compute上で動作し、以下の恩恵を受けられる。

  • プッシュごとのプレビューデプロイ 全コミットに不変のURLが付与され、共有やロールバックが容易になる
  • 双方向オートスケール トラフィック到来でスケールアウトし、アイドル時はインスタンスが縮退する。フリートのサイジングや同時実行数の見積もりは不要
  • アクティブCPU課金 コードが実際に動作している時間だけ支払う。遅いクエリや上流API待ちでサーバーが待機している間は、CPU時間を消費しない
  • オブザーバビリティの統合 ログ、トレース、メトリクスを同一のダッシュボードで確認できる
  • 単一プロジェクト・単一ドメイン コンテナはフロントエンドや他のサービスと並んで配置され、Vercelネットワーク上でプライベートに通信する。フルスタックが1デプロイで完了する
従来のサーバー課金(Before)
インスタンスがアイドル状態でも、稼働時間(Wall time)に対して料金が発生する
※外部API応答待ちの時間も課金対象
Fluid compute課金(After)
CPUが実際にコードを実行している時間だけ課金される
※待機時間やアイドル時間は課金ゼロ

とくにアクティブCPU課金は、トラフィックが散発的なサービスにとってコスト面のインパクトが大きい。常時稼働のサーバーを抱える必要がなくなり、使った分だけの支払いで済む。

高速起動を支える最適化技術

高速起動を支える最適化技術

コンテナの価値は、最初のリクエストに応答するまでの速さで決まる。Vercelはイメージビルド時に、最適化ブートイメージを生成する。これはコンテナのディスクスナップショットを圧縮し、起動速度に特化させた形式だ。

コンテナ起動時には、イメージ全体をダウンロードし終える前に、必要な部分からストリーミングと解凍が行われる。大きなイメージでも、ダウンロード完了を待たずにリクエスト処理を開始できる仕組みだ。

インスタンスが立ち上がった後は、Fluid computeがそのインスタンスを温かく保ち、複数のリクエストを処理する。リクエストごとに新しいコピーを起動するわけではないので、応答性は常時稼働サーバー並みでありながら、アイドル時はスリープするという課金上の利点が両立する。

各コンテナはステートレスプロセスとして設計される。リクエストを受け取り、レスポンスを返し、その間に状態を保持しない。永続的なデータはVercel Marketplaceで提供されるデータベースやキャッシュなどのバッキングサービスに依存する。これにより、インスタンスの追加と削除が自由に行え、トラフィック変動への追従がシンプルになる。記事によれば、コンテナに永続ストレージを直接接続する機能も現在開発中とのことだ。

10年越しで実現したDockerfileサポートの背景

10年越しで実現したDockerfileサポートの背景

Vercelの最初のプラットフォームは、1コマンドでDockerfileをデプロイできるツールだった。2016年頃の話だ。アイデア自体は正しかったが、当時のインフラでは十分に扱いきれなかった。

その後、Vercelはビルド、Functions、Sandboxと、プラットフォームを構成する基盤技術を一つひとつ磨いてきた。これらは現在、Vercel上で動作するすべてのワークロードを支えている。今回のDockerfileサポートは、それらの積み重ねの上に成り立っている。コンテナも、それらと同一のシステム上で動くファーストクラス市民になった。

フレームワーク自動検出はVercelの入り口だ。コードを読んでインフラを導出する。ほとんどのアプリではそれが最速の出荷手段となる。Dockerfileは、それ以外のすべてをカバーする。FFmpegやChromiumのようなシステムライブラリが必要なサービス、まだ自動検出が対応していないフレームワーク、あるいは既存の構成をそのまま持ち込みたいアプリケーション。Dockerfileは、プログラムのビルド方法を定義する普遍的な手段であり、フレームワークが読めない場合にはそれを直に受け取る。

Dockerfile以外の設定は不要だ。イメージを指定するだけで、ビルド、レジストリ、ロールアウト、スケーリング、URL発行まですべてが自動的に行われる。Vercelの発表文には「ゼロコンフィグレーション」という言葉が使われているが、まさにそれを体現する機能と言える。

バックエンド開発の新しい当たり前

バックエンド開発の新しい当たり前

バックエンドが、フロントエンドと同じ方法で出荷される時代が来た。ワンプッシュ、ワンプレビュー、ワンプラットフォーム。VercelのDockerfileサポートは、その簡潔さとスケーラビリティにおいて、バックエンド開発の風景を変える可能性を秘めている。

具体的な手順やテンプレートは公式ドキュメントで公開されている。GoやRailsだけでなく、あらゆるHTTPサーバーが対象だ。既存のDockerfileを持つプロジェクトがあれば、それをDockerfile.vercelにリネームするだけでVercel上での稼働を試せる。

コンテナを扱うためにローカルでデーモンを動かす必要も、レジストリを用意する必要も、クラスタを管理する必要もない。必要なのは、Dockerfile.vercelという1つのファイルと、vercel deployという1つのコマンドだけだ。その先の複雑さは、すべてVercelが引き受ける。

STEP 1 プロジェクトに Dockerfile.vercel を追加
STEP 2 vercel deploy を実行
STEP 3 イメージビルド・保存・Fluid computeへのデプロイが自動で進行
STEP 4 本番URL発行。以後git pushごとにプレビューURL自動生成

この記事のポイント

  • VercelがDockerfileサポートを開始し、任意のHTTPサーバーをワンコマンドでデプロイ可能になった
  • サーバーが$PORTで待ち受けることさえ守れば、Go、Rails、Spring Boot、PHPなど全スタックが動作する
  • Fluid computeにより、トラフィックに応じた自動スケールと、CPU実行時間のみの課金が実現する
  • イメージのストリーミング起動技術により、大きなコンテナでも高速にリクエスト処理を開始できる
  • この機能は10年にわたるプラットフォーム基盤の改良の上に成り立っており、コンテナがVercelのファーストクラス市民として統合された
海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験 ・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識 ・ 15ヶ国語対応の多言語SaaSの開発経験 ・ 17年間にも及ぶ、Eコマース長期運営経験 ・ 幅広い業界でのSEO最適化の豊富な経験

メッセージを残す