Skip to content

VPN and mesh adapters

Some agent tools must reach private APIs: customer VPCs, on-prem knowledge bases, or partner extranets. Others need peer-to-peer meshes (short-lived cohorts, research pairs). Hard-coding one VPN stack would block enterprise adoption.

Celestial uses a VpnMeshPort adapter interface (ADR 028) with first-class targets:

ProviderRole
WireGuardFast modern tunnels; common default.
FirezoneIdentity-aware policy on top of WireGuard.
OpenVPNLegacy enterprise compatibility.
FreelanP2P / mesh-oriented scenarios.

Starflow pipelines can ensure a tunnel is up before Spacecraft tool steps run; sandbox isolation (see Sandbox adapters) composes so egress is policy-bound, not “agent has full internet.”

VpnMeshPort / NoopVpnMeshPort are defined in @celestial/agent-host-ports and re-exported from @celestial/shared for early wiring without a real tunnel.

Starflow graphs may include a vpn-connect node (ordered before downstream steps). Set vpnMeshProvider to a registry key; the host passes vpnMeshes on WorkflowEngineOptions / RunGraphRequest, optional strictVpnProviders, and vpnMeshFallbackKey (same semantics as sandbox). vpnConnectProfileId, vpnConnectMeshName, vpnConnectAdvertisedCidrs, and vpnConnectMode map to VpnMeshPort.connect. Successful connects stay up until the run finishes without a durable wait; the engine disconnects them on terminal completion.