Notion Workers let you write and deploy code to give Custom Agents new powers: sync external data, trigger automations, call any API. With Workers, developers can build agents that sync CRM data on a schedule, open issues when error rates spike, and turn Slack threads into formatted content.

Under the hood, every Worker runs on Vercel Sandbox.

Link to headingThe problem: safely running code from any developer or agent

Notion wanted to let anyone extend their platform with custom code. That's a hard infrastructure problem, but an even bigger security problem. Every Notion Worker runs arbitrary code generated by a third-party developer or agent, on behalf of a Notion user, potentially inside an enterprise workspace.

Without proper isolation, a Worker would run in the same environment as the Custom Agent, with access to its secrets, permissions, and everything else in that execution context. A single prompt injection could exfiltrate credentials or access another user's data.

The requirements were clear:

• Hard isolation: One Notion Worker can never access another's data or state

• Credential security: Notion Workers need API keys to talk to external services, but those secrets can never be exposed to the code itself

• Network controls: Enterprise customers need guarantees about the external services a Worker is allowed to reach

• Scale: Workers need to support millions of users running concurrent executions without performance degradation

• State preservation: Workers need fast cold starts, which require the ability to snapshot and restore filesystem state

• Economics: A billing model that is built for agents with low CPU utilization rates

Link to headingWhy Vercel Sandbox

Vercel Sandbox runs each Notion Worker in an ephemeral Firecracker microVM. Every VM boots its own kernel, providing stronger isolation than containers. Each execution gets its own filesystem, its own network stack, and its own security boundary. When the Notion Worker finishes, the microVM is either destroyed or snapshotted for later retrieval.

To support workloads like Notion Workers at scale, Vercel Sandbox provides several critical capabilities:

Credential injection. Sandbox's firewall proxy can intercept and inject API keys into outbound requests at the network level, so credentials never enter the execution environment. For agent-driven workloads, this eliminates the most dangerous prompt injection vector: an agent being tricked into exfiltrating secrets. (We wrote about this architecture in depth in security boundaries in agentic architectures).

Network policies. Sandbox supports dynamic network policies that can be updated during runtime without restarting the process: start with internet access to install dependencies, then lock down egress before running untrusted code. Platform builders can pass these controls through to their own customers.

Snapshots. Install dependencies once, snapshot the filesystem state, and resume from that snapshot on subsequent invocations. Combined with active-CPU billing, where CPU costs only accrue when your code is actually executing, not waiting on I/O, this keeps costs predictable as usage scales.

Link to headingThe bigger picture: Notion as a developer platform

Notion Workers isn't a one-off feature. It's the beginning of Notion becoming a developer platform.

This shift requires infrastructure that Notion shouldn't have to build. Secure code execution, credential management, network isolation, file-sytem based snapshotting: these are hard problems that compound as the platform scales.

Vercel Sandbox handles the infrastructure complexity so Notion can focus on the developer experience.

Link to headingWhat developers are building with Notion Workers

Notion Workers support three main patterns: third-party data syncing, custom automations, and AI agent tools.

Developers use them to sync external data, such as CRM records, analytics, and support tickets, into Notion on a schedule. A Worker can also be attached to a button, triggering arbitrary code with a single click. And when Notion's custom agents invoke Workers as tool calls, they become far more capable than agents limited to pre-built integrations.

Link to headingExtend your platform with Vercel Sandbox

Notion Workers requires the same capabilities as other agent platforms. Any platform that wants to let users or agents run custom code faces the same set of problems: isolation, credential security, network controls, and scale.

Vercel Sandbox provides these as capabilities out of the box. If you're building a platform that needs to run untrusted code, whether for AI agents, developer plugins, or workflow automation, then this is how you do it.