VercelLogotype
AI Cloud
Core Platform
Security
Company
Learn
Open Source
Use Cases
Tools
Users
The safest way to run code you didn’t write.
Modern apps increasingly need to execute code they didn’t author. From AI agents, customer scripts, or dynamic systems. remote-sandbox.vercel.run Sandbox is not running Agent Generate a Next.js app that allows to list and search Emojis Create Sandbox Upload files Execute Execute Get Sandbox URL
Reducing the risk of untrusted code, at scale. Cost-efficient, scalable execution with Fluid compute
Vercel Sandbox runs on Fluid compute, Vercel optimized execution model that scales CPU and memory dynamically across millions of executions.
With Active CPU pricing, you’re billed only when code is actively running, not during idle or wait time, resulting in up to 95% lower cost for workloads with bursty or I/O-bound patterns. “
Vercel Sandbox expands what our frontend infrastructure can handle. We plan to rely on it more for running untrusted code in AI workflows and for integrating tools that cannot run in a Node.js serverless function.”
Tudor Golubenco
CTO, Xata Xata “
Cua lets teams run computer-use agents from their apps with 100+ compatible VLMs — agents operate real desktops backed by Vercel Sandbox. Next.js playground on Vercel; agents execute in Vercel Sandbox via Cua with logs, replays, and evals — fully suited for reinforcement learning (RL) workflows.”
Francesco Bonacci
Founder, Cua AI Cua Get started
You can get started with Vercel Sandbox quickly and easily. Launch a secure, interactive sandbox environment in milliseconds.
$ npx sandbox create –connect
Quickly give Vercel Sandbox a try with your AI tool of choice. Bootstrap a simple Node.js CLI that creates a Vercel sandbox. Use this code:
import { Sandbox } from ‘@vercel/sandbox’;
const sandbox = await Sandbox.create();
const { exitCode } = await sandbox.runCommand({ cmd: ‘node’, args: [‘-e’, ‘process.exit(0)’], });
console.log(exitCode === 0 ? ‘ok’ : ‘failed’);
await sandbox.stop();
Include auth setup (vercel login && vercel link) with error handling. Frequently Asked Questions
Vercel Sandbox is an on-demand, isolated Linux microVM that runs arbitrary code safely through an SDK or CLI.
Sandbox gives you secure microVM isolation, built-in authentication and observability, and usage-based pricing without any infrastructure to maintain.
Yes. Sandbox is purpose-built to execute untrusted or AI-generated code in fully isolated, short-lived environments.
Each sandbox runs inside a Firecracker microVM on the same infrastructure that powers Vercel’s build system.
Node.js 22 and Python 3.13 are available by default, with more runtimes coming soon.
Yes. Each sandbox runs on Amazon Linux 2023, so you can install packages with dnf and use sudo as needed.
Sandboxes run for 5 minutes by default, up to 45 minutes on Hobby and 5 hours on Pro and Enterprise plans, with programmatic extensions available.
Each sandbox can use up to 8 vCPUs and 2 GB of RAM per vCPU.
Yes. You can open up to four ports and access them through a sandbox URL, such as sandbox.domain(port).
You can view active sandboxes in the Observability → Sandboxes view for your project, and stream real-time logs to your terminal.
Ready to deploy? Start building with a free account. Speak to an expert for your Pro or Enterprise needs.
Trial Vercel with higher execution, increased app bandwidth, Speed Insights, team features, and more. Products
AI
Enterprise
Fluid Compute
Next.js
Observability
Previews
Rendering
Security
Turbo
Domains
Sandbox
Workflow
v0
Resources
Community
Docs
Knowledge Base
Academy
Help
Integrations
Platforms
Pricing
Resources
Solution Partners
Startups
Templates
Company
About
Blog
Careers
Changelog
Contact Us
Customers
Events
Partners
Shipped
Privacy Policy
Social
GitHub
LinkedIn
Twitter
YouTube
Loading status… Select a display theme: system light dark
vercel sandboxの使い道を教えて
Vercel Sandbox は、Vercel が提供する「短時間で立ち上がる隔離された Linux microVM（Firecracker）」で、自分が書いていない（=信頼できない可能性がある）コードを安全に実行するための実行環境です。Next.js のサーバレス関数や Edge ではやりにくい「任意コード実行」を、より強い隔離で扱えます。
もし「具体的にどんなプロダクトで使いたいか（例：ユーザースクリプト、AIエージェント、オンラインIDEなど）」を教えてくれれば、Sandboxでの構成例（API設計、権限制御、ログ/保存、コスト見積もりの考え方）まで絞って提案できます。
いまいちイメージ湧かないんですけど。 今までのソリューションや手段とは何が違うの？ 大量の実行を想定（AIワークロード向き）とあるけど、そんなシチュなんてあるの？
Vercel Sandbox を「何が新しいのか」「どんな大量実行があるのか」が腹落ちする形で整理します。ポイントは “任意コード実行”を、サーバレス関数より強い隔離（microVM）で、しかも大量に回せるように製品化したもの です。
Serverless/Edge は基本的に「自社が書いたコード」を安全に運用するためのもので、ユーザーやAIが生成した“怪しいコード”を走らせる用途は想定が弱いです。
結論：「自社コード」なら Serverless、 「他人/AIのコード」なら Sandbox が分かりやすい。
「コンテナで隔離して実行」は昔からある王道です。違いは 運用と隔離の“前提”。
結論：Dockerで作れるが、“任意コード実行基盤”を自前で作る面倒を製品として肩代わりしている。
「毎秒数千のコード実行」みたいな極端な話だけじゃないです。AI時代だと “小さい実行が大量に発生する”が普通に起きます。
例：あなたのアプリに「AIにCSV整理を頼む」機能があるとします。
ユーザー1人の1回の操作が、裏で 10〜50回の実行になることがあります。
これが 1000ユーザー / 日 になると、数万実行/日は現実的です。
エージェントは「一発で完成」よりも、次のように分割します。
1つの依頼が 複数コマンド実行に分解されるので、実行回数が増えがちです。
例：
こういうのは、ユーザーが増えるほど イベント数＝実行数で増えます。
さらに「ユーザーコードは信頼できない」ので Sandbox が刺さる。
1クラスで数百人が、課題提出のたびに何回も実行 → 短時間にバーストします。
サンドボックスは短命実行を捌くのに向いています。
あなたの Next.js アプリで「ユーザーが貼ったJSを実行して結果を返す」機能を作るとします。
node script.js → 出力回収 → Sandbox破棄もし「今イメージできない」の原因が、あなたの作っているものに“他人のコードを実行する要件がない”からなら、それが正常です。
逆に、次のどれかがあるなら刺さりやすいです：
1) AIにコードを書かせて実行したい（データ加工、repo操作、テスト実行）
2) ユーザーがスクリプト/式/プラグインを書ける機能を入れたい
3) OSツール（変換・解析）を安全に動かしたい
あなたが作っているプロダクト（または作りたい機能）を1〜2行で教えてください。「Sandbox が必要な場面か」「代替（ServerlessやQueue+Worker）の方がいいか」を、その前提で具体構成に落とします。
sandboxを使う時は冪等性を確保するべきですよね？ 毎回一から vm をつくって、必要な環境をセットアップして、コードを実行して、をできるようにする。 基本的にその理解で合っていて、Vercel Sandbox を「短命・使い捨ての実行環境」として使うなら 冪等性（同じ入力→同じ結果、途中で落ちても再実行できる）を前提に設計するのがほぼ必須です。理由は「VMがいつでも捨てられる/作り直される」ことが価値であり、そこに依存すると運用が壊れるからです。
ただし、冪等性を“Sandboxの中で全部完結”させるというより、外側（あなたのアプリ側）でジョブを冪等に管理し、Sandboxは純粋な実行器にするのがコツです。
典型フローはおっしゃる通りで、
このとき Sandbox内の状態は信用しない / 再利用を前提にしない のが基本です（キャッシュを置いて高速化、は“最適化”として後から）。
→ 「同じジョブをもう一回投げる」が避けられないので、二重実行されても壊れない設計が必要。
例：
→ Sandboxの中で副作用を起こすなら、必ず冪等化が必要。
jobId を発行（UUIDなど）jobId に紐づけて保存jobId をユニークにして 二重コミットを防ぐ（UPSERT / unique制約）これで、Sandboxが何回走っても最終結果がブレにくい。
これができると冪等性が一気に簡単になります。
StripeのIdempotency-Keyのように、外部が冪等キー対応しているなら必ず使う。
対応してないAPIなら、あなた側で「このjobIdでは既に呼んだ」記録を持つ。
毎回クリーンに作ってセットアップするのは“正”です。ただ、セットアップが重い場合は次を検討します。
dnf install -y ... を何度走らせてもOK、みたいにVercel Sandbox自体に「常に同じVMを温存して使い回す」発想を強く持つと、結局不安定になります。
jobId（冪等キー）を全リクエストに付与もし「何をSandbox内でやって、何を外に出すべきか」を具体に引きたいので、想定ユースケース（例：ユーザースクリプト実行、AIが生成したPythonでETL、リポジトリに対するテスト実行など）を教えてください。副作用ポイントごとに冪等化の設計を落とし込めます。
vercel sandbox を使うときの具体的なフローは？ API で vm 起動命令と実行させたいコードを送る？
典型は「APIで“VMに入ってコマンド叩く”」というより、あなたのアプリ（Next.js / Backend）から Vercel Sandbox SDK/CLI を使って microVM を作り、VM内でコマンドを実行して、結果（stdout/stderr/成果物）を回収して捨てる、という流れです。
（＝HTTPで“コード文字列”を投げて勝手に実行してくれる単体サービス、というより「隔離実行環境をAPIで操作する」イメージ）
以下、実運用でよくある具体フローを2パターンで。
Sandbox.create() でSandbox作成sandbox.runCommand() で実行（node/python、任意コマンド）sandbox.stop() で破棄向いてるもの:
向いてるもの:
概ね Yes ですが、よくある設計はこう整理すると安全で運用しやすいです。
つまり「クライアントがVercel Sandboxへ直接コードを投げる」より、必ずあなたのサーバ側が仲介して
import { Sandbox } from "@vercel/sandbox";
export async function runUserCode({ files, cmd, args }) {
const sb = await Sandbox.create();
try {
// 例: ファイル配置（APIは実際のSDKの形に合わせて）
// await sb.writeFile("/work/index.js", files["index.js"]);
const result = await sb.runCommand({ cmd, args });
// result: exitCode, stdout, stderr ... のような情報を回収
return result;
} finally {
await sb.stop();
}
}
あなたの想定はどれに近いですか？
1) ユーザーが貼ったJS/Pythonを1回実行して結果を返す（同期）
2) AIが何度も試しながら実行する（非同期・複数回）
3) OSツール込みで変換（pandoc/ffmpeg等）
それで、具体的な「ファイルの渡し方」「結果の取り回し」「冪等化」をその前提でフロー図レベルまで落とします。
え？ Sandbox.create() や runCommand() はローカルで microVM 立ち上げるってこと？違うよね？
違います。Sandbox.create() や runCommand() は ローカルPC上で microVM を起動するものではなく、Vercel のインフラ上（リモート）で sandbox（Firecracker microVM）を作って、その中でコマンドを実行するための SDK 呼び出しです。
Sandbox.create() を呼ぶrunCommand() は「そのリモートVMの中で cmd を実行して、stdout/stderr/exitCode を返して」という命令つまり SDK は “VMをローカルで動かすライブラリ” ではなく、リモート実行環境を操作するクライアントです。
npx sandbox create --connect は？これも同じで、CLIが リモートに sandbox を作って、それに ローカル端末から接続（ログ閲覧・操作）しているだけです。Docker Desktop みたいにローカルでVMが立つわけではありません。
Sandbox.create() = 「VercelにVM作って」と頼むsandbox.runCommand(...) = 「そのVMの中でこのコマンド実行して」sandbox.stop() = 「VM捨てて」もし「ローカルから呼ぶ場合、認証は何が必要？」「本番で Next.js の Route Handler から呼ぶのはアリ？」みたいな運用面の前提を教えてくれたら、その形での推奨構成を具体化します。