How Hive and Secure Compute are wired together

Vercel's internal compute platform, Hive, powers all builds across the platform. For builds with stricter security requirements, Hive plugs into Secure Compute, which gives teams private connectivity to their backends. Moving Secure Compute onto Hive cut provisioning time from 90 seconds to 5 seconds and improved build performance by an average of 30%.

Four components make the integration work:

  • Connectors: EC2 instances inside the Secure Compute network that terminate WireGuard® connections and route network traffic. Each connector runs a daemon that talks to the Key Exchange Service for key and routing distribution, plus a WireGuard interface that establishes secure tunnels with each Hive cell. Connectors are managed by autoscalers using custom Amazon Machine Images (AMIs), and they cycle frequently so keys stay short-lived and ephemeral.
  • Key Exchange Service: An internal service that distributes WireGuard public keys, assigns box and connector IPs, and cleans up stale resources across private networks and EC2 instances. It ensures all network peers are authenticated and authorized.
  • WireGuard: Encrypts traffic between Hive cells and Secure Compute networks. The tunnel is always initiated from the Hive box side, never the connector side. Keys are generated at instance boot, distributed via the Key Exchange Service, and removed automatically at shutdown—there's no persistence or reuse.
  • Network Routing: When a Secure Compute connected cell starts, its network resources move into a namespace tied to the secure tunnel. This gives programmatic access to Linux's netlink layer for setting up namespaces, routing, source-based routing, and custom CNI plugins, so traffic returns through the same path it arrived on.

The path secure traffic takes

When a cell in a Hive box makes a network call, a WireGuard interface with a unique private IP encrypts the traffic. The encrypted packets travel to the appropriate connector in the Secure Compute network, where they're decrypted and routed to their final destination.

Inside the box, each WireGuard interface gets its own namespace. The namespace holds a WireGuard device that acts as the gateway for encrypted traffic, and the host-side of the tunnel from a cell sits in that namespace—so all cell traffic is encrypted and correctly routed by design.

The connector side is deliberately simpler: a single WireGuard device handles all incoming traffic with the box configured as a peer. The connector doesn't need to know which device generated the traffic, only that it came from an authenticated, authorized peer.

Spinning up a Secure Compute build

When a build requiring Secure Compute is created, the build pipeline includes a Secure Compute ID in the build task payload, tied to the Secure Compute network. The Hive box uses that ID to locate a network interface so all cell traffic routes through the correct connector. A new cell provisions in roughly 5 seconds, with traffic encrypted, routed through the connector, and processed inside the Secure Compute network.

What the old architecture cost

Before Hive, secure builds ran on Fargate inside the private network. Security was solid, but provisioning took up to 90 seconds before a build could start—a significant drag on iteration speed.

Hive removes that bottleneck. Cells spawn quickly and secure environments provision in seconds, keeping the same level of network security while making secure workloads substantially faster and more consistent.