Vercel Services：フルスタックを Vercel で実行可能に
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Vercel Blog
Vercel は新機能「Vercel Services」を発表し、Next.js フロントエンドと FastAPI バックエンドなど複数のフレームワークを単一プロジェクトで統合して実行できる機能を追加した。これにより、開発者は異なるクラウドやデプロイワークフローを跨ぐことなく、原子的なデプロイを実現できるようになる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
ユーザーにとって、Next.js フロントエンドと FastAPI バックエンドを持つアプリは一つの製品のように感じられ、それを構築するエンジニアにとっても同じであるべきです。しかし実際には、これら 2 つの部分は異なるクラウド上で展開され、それぞれ異なる開発およびデプロイワークフローが用いられることがよくあります。
本日、Vercel Services を発表いたします。これにより、1 つの Vercel プロジェクト内で複数のフレームワークを実行できるようになります。これによって以下の機能が解放されます:
アトミックなデプロイメント：フロントエンド、バックエンド、およびその他のサービスは同期され、同時にデプロイまたはロールバックされます。
共有プレビューデプロイメント：あらゆる変更がすべてのサービスに与える影響を確認できます。
内部サービス間通信：サービスはパブリックインターネットを経由せずに互いに通信できます。
残りの部分は Vercel が処理します。ルーティング、ビルド、デプロイメント、および本番環境での自動スケーリングです。Vercel から既に知っている開発者体験が、今やアプリケーション全体をカバーするようになります。
Vercel Services でアプリケーションを構築する
vercel.json の services キーの下にサービス宣言を行い、ルーティング設定は明示的に記述してください:
サービスはリバースプロキシや CORS を必要とせずに、共有のルーティングテーブルにマウントできます。
サービスの構成は Vercel プラットフォームの複数のレベルで認識されます:
デプロイメントパネルでは、サービスのグラフが可視化されます。
ログ UI では、個別のサービスごとにフィルタリングが可能です。
vercel dev CLI はすべてのサービスを自動的に実行し、ローカル環境で本番に近い環境を提供します。
サービスバインディング
サービスは、パブリックインターネットを経由せずに内部で他のサービスと通信できます。新しいバインディング設定キーがこれを可能にする例を以下に示します:
これで JavaScript フロントエンドコードは、BACKEND_INTERNAL_URL 環境変数に格納された URL を介して Python サービスと内部で通信できるようになります:
サービス間トラフィックはパブリックインターネットへエグレスするのではなく、Vercel ネットワーク内に留まります。多数の独立したサービスを、ホスト間でつなぎ合わせた別々のデプロイメントではなく、同じ配線によって接続された一つのアプリケーションとして統合できます。
フレームワーク定義インフラストラクチャ
ほとんどのフレームワークは、ゼロ設定で Vercel 上で動作します。フレームワーク定義インフラストラクチャとは、各サービスのフレームワークが自動検出され、自動プロビジョニングされることを意味します。Python では FastAPI や Flask、TypeScript では Express や Hono がサポートされており、Go および Rust サーバーについても第一級サポートを提供しています。
サービスは Fluid compute 上で動作し、トラフィックに応じてオートスケーリングしますが、課金はアクティブな CPU 時間のみに対して行われます。しかし、フレームワーク定義の最適化はさらに深くまで及んでいます。例えば Django の場合、静的アセットがどこに存在するかを自動的に検出し、CDN から配信します。
フルスタックプラットフォーム
Vercel Services は、アプリケーションを構築して実行するための構造化された方法を Vercel に提供します。
これらのサービスは、バックエンドに必要なあらゆる要素を含むプラットフォーム上で動作します。API、エージェント、またはバググラウンドワーカーのいずれを構築している場合でも、計算リソース、データ、ネットワーク、バググラウンドワーク、および外部サービスへの安全な接続が含まれます。
エージェントサービス用の孤立型コンピューティング
エージェントはファイルの読み込み、コマンドの実行、コードの記述が可能です。しかし、この機能にはセキュリティが不可欠です。Vercel Sandbox は各エージェントに独自の Linux コンピューターを提供します：ファイルシステム、シェル、Docker サポート、そして独自のカーネルを備え、デプロイメントから完全に隔離されています。エージェントはコードを実行し、ファイルを grep 検索し、依存関係として Redis や Postgres を起動できます。サンドボックス内の何者も、本番環境にアクセスすることはできません。
自動永続化により、状態はセッション間で保持され、Pro プランではサンドボックスを最大 24 時間実行可能です。
WebSocket サポートを備えたリアルタイムバックエンド
Vercel Functions は、Node.js、Python、Go のいずれでバックエンドが記述されていても、すべての Vercel ランタイムにおいて永続的な WebSocket 接続を処理します。Socket.IO などの標準的な WebSocket ライブラリと連携し、Fluid コンピューティング上で Active CPU プライシング（従量課金）により動作するため、メッセージの処理に費やした時間に対してのみ課金され、接続がアイドル状態にある時間は課金対象となりません。
Vercel Connect で外部サービスへアクセス
エージェントやバックエンドは、プロジェクト外のサービス（Slack、GitHub、管理されたデータベースなど）にアクセスする必要がありますが、通常これは環境内に長期有効なシークレットを保存することを意味します。Vercel Connect はこれに代わり、アプリがランタイム時に要求する短期有効な認証情報を提供し、そのタスクにスコープを限定します。漏洩のリスクがある長期有効なシークレットは残されません。
サービス用のデータベースとストレージ
Vercel Marketplace から数回のクリックだけでデータベースをプロビジョニングでき、Neon や Supabase といったプロバイダーや、AWS の Aurora PostgreSQL、Aurora DSQL、DynamoDB から認証情報を自動的に注入されます。Amazon OpenSearch Serverless はフルテキスト検索とベクトル検索機能を追加し、Vercel Blob はオブジェクトストレージを処理します。これらすべてを Vercel を離れることなくクエリや管理が可能で、Blob および AWS 統合の両方とも、保存されたシークレットではなく、短期有効な OIDC トークン（OpenID Connect）を使用して認証を行います。
永続的なワークフローとバックグラウンドジョブの実行
Vercel Queues はリクエストパスから外れたバックグラウンドジョブを処理します。Vercel Workflow はクラッシュや再デプロイ後も耐性を持つ永続的な多段階プロセスを扱います。また、Vercel Cron はスケジュールに基づいて作業を実行します。これはリクエストを超えて存続するバックエンドの一部であり、他のすべてのコンポーネントと同じプラットフォーム上で動作するため、長時間実行されるバックエンド側には別個のインフラストラクチャは不要です。
プライベート接続と適切なコンピューティングでの実行
バックエンドがパブリックサービスではなく、プライベートデータベースや内部ネットワークにアクセスする必要がある場合、Secure Compute（セキュア・コンピュート）、静的 IP アドレス、VPC ピアリング（仮想プライベートクラウドピアリング）がその経路を開きます。
Pro および Enterprise プランでは関数が最大 30 分間実行可能で、Python バックエンドは最大 500MB の依存関係を伴ってデプロイできます。
そのすべてを支える基盤として、Fluid compute（流体コンピューティング）が新規プロジェクトのデフォルトとなり、Active CPU プライシングではコードが実際に実行されている時間に対して課金され、待機している時間は課金されません。これはアイドル状態が多いバックエンドや AI 作業に適した料金モデルです。
出荷するすべてのものを収容する単一のプラットフォーム
Vercel Services は、フロントエンド、バックエンド、およびサポートサービスを一つのプロジェクトに統合します。これらはデフォルトで一緒に構築され、プレビューされ、デプロイされ、内部通信を行います。
計算（compute）、データ、キュー、ワークフロー、cron、セキュアなネットワーク、サンドボックス化されたエージェント環境のための Vercel 組み込みプリミティブと組み合わせることで、別々のプラットフォームを接続することなくフルスタックを実行できます。
サービスの構成を開始するには、Vercel Services のドキュメントおよびルーティングと通信に関するガイドをお読みください。Vercel 上でバックエンドを実行するのが初めての場合は、ゼロ設定バックエンドの投稿がスタート地点となります。
さらに読む
原文を表示
To a user, an app with a Next.js frontend and a FastAPI backend feels like one product, and the same should be true for the engineers who build it. Instead, the two pieces are often deployed across different clouds with different development and deployment workflows.
Today we're introducing Vercel Services, which lets you run multiple frameworks in one Vercel Project. This unlocks:
Atomic deployments: Your frontend, backend, and other services stay in sync and deploy or roll back together
Shared preview deployments: See how any change affects all your services
Internal service communication: Services can talk to each other without routing through the public Internet
Vercel handles the rest: routing, builds, deployments, and auto-scaling in production. The developer experience you already know from Vercel now covers your entire application.
Compose applications with Vercel Services
Declare your services under the services key in vercel.json keeping the routing configuration explicit:
Services can be mounted to a shared routing table without the need for a reverse proxy or CORS.
The services configuration is recognized at multiple levels of the Vercel platform:
The Deployments panel shows a visualization of services graph
The Logs UI allows filtering by individual service
The vercel dev CLI automatically runs all services giving you a production-like environment locally
Service bindings
Services can talk to other services internally, without routing through the public Internet. Here's an example how the new bindings configuration key enables that:
Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:
Service-to-service traffic stays on the Vercel network rather than egressing to the public internet. Many independent services can become one application connected by the same wiring, rather than separate deployments that you stitch together across hosts.
Framework-defined infrastructure
Most frameworks run on Vercel with zero configuration. Framework-defined infrastructure means that each service's framework is auto-detected and auto-provisioned, from FastAPI and Flask for Python to Express and Hono for TypeScript, with first-class support for Go and Rust servers.
Services run on Fluid compute, autoscaling with traffic, while you pay only for active CPU time. But framework-defined optimizations go even deeper. With Django, for example, we automatically detect where static assets live and serve them from the CDN.
The full stack platform
Vercel Services gives Vercel a structured way to build and run your application.
Those services run on a platform that includes everything any backend could need, whether you're building APIs, agents, or background workers: compute, data, networking, background work, and secure connections to external services.
Isolated compute for agent services
Agents can read files, run commands, and write code. But that capability needs to be secure. Vercel Sandbox gives each agent its own Linux computer: a filesystem, a shell, Docker support, and its own kernel, completely isolated from your deployments. Agents can execute code, grep files, and spin up Redis or Postgres as dependencies. Nothing inside the sandbox can touch your production environment.
With automatic persistence, state carries between sessions, and on Pro, sandboxes can run for up to 24 hours.
Real-time backends with WebSocket support
Vercel Functions handle persistent WebSocket connections in every Vercel runtime, whether your backend is written in Node.js, Python, or Go. They work with standard WebSocket libraries like Socket.IO, and because connections run on Fluid compute with Active CPU pricing, you only pay for the time spent processing messages, not the time a connection sits idle.
Reach external services with Vercel Connect
Agents and backends need to reach services outside your project (Slack, GitHub, managed databases), which usually means storing a long-lived secret in your environment. Vercel Connect replaces that with a short-lived credential your app requests at runtime, scoped to the task in front of it. There is no long-lived secret left to leak.
Databases and storage for your services
You can provision a database from the Vercel Marketplace in a few clicks, with credentials injected for you, from providers like Neon, Supabase, and from AWS with Aurora PostgreSQL, Aurora DSQL, and DynamoDB. Amazon OpenSearch Serverless adds full-text and vector search, and Vercel Blob handles object storage. You can query and manage any of it without leaving Vercel, and both Blob and the AWS integrations authenticate with short-lived OIDC tokens rather than stored secrets.
Run durable workflows and background jobs
Vercel Queues processes background jobs off the request path. Vercel Workflow handles durable multi-step processes that survive crashes and redeploys. And Vercel Cron runs work on a schedule. This is the part of a backend that outlives a request, and it runs on the same platform as everything else, so the long-running side of your backend needs no separate infrastructure.
Connect privately and run on the right compute
When a backend needs to reach a private database or an internal network instead of a public service, Secure Compute, static IPs, and VPC peering open that path.
Functions run for up to 30 minutes on Pro and Enterprise, and Python backends deploy with up to 500mb of dependencies.
Underneath all of it, Fluid compute is the default for new projects, and Active CPU pricing bills for the time your code is actually running rather than the time it waits, the right shape for idle-heavy backend and AI work.
A single platform for everything you ship
Vercel Services brings your frontend, backend, and supporting services into one project. They build together, preview together, deploy together, and communicate internally by default.
Combined with Vercel's built-in primitives for compute, data, queues, workflows, cron, secure networking, and sandboxed agent environments, you can run the full stack without stitching together separate platforms.
To start composing services, read the Vercel Services documentation and the routing and communication guide. If you are new to running a backend on Vercel, the zero-config backends post is the place to begin.
Read more
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み