Customers

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. The 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 Why 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. The 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. What 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. Extend 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.

Karson Seeley, Harpreet Arora

GitBook on Vercel 30,000 documentation sites hosted on a single Vercel deployment 120 million monthly page views served from the edge 40,000 cache invalidations processed daily, each resolved in under 300ms 41% of all traffic now comes from AI crawlers and automated systems GitBook hosts 30,000 documentation sites on Vercel, serving 120 million page views every month. Companies like n8n, Nvidia, and Zoom trust the platform to keep their docs fast and current. For modern engineering teams and coding agents, documentation is as critical as the production code it describes, and GitBook sits at the center of that expectation. GitBook's publishing model mirrors how teams ship software: propose changes, review, and merge. With 30,000 independently managed sites each on its own update cadence, keeping content fast and fresh was a complicated engineering problem. Before migrating to Vercel, site editors would hit merge, visit the published site to validate, and see old version of the content. "One of our customers planned a large feature release, and on launch day, the docs lagged behind the rest of the product," says Steven Hall, Head of Engineering at GitBook. "That was the moment we really internalized that docs are as important as your code going to production." Making merge mean live at multi-tenant scale GitBook's published content frontend runs on Next.js and is open source. When Vercel's use cache directive became available, the team saw a solution to their speed problem: cache individual data-fetching functions rather than full page responses. That meant expensive API calls were deduplicated across requests, and cache behavior became visible directly in code rather than buried in external configuration. The harder problem was invalidation. In a multi-tenant system, a broad cache purge is expensive and wasteful. One team merging a typo fix shouldn't trigger revalidation for 29,999 other sites. GitBook already had a reliable signal for when content becomes stale: a merge event, whether through GitBook's app, GitHub, or GitLab. The team built tag-based invalidation triggered directly by those events. Cached data is tagged by content unit, and when a merge occurs, only the affected tags are revalidated. Everything else stays cached. Today, when a change is merged, updated content becomes visible globally within 300 milliseconds. GitBook processes 40,000 of these invalidations daily. "Outside of building our own caching, I don't think we considered anything else," says Hall. What changes when 41% of your traffic isn't human AI-driven traffic to GitBook documentation surged 5x year-over-year in 2025 and now accounts for 41% of all page views. LLMs and automated systems crawl docs programmatically, using GitBook as a source of truth for internal tooling, SDKs, and AI applications. That changes the infrastructure math. A human reader might visit a handful of pages on a single docs site, but an AI crawler can sweep every page across hundreds of sites in a single session, hitting cold cache paths that no human would visit. Multiply that across 30,000 sites and the caching foundation has to handle not just more traffic, but fundamentally less predictable traffic. Content still has to be immediately consistent after every change, and infrastructure costs have to stay predictable even as volume climbs. Hall says they didn't choose the caching architecture because of AI specifically, but it turned out to be the right foundation. "We need fast docs regardless of whether AI or humans are reading them," he says. "Our target is closer to 100% cache hits. Cache hits mean fast docs, and fast docs are a critical feature of GitBook." The next 30,000 sites The caching infrastructure isn't finished. Features like adaptive documentation, which modifies content based on who's reading it, make multi-tenant caching meaningfully more complex. And as AI traffic keeps climbing, the volume of requests flowing through 30,000 sites will only grow. "Volume is going up everywhere," Hall says. "Engineers shipping more means more docs changes. LLMs are crawling more pages every day. Our main goal is to maintain that high bar for latency and predictability as we scale." GitBook is an intelligent documentation platform used by more than 30,000 teams to create, publish, and maintain product and developer documentation at scale. GitBook's published content frontend is open-source.

Eric DoddsContent Engineer

Conductor on Vercel Multiple parallel coding agents running at scale in the cloud Model-agnostic, works with Claude Code, Codex, and other coding agents Used by engineering teams at Notion, Linear, Ramp, and Life360 Interacting with a single coding agent feels natural, and Conductor makes directing a fleet of agents just as intuitive. It's a GUI for spinning up multiple coding agents in parallel, each working on an isolated branch of your codebase at once. You review their work, merge what works, and redirect the agents that need to keep iterating. Engineering teams loved it, but hardware was a real limitiation. Every agent ran on your machine, so the fan climbed, the CPU ran hot, and if you closed your laptop, the agents stopped. Charlie Holtz, co-founder and CEO of Conductor, spent time at Vercel before starting the company. He understands what developers lose when their environment imposes rules on how they can work. Cloud Workspaces, Conductor's remote execution layer built on Vercel Sandboxes, removes the local hardware constraint. Developers can now spawn multiple agents and close the lid without interrupting work. The journey from local to cloud Developers who adopted Conductor early felt the power. Notion's engineering team said, "It makes you feel like an octopus, where each one of your arms is working on something separately." The demand for remote execution came quickly. Developers wanted more agents running longer, and local hardware was the ceiling. For a six-person startup, going from local to cloud is a huge technical leap, and when the developers using Conductor work at companies like Linear and Ramp, provider choice is a matter of building trust with engineers choosing to run their code on infrastructure they don't own. The team evaluated several sandbox providers, weighing fast spin-up and snapshot support alongside longevity and the depth of the support relationship. Running parallel agents in the cloud Conductor built Cloud Workspaces on Vercel Sandboxes. When a developer opens a new workspace, agents spin up on a remote server instead of their local machine. The interface doesn't change. Holtz describes the result: "To our users it feels just like the local version of Conductor. They don't know the difference, which is amazing, and that's because Vercel Sandboxes are super fast." Conductor already supports Claude Code, Codex and other coding agents, but they are model agnostic. That means that no matter how often labs release updates, or what the next popular harness is, they can keep the same cloud layer underneath. As Holtz puts it: "The vibes shift every 3 months. Right now GPT-5.5 has the vibes on its side, but that's going change in another few months. Being agnostic to the providers is the key, and we get that with Vercel." One interface, whatever the frontier looks like next Conductor's bet is on the interface: the one place to direct your agents, review their work, and decide what to merge. With Vercel Sandbox, that interface goes wherever developers go. About Conductor: Conductor is a multi-agent IDE for running coding agents in parallel, each on isolated branches of your codebase. Model-agnostic by design, it works with Claude Code, Codex, and other coding agents.

Eric DoddsContent Engineer