Link to headingKey components for building secure connections

To enable the integration between Hive and Secure Compute, several key components work together.

Link to headingConnectors

EC2 instances running inside the Secure Compute network that terminate WireGuard® connections and securely route network traffic. These connectors behave as if they were part of the Hive network, enabling seamless communication. Each connector runs a daemon that interfaces with the Key Exchange Service to manage key distribution and routing information. Additionally, a WireGuard interface on each connector is responsible for creating secure tunnels with each Hive cell.

The instances are managed by autoscalers with custom Amazon Machine Images (AMIs) built by us, ensuring the connectors are ready to handle traffic efficiently as soon as they are instantiated. These instances are set up to be cycle frequently to ensure the system is up to date, and that their keys are short-lived and ephemeral.

Link to headingKey Exchange Service

Facilitates key distribution across private networks and EC2 instances. It manages tasks such as sharing WireGuard public keys, distributing box and connector IPs, and cleaning up stale resources. This service is internal to us and ensures that all peers in the network are authenticated and authorized to participate.

Link to headingWireGuard

Encrypts traffic between Hive cells and Secure Compute networks, ensuring security and privacy. It’s exposed on the connector side but always initiated from the Hive box side, guaranteeing that connections are tracked and secure by default.

Each Hive cell initiates a secure tunnel with the connector’s WireGuard interface. Keys are generated at instance boot and distributed via the Key Exchange Service, with no persistence or reuse. They are automatically removed when instances shut down, maintaining a secure lifecycle.

Link to headingNetwork Routing

When a Secure Compute connected cell starts up, we move its network resources into a namespace that is associated with the secure tunnel. This allows programmatic access to Linux's netlink layer to set up namespaces, routing, source-based routing, and with custom CNI plugins. This setup ensures traffic flows correctly and securely back through the same path it came from, maintaining reliability and security.

Link to headingHow secure traffic flows through the system

When a cell in a Hive box initiates a network call, the traffic is encrypted by a WireGuard interface configured with a unique private IP for the box. The traffic flows through the appropriate connector in the Secure Compute network, where it’s decrypted and routed to its destination.

To handle this routing, we create one namespace per WireGuard interface within the box. Each namespace includes a WireGuard device that serves as the gateway for encrypted traffic. The host-side of the tunnel from a cell is placed inside this namespace, ensuring all cell traffic is encrypted and correctly routed.

On the connector side, the setup is simpler. A single WireGuard device handles all incoming traffic, configured with the box as a peer. This abstraction ensures the connector doesn’t need to know the specifics of which device generated the traffic—just that it’s coming from an authenticated and authorized peer.

Link to headingStarting a new Secure Compute build

When a build requiring Secure Compute is created, the build pipeline submits a Secure Compute ID, tied to the Secure Compute network, within the build task payload. The Hive box uses this information to find a network interfaces so that all cell traffic routes through the appropriate connector.

Then, a new cell is provisioned in about 5 seconds. The traffic from the cell is encrypted, routed to the connector, and securely processed within the Secure Compute network.

Link to headingBefore and after: Securing builds with efficiency

Before Hive, secure builds were run using Fargate within the private network. While effective for security, Fargate introduced significant delays. Provisioning times took up to 90 seconds before a build could even start. This delay directly impacted iteration velocity.

By transitioning to Hive, we’ve reduced provisioning times dramatically—from 90 seconds to 5 seconds. Hive’s architecture allows us to spawn cells and quickly provision secure environments, ensuring builds start faster while maintaining the same level of network security. This improvement speeds up workflows and delivers a more consistent and efficient experience for sensitive workloads.

Link to headingBuild faster and connect securely

Hive is more than a compute platform—it’s the backbone of Vercel’s infrastructure, delivering optimal performance, security, and automatic scale. Improved provisioning times and build performance means you can ship quickly, even in the most demanding and sensitive workflows.