Skip to main content
Galactic is the networking software underneath gVPC. It builds private networks on Datum’s IPv6 backbone with segment routing (SRv6), and it keeps each network separate from every other one. Galactic is open source under the AGPL-3.0 license, at github.com/datum-cloud/galactic. You don’t install or run Galactic to use gVPC. Datum runs it for you. This page explains what happens underneath, so you can understand how your traffic moves and what the network can grow into.

​
The Galactic stack

Galactic has four layers. Kubernetes resources describe every layer, so the whole network is configured the same way the rest of Datum is.
Four stacked layers. Attach: pods, VMs, ingress addresses and internet egress. Control: BGP EVPN routes through route reflectors. Datapath: VRF isolation and eBPF programs in each node's kernel. Underlay: the eBGP transit network. A side panel lists the Kubernetes resources that configure them.

Galactic's four layers, and the Kubernetes resources that configure them

​
How a connection works

When something attaches to a network, Galactic gives it an address and tells every other node in that network how to reach it. The following figure follows one attachment from start to finish.
Two compute nodes, Node A and Node B, connected through a route reflector and an SRv6 underlay. Control-plane arrows go from the attach chain to the router to the route reflector to Node B. A dashed data path goes from the pod on Node B through the underlay to the pod on Node A.

Steps 1 to 5 publish a new attachment's address. Steps 6 to 8 deliver a packet to it from another node.

  1. The attach plugins create the node’s side of the connection. They place it in the network’s own routing table (a VRF) and register it with the node’s eBPF datapath.
  2. They record the new address as a BGPAdvertisement resource.
  3. The node’s router turns that resource into a BGP EVPN route. The route carries the node’s SRv6 address for this network.
  4. Route reflectors pass the route to every node. Only nodes that host the same network import it.
  5. Those nodes install the route in their copy of the network’s routing table.
  6. When a workload sends a packet, its node wraps the packet in an outer IPv6 header addressed to the destination node’s SRv6 address.
  7. The backbone forwards the wrapped packet like any other IPv6 packet. It never sees your network’s addresses.
  8. The destination node’s eBPF program unwraps the packet and hands it to the right network’s routing table, which delivers it.
The figure shows Galactic in general, so it uses both IPv4 and IPv6 addresses. gVPC networks use IPv6 only. See Addressing.

​
The address carries the instructions

Each SRv6 address that Galactic uses tells the network where the packet goes, what to do when it gets there, and which private network it belongs to.
A bar divided into fields: uSID Block 48 bits, Node-ID 16 bits, Function 4 bits, Argument 12 bits, Slot 16 bits and Padding 32 bits.

The 128-bit layout of a Galactic SRv6 address

  • Block and Node-ID identify the destination node. The backbone routes on this 64-bit prefix only.
  • Function says what the node does with the packet, such as unwrapping it into a private network.
  • Argument identifies which private network on that node receives the packet.
Because isolation is encoded in the address and enforced in the kernel, two networks can’t reach each other even when they share a node. Isolation comes from the topology, not from a shared VLAN with rules on top.

​
How Datum runs Galactic as a service

gVPC is Galactic run as a managed service. You work with a small set of resources, such as a network and the workloads attached to it. Datum operates everything else. What Datum runs for you:
  • The backbone. Datum runs the underlay routers in every location, the routes between locations, and the configuration of each router. Configuration changes roll out through the API in stages, so a bad change can be stopped before it reaches the whole fleet.
  • The routing control plane. Every node runs a Galactic router. Datum runs the route reflectors that connect them, so a new attachment becomes reachable from every location without anyone touching a router.
  • The edges. Datum runs the edge nodes that bring public traffic into a network, through the Application Load Balancer and anycast ingress addresses. They also take traffic out to the internet.
  • Identity and addressing. Datum allocates network identities and address space centrally, so two networks never collide. This is why you don’t plan subnets.
  • Visibility. Datum monitors every BGP session, route and datapath counter. Its operators can ask any router for its view of the network, and can run ping and traceroute from inside the backbone.
What you do:
  • Create a network.
  • Attach things to it.
The rest of this page describes what “attach things to it” can grow to include.

​
One network, many attachments

This section describes where gVPC is headed. Only the attachments marked Available below work today. Plans can change, and this isn’t a commitment to deliver any feature or to meet any timeline.
In Galactic, everything that joins a network does it the same way. It gets a place in the network’s routing table and an address, and it announces that address with a BGPAdvertisement. A container, a virtual machine, a public ingress address and an internet egress point already join this way. The rest of the network doesn’t need to know what kind of thing an attachment is. So adding a new kind of connection doesn’t need a new network. It needs a new way to attach. That makes a gVPC network work like a virtual meet-me room: a single private place where all your connections meet, whatever they are and wherever they come from.

​
Words we use for this

These terms describe gVPC in plain language. Each one corresponds to something the platform does.

​
What’s next

gVPC

Create a network and attach workloads to it.

Traffic and connecting

Learn which traffic a network carries today.

Networking roadmap

Review what gVPC can’t do yet and what’s planned.

Galactic on GitHub

Read the source code and architecture documents.
Last modified on October 23, 2026