When you deploy across the Upsun grid with our distributed infrastructure - capable of running tens of thousands of containers simultaneously - networking becomes one of your biggest challenges. The grid consists of three key components: orchestration machines that manage deployments, compute nodes where your application containers run, and a regional storage cluster that houses all project data including files and databases. At this scale, traditional networking approaches start to break down. Containers are created and destroyed constantly, often moving between hosts for efficiency or availability. Centralized systems quickly become bottlenecks or single points of failure, increasing the risk of unavoidable downtime. To solve this, we built a stateless mesh networking system that embeds routing information directly into IP addresses, eliminating the need for databases while supporting up to 8,192 containers per VM across the entire grid.Documentation Index
Fetch the complete documentation index at: https://developer.upsun.com/llms.txt
Use this file to discover all available pages before exploring further.
The high-density challenge
Upsun’s infrastructure operates at high density by design. Your preview environments, production deployments, and service containers all share the same network space for maximum efficiency. This creates a complex networking scenario:- Containers constantly appear and disappear as you push code
- Preview environments are created and destroyed dynamically
- Containers move between VMs for capacity planning and load balancing
- Maintenance rollovers relocate workloads during infrastructure upgrades
- Incident response triggers automatic failover to healthy nodes
- Service discovery must work instantly across the entire grid
Why we built our own solution
Most mesh networking solutions rely on external databases or control planes to track container locations. This approach introduces latency, complexity, and potential failure points. We asked ourselves: what if we could make routing completely stateless? The answer came from an unexpected source: IPv6’s concept of IPv4-mapped addresses, where IPv4 addresses get embedded within IPv6 space. We realized we could embed VM addresses directly into container IP addresses.The magic of address mapping
Here’s how our stateless routing works. Consider these network ranges:- Physical network:
192.168.0.0/16 - Overlay network:
10.0.0.0/8
- The VM’s physical IP is 192.168.16.32 (extracted from the overlay address)
- This is the 90th container on that VM (the first IP of the subnet is for the VM itself)
The technical implementation
When a packet needs routing between VMs, our custom ARP daemon:- Extracts the target VM’s IP from the destination overlay address
- Establishes a GRE tunnel to that VM if one doesn’t exist
- Forwards the encapsulated packet directly
Scaling beyond standard private networks
Initially, we considered using the standard10.0.0.0/8 private network
for our overlay. But this only provides 256 addresses per
VM—insufficient for high-density deployments.
We found a creative solution in 240.0.0.0/4, the “reserved for future
use” IPv4 space that became available when IPv6 development made it
redundant. This gives us:
- 4 bits for subnet identification
- 16 bits for physical IP mapping
- 12 bits for container addresses (8,192 per VM)
Real-world benefits
This architecture delivers concrete advantages for your applications:- Instant service discovery: new containers become routable immediately without propagation delays
- Zero network bottlenecks: direct VM-to-VM communication eliminates central routing points
- Predictable performance: network latency remains consistent regardless of infrastructure scale