Webフロントエンドのホスティングで広く使われているVercelに、任意のコンテナをそのまま動かせる仕組みが2026年6月末に発表されました。プロジェクトに Dockerfile.vercel を1枚置くだけで、GoやFastAPI、Railsといったバックエンドをフロントエンドと同じプロジェクトへデプロイできるという内容です。これまで「Vercelはフロントエンド、バックエンドは別基盤」という住み分けが一般的でしたが、その境界が大きく動きつつあります。
本記事では、バックエンドやインフラを触るエンジニアの視点から、この仕組みの要点を整理します。コンテナのビルドから課金モデル、高速起動の裏側までを押さえたうえで、AWSサーバーレスやクラウドネイティブを主軸とするRagateが、MVP開発や内製化支援の現場でどのように活かせるかまで踏み込みます。
Dockerfile.vercel が変えるコンテナデプロイ
この機能の中心にあるのは Dockerfile.vercel というファイルです。プロジェクトのルートにこのファイルを追加しておくと、Vercelがそのコンテナのビルド、保存、デプロイ、そしてオートスケールまでを一貫して引き受けてくれます。開発者はコンテナの中身を記述するだけでよく、その先の運用はプラットフォーム側に委ねられる形です。
従来コンテナを本番運用しようとすると、Dockerデーモンの管理、レジストリの設定、そしてクラスタのオーケストレーションといった作業が付いて回りました。今回の仕組みではそれらが不要になり、開発者はインフラの土台を組み立てる作業から解放されます。デプロイは vercel deploy というコマンドで完結し、コンテナ化されたアプリケーションが公開URLとして立ち上がります。
# Dockerfile.vercel の最小例
FROM golang:1.23 AS build
WORKDIR /app
COPY . .
RUN go build -o server .
FROM gcr.io/distroless/base
COPY --from=build /app/server /server
CMD ["/server"]もう一つ見逃せないのが「One project, one domain」という考え方です。フロントエンドとコンテナ化したバックエンドを、1つのプロジェクト・1つのドメインとして統合的にデプロイできます。フロントとAPIが同じ枠組みに収まることで、CORSやドメイン分割にまつわる面倒が減り、構成そのものがシンプルになります。
唯一のルールは PORT でHTTPを話すこと
この仕組みで守るべきルールはほぼ1つだけで、サーバーが $PORT をlistenすることです。$PORT の既定値は 80 であり、コンテナ内のプロセスがこのポートで待ち受けてHTTPを話しさえすれば、あとはプラットフォームがルーティングを担ってくれます。公式の言葉を借りるなら、HTTPを話すものであればデプロイできる、というシンプルさです。
この前提のおかげで、言語やフレームワークの選択はほぼ自由になります。公式では代表例として Go、Rails、Spring Boot、FastAPI、nginx などが挙げられており、他にもHTTPを話す一般的なスタックが広くカバーされます。既存のバックエンドコードを大きく書き換えることなく、ポートの待ち受けだけ合わせれば載せられるというのは、移行の負担を考えるうえで大きな安心材料になります。
一方で、プロセスはステートレスを前提とする点は意識しておく必要があります。コンテナ自身にファイルやセッションを永続的に抱えさせるのではなく、データベースをはじめとする外部のバッキングサービスに状態を預ける設計が求められます。これはクラウドネイティブなアプリケーション設計の基本と重なる考え方であり、スケールアウトを前提とする以上は自然な制約と言えます。
Fluid compute と Active CPU Pricing で使った分だけ
コンテナが動く実行基盤は Fluid compute です。ここで採用されている Active CPU Pricing は、コードが実際に走っている時間に対して費用が発生する消費ベースの課金という考え方に立っています。リクエストを待って待機しているだけのサーバーはCPUを消費しないため、そのアイドルの時間は課金されません。
ポイントは、経過時間そのものではなく実行時間に対して支払う点です。つまりプロセスが起動しているというだけで料金がかさむのではなく、実際に処理を行っている分だけがコストになります。トラフィックが不規則で、リクエストが集中する時間帯とほとんど呼ばれない時間帯が混在するようなワークロードでは、この課金モデルはコストの無駄を抑えるうえで相性が良い仕組みだと考えられます。
最適化ブートイメージとストリーミング展開で速く起動
コンテナ実行でしばしば課題になるのが起動の速さです。この仕組みでは、コンテナが optimized boot image と呼ばれる最適化されたブートイメージとして保存されます。これはコンテナのディスクを高速起動向けにチューニングした圧縮スナップショットであり、通常のイメージをそのまま引き回すのとは異なるアプローチです。
さらに、そのスナップショットはオンデマンドでストリーミング展開されます。イメージ全体のダウンロードが完了するのを待たずに、必要な部分から順に展開して処理を始められるため、全イメージがそろう前にリクエストの処理を開始できます。コールドスタートの体感を小さく抑えるための工夫であり、スケールアウト時やしばらく呼ばれていなかったコンテナが再び立ち上がる場面で効いてくる部分です。
RagateがVercelコンテナを活かせるシーン
RagateはAWSサーバーレスやクラウドネイティブを主軸に据えつつ、生成AI活用やMVP開発、いわゆるバイブコーディングによる素早い立ち上げ、そして内製化支援を提供しています。Dockerによるコンテナ化も日常的に扱う領域であり、今回のVercelコンテナはこうした強みと重なる場面が多いと考えています。
まず思い浮かぶのが、MVPやPoCのフェーズです。フロントエンドとバックエンドAPIを、GoやFastAPIといった慣れた言語で書きつつ1つのプロジェクトに同居させれば、インフラ構築の初期コストを圧縮したまま検証を回せます。vercel deploy だけで公開まで届くため、アイデアを形にして触ってもらうまでのリードタイムを短くできます。
次に、既に手元にあるDocker資産の活用です。社内ツールやAPIをコンテナ化してある場合、それをクラスタ運用の手間なしに公開したいという需要は少なくありません。デーモンやクラスタ管理から解放されることで、運用担当を張り付けずに検証環境や社内向けサービスを立ち上げられます。加えて、Active CPU Pricingの考え方によって、常時アクセスがあるわけではない検証環境のアイドルコストを抑えられる点も現場の判断を後押しします。
これらを顧客のメリットに翻訳すると、インフラ運用工数の削減、企画から公開までのリードタイム短縮、そして使った分だけという課金によるコスト最適化にまとまります。並走型でDXを支援するRagateにとって、こうした選択肢を状況に応じて提案できることは価値につながると考えています。
導入前に押さえておきたい注意点
手軽さの一方で、設計上いくつか意識すべき点があります。前述のとおりプロセスはステートレス前提のため、永続的に保持したいデータは外部サービスへ逃がす構成が基本になります。ここを曖昧にしたまま進めると、スケール時に思わぬ挙動を招きかねません。
また、料金の単価や無料枠、提供リージョン、提供区分といった数値的な条件は、本記事では概念レベルの整理にとどめています。実際に採用を判断する際は、公式の最新情報を必ず確認することをおすすめします。既存のAWSやサーバーレス構成とどう使い分けるか、あるいは併用するかも、ワークロードの性質に応じて見極めたいところです。適材適所で組み合わせてこそ、それぞれの強みが生きてきます。
Vercelにコンテナを載せられるようになったことで、フロントエンドとバックエンドを同じ土俵で扱う選択肢が現実味を帯びてきました。MVPの立ち上げから既存資産の公開まで、Ragateが提供する開発支援の引き出しにまた一つ選択肢が加わったと言えます。
本記事はVercel公式ブログ（https://vercel.com/blog/dockerfile-on-vercel）の発表内容をもとに構成しています。
