You can now transfer Marketplace resources between teams directly from the Vercel dashboard without relying on the API. This simplifies resource management during team or project changes. Both owner and member roles on the source and destination teams can initiate transfers.

The destination team must have the corresponding integration installed before receiving a resource. The feature currently supports transfer databases from Prisma, Neon and Supabase , with additional providers and product support coming soon.

Start from your database settings in the dashboard, or learn more in the documentation.

The axios npm package was compromised in an active supply chain attack discovered on March 31, 2026. Vercel investigated this issue and implemented remediation actions to protect the platform. No Vercel systems were affected.

The npm registry removed the compromised package versions, and the latest tag now points to the safe axios@1.14.0 release.

• We’ve blocked outgoing access from our build infrastructure to the Command & Control hostname sfrclak.com.

• The malicious version of the package has been blocked and unpublished from npm.

• Vercel’s own infrastructure and applications have been unaffected. We recommend checking your supply chain for exposure.

Link to headingAffected versions

Projects using axios@1.14.1 or axios@0.30.4 in their build environments are affected by this vulnerability.

• Check your dependencies and lockfiles for:

  • axios@1.14.1

  • axios@0.30.4

  • plain-crypto-js@4.2.1

Link to headingResolution

If your deployments used the malicious package version listed above in your build environment, take the following actions:

• Search your lockfiles and node_modules for plain-crypto-js to identify compromised installations

• Redeploy your project to ensure your build uses a clean version of axios

• Rotate API keys, database credentials, tokens, and any other sensitive values present in your build environment

• Review your dependency tree for references to axios@1.14.1 or axios@0.30.4 and update them to axios@1.14.0

New Vercel projects will honor cache-control headers by default when proxying requests to external origins, starting April 6th.

Previously, responses served through rewrites to external origins were uncached by default, and enabling caching required the x-vercel-enable-rewrite-caching header in vercel.json. Now, Vercel's CDN automatically respects your origin's caching headers.

What's changing:

• For new projects, Vercel will cache responses from external origins according to upstream Cache-Control, CDN-Cache-Control and Vercel-CDN-Cache-Control headers by default.

• You can use Cache Tags (Vercel-Cache-Tag header) from your origins to purge cached content.

• Existing projects can opt in to the new caching behavior from the project dashboard.

• You can opt out of caching for specific request paths by setting the x-vercel-enable-rewrite-caching header to 0.

Review your upstream cache headers before April 6th when creating a new project that proxies to external origins without caching, ensuring they reflect your intended caching strategy.

Learn more about Rewrites to External Origins and configure routing in the CDN tab of your project settings.

The Vercel plugin now supports OpenAI Codex and the Codex CLI.

With the plugin, teams can access over 39 platform skills, three specialist agents, and real-time code validation to assist with their development workflow.

Install it in the Codex app or from the Codex CLI:

1
codex
2
/plugins

Learn more about the plugin in the documentation.

Vercel Sandboxes can now automatically save their filesystem state when stopped and restore it when resumed. This removes the need for manual snapshots, making it easier to run long-running, durable sandboxes that continue where you left off.

Link to headingHow it works

A sandbox is the durable identity, now identified by a name, its filesystem state, and configuration options. A session is the compute tied to that state, invoked as needed.

Automatic persistence introduces orchestration that separates storage from compute, reducing the need for manual snapshotting, so:

• when you stop a sandbox, the session shuts down but the filesystem is automatically snapshotted.

• when you resume, a new session boots from that snapshot. This state storage is not charged, so you pay when your setting is active.

1
import { Sandbox } from '@vercel/sandbox';
2

3
// Create a named sandbox
4
const sandbox = await Sandbox.create({ name: 'user-a-workspace' });
5
await sandbox.runCommand('npm', ['install']);
6
await sandbox.stop();
7

8
// Later, resume where you left off
9
const sandbox = await Sandbox.get({ name: 'user-a-workspace' });
10
await sandbox.runCommand('npm', ['run', 'dev']);

Persistence is enabled by default in the beta SDK, can be disabled between sessions with persistent: false. When disabled, the sandbox still exists after being stopped and can be resumed by its name, but each session starts with a clean filesystem.

If a sandbox is stopped and you run a command, the SDK will transparently create a new session, so you don't need to check state or manually restart

1
const sandbox = await Sandbox.create({ name: "long-lived-sandbox" });
2
await sandbox.writeFiles([{
3
  path: "run.sh",
4
  content: Buffer.from('#!/bin/bash\necho "Hello!"'),
5
  mode: 0o755,
6
}]);
7

8
// Days later
9
const resumedSandbox = await Sandbox.get({ name: "long-lived-sandbox" });
10
console.log(resumedSandbox.status); // stopped automatically
11

12
await resumedSandbox.runCommand("./run.sh"); // logs "Hello!"
13
console.log(resumedSandbox.status); // running

The beta SDK adds methods for managing sandboxes over their lifetime:

1
const sandbox = await Sandbox.get({ name: 'user-alice' });
2

3
// Scale up resources on a running sandbox
4
await sandbox.update({ resources: { vcpus: 4 } });
5

6
// Inspect session history and snapshots
7
const { sessions } = await sandbox.listSessions();
8
const { snapshots } = await sandbox.listSnapshots();
9

10
// Search across sandboxes
11
const { sandboxes } = await Sandbox.list({
12
  namePrefix: 'user-',
13
  sortBy: 'name',
14
});
15

16
// Permanently remove a sandbox and all its data
17
await sandbox.delete();

The beta CLI adds configuration management and session inspection:

1
  # Spin up a sandbox for a user
2
  sandbox create --name user-alice
3

4
  # User runs commands — if the sandbox timed out, it resumes automatically
5
  sandbox run --name user-alice -- npm test
6

7
  # Check what happened across sessions
8
  sandbox sessions list user-alice
9

10
  # Tune resources without recreating
11
  sandbox config vcpus user-alice 4
12
  sandbox config timeout user-alice 5h

This feature is in beta and requires upgrading to the beta SDK and CLI packages.

Install the beta packages to try persistent sandboxes today: pnpm install @vercel/sandbox@beta for the SDK, and pnpm install -g sandbox@beta for the CLI.

Persistent sandboxes are available in beta on all plans.

Learn more in the documentation.

Vercel Sandboxes created with the latest beta package will now have a unique, customizable name within your project, replacing the previous ID-based identification. Names make sandboxes easy to find and reference:

1
import { Sandbox } from '@vercel/sandbox';
2

3
// Create a named sandbox
4
const sandbox = await Sandbox.create({ name: 'user-a-workspace' });
5
await sandbox.runCommand('npm', ['install']);
6
await sandbox.stop();
7

8
// Later, resume where you left off
9
const sandbox = await Sandbox.get({ name: 'user-a-workspace' });
10
await sandbox.runCommand('npm', ['run', 'dev']);

The beta CLI adds configuration management and session inspection:

1
  # Spin up a sandbox for a user
2
  sandbox create --name user-alice
3

4
  # User runs commands — if the sandbox timed out, it resumes automatically
5
  sandbox run --name user-alice -- npm test
6

7
  # Check what happened across sessions
8
  sandbox sessions list user-alice

Named sandboxes are the mechanism for identifying automatic persistence, which allows your session to be more easily identified for at both time of creation resumption.

Install the beta packages to try named sandboxes today: pnpm install @vercel/sandbox@beta for the SDK, and pnpm install -g sandbox@beta for the CLI.

Learn more in the documentation.

Chat SDK now lets you control what happens when a new message arrives before a previous one finishes processing, with the new concurrency option for the Chat class.

1
const bot = new Chat({
2
  concurrency: {
3
    strategy: "queue",
4
    maxQueueSize: 20,
5
    onQueueFull: "drop-oldest",
6
    queueEntryTtlMs: 60_000,
7
  },
8
  // ...
9
});

Four strategies are available:

• drop (default): discards incoming messages

• queue: processes the latest message after the handler finishes

• debounce: waits for a pause in conversation, processes only the final message

• concurrent: processes every message immediately, no locking

Read the documentation to get started.

Chat SDK now supports scheduled messages on Slack, allowing you to deliver a message at a future time.

Use thread.schedule() and pass your message and a postAt date, like:

1
const scheduled = await thread.schedule("Reminder: standup in 5 minutes!", {
2
    postAt: new Date("2026-03-09T08:55:00Z"),
3
});
4

5
// Cancel before delivery
6
await scheduled.cancel();

Read the documentation to get started.