Private Networks

Beta. Private networks are rolling out behind a feature flag. If you don't yet see "Private Networks" in your dashboard sidebar, email support and we'll enable it for your team.

Private networks are isolated, RFC1918 layer-2 segments that connect your VPS instances over a private link. Traffic between attached VPS instances stays inside our infrastructure — it never traverses the public internet, doesn't count against your VPS bandwidth allowance, and isn't reachable from the outside.

Each network you create gets:

• Its own CIDR block (you pick) from any RFC1918 range — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
• A dedicated bridge on every VPS host you attach a VM to, glued together with VXLAN so VMs on different physical hosts behave as if they were on one switched LAN.
• Per-attachment MAC and IP, attached as an extra NIC inside the guest with no reboot required.

When to use a private network

Create a network

1. Open Networking → Private Networks in the sidebar and click New private network.
2. Pick a name (lowercase letters, digits, and hyphens; must start and end with an alphanumeric character).
3. Choose an IP range in CIDR notation. Rules:
   • RFC1918 only: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
   • Prefix between /16 and /24.
   • The first 10 addresses of the range are reserved for the platform (e.g. 10.0.0.0–10.0.0.9 in a 10.0.0.0/24 network); your VPS instances start at .10.
   • The range cannot overlap with another private network you already own.
4. (Optional) Add a description so your teammates know what the network is for.

The network goes active within a few seconds of creation. Behind the scenes, the platform allocates a VXLAN ID, writes the bridge configuration to every VPS host, and registers a Multus network attachment in your tenant namespace.

Attach a VPS

From the network's detail page (or directly from the index using Attach VPS on each row), pick the VPS you want to attach.

• Auto-allocated IP — leave the Requested IP field blank and the platform picks the next available address from the network's range.
• Specific IP — type one in (e.g. 10.0.0.42). It must be inside the network's CIDR, outside the reserved first-10 block, and not already taken.

The new interface comes up live — no reboot. Within a few seconds:

• Inside the guest, you see a new NIC with the assigned IP and a deterministic MAC of the form 02:00:01:xx:xx:xx.
• Cloud-init has dropped a netplan file at /etc/netplan/60-private-<vni>.yaml so the address survives reboots.
• The MTU on the new interface is 1450 to leave room for VXLAN encapsulation.

The attachment status is reflected in the UI:

Verify connectivity

After attaching two VPS instances, ping between them using the private IPs:

# On 10.0.0.10
ping -c 4 10.0.0.11
ip -br addr show
ip route get 10.0.0.11

You should see sub-millisecond RTT between VPS instances on the same physical host, and a few hundred microseconds across hosts (VXLAN-encapsulated over our internal datacenter network).

The private IPs are not reachable from outside the network — a public-internet host pinging 10.0.0.10 will time out. Only VPS instances attached to the same private network can reach each other.

Detach

From the network's detail page, click the trash icon on an attachment row and confirm. The platform:

1. Pushes the netplan removal to the running guest (when the agent is reachable) so the IP comes off live.
2. Updates the VM manifest to drop the NIC.
3. Frees the IP back to the pool.

If the guest agent isn't reachable at the moment of detach, the netplan file lingers until the next reboot — but the host stops forwarding to the IP immediately, so peers can't reach it regardless.

Delete a network

A network can only be deleted when no VPS instances are still attached to it. Detach all VPSes first, then click Delete network on the network's detail page. The bridge and VXLAN tunnel are removed from every host within the next reconcile cycle.

Limits and notes

• MTU is 1450 on the in-guest interface. If you tunnel further (WireGuard, VPN), keep the inner MTU below this.
• No DHCP — IPs are assigned at attach time and configured statically via netplan. There is no DHCP server on the network.
• No NAT, no gateway — a private network is L2-flat. There is no router providing internet access via the private IP. VPS instances still use their public NIC for internet traffic; the private network is purely for east-west traffic.
• Free — east-west traffic on a private network does not count against your VPS bandwidth allowance.

Security model

A few things to know before treating a private network as a security boundary.

Tenant isolation

• Per-team isolation is enforced at the platform layer. Networks are scoped to your team, allocated a distinct VXLAN ID, and the host kernel decapsulates packets onto your bridge only when the VXLAN ID matches yours.
• Host-level firewall restricts which underlay IPs can send VXLAN traffic to the platform — the kernel only accepts UDP/4789 from VPS hosts in our internal whitelist. External attempts to inject crafted VXLAN frames are logged and dropped.
• Two teams using the same CIDR (e.g. both 10.0.0.0/24) are completely isolated — they live on different bridges with different VXLAN IDs.

Inside one network

A private network is a layer-2 LAN segment between attached VPS instances. That means:

• Anti-spoofing is enforced by the platform. Each VM is pinned to its assigned (MAC, IP) pair via host-level ebtables rules. A VPS attempting to ARP-spoof or IP-spoof another VPS on the same network has those frames dropped on the bridge before they reach any peer.
• We do not inspect or filter your application-layer traffic between VMs that use their legitimate IPs.
• If you run untrusted workloads (multiple users / multiple apps with different trust levels), still prefer separate private networks per trust boundary as defense in depth — anti-spoofing prevents impersonation, not application-level abuse from a legitimate VM.
• The per-VPS firewall applies to private-network traffic, but in "explicit-allow" mode. Any allow rule you define (e.g. allow TCP/22 from anywhere) is matched on the public IP and on every private-network IP attached to the VPS. However, unlike on the public NIC, traffic on the private network is not denied by default — anything not explicitly allowed simply passes through. This means:
  • Adding allow TCP/22 from anywhere opens SSH on both public and private IPs.
  • Service-to-service ports between attached VPS instances (e.g. an internal API on TCP/9000) keep working without a matching rule.
  • To restrict which VPSes can reach which ports on the private network, add explicit deny rules with a private-network source — those are honored verbatim.
• For wire-tight isolation between workloads on the same private network, complement the per-VPS firewall with an in-guest firewall (ufw / firewalld / iptables).

Encryption

VXLAN traffic between VPS hosts is not encrypted on the wire. The underlay traverses our internal datacenter network, which is not exposed publicly, but if you have a regulatory requirement for wire-level confidentiality (HIPAA, certain GDPR data classes, internal compliance), you should terminate TLS or WireGuard between your VPSes on top of the private network. The private network gives you a clean addressing plane to do that on.

Audit

Create / delete / attach / detach actions are written to your team's audit log. You can review them from your account settings.

Related Documentation

• Networking Overview
• Firewalls
• Network Peering