Network devices (load balancers, routers, switches, gateways)

Put a load balancer in front of an application, connect two private networks with a router, join applications on a switch, give them one outgoing address with a NAT gateway, or link an office with a site-to-site VPN.

What they are

Your applications, databases and services run on private networks: VXLAN overlays that nothing outside the cluster can see, where services find each other by name. Network devices are small pieces of network equipment ISOGrid runs for you on those networks, beside your applications. Your networks stay exactly as they are; a device adds something on top.

Device What it does
Load balancer Shares traffic between every copy of your applications, checks each copy's health, can keep a visitor on the same copy, and can be published on a public port.
Router Connects two of your networks, one service at a time: only the routes you add go through.
Switch A shared segment: the applications you plug in talk to each other directly, whatever network they live on.
NAT gateway Your applications' outgoing traffic leaves from one fixed address, to the destinations you allow and nowhere else.
Site-to-site VPN Connects a network to your office or data centre over WireGuard, so your applications reach your own servers by name.

Open Networks → Devices in the console, or use isogrid networks devices from the command line. Every change is applied in a few seconds; the status reads Active when it is done. A device can only use networks your organization owns, in one region.

Load balancer

A load balancer listens on a port of a network under its own name and forwards to the applications behind it:

isogrid networks devices create lb web --network app-tier --backend acme-api:8000 --port 80
curl http://web/          # from any application on app-tier
  • Every copy is checked separately. A backend is an application's internal name (shown on its page). The balancer looks up each running copy of it and checks each one. A copy that fails stops receiving traffic until it recovers. Swarm's own balancing cannot do this, because it hides the copies behind a single address.
  • How traffic is shared: in turn, to the least busy copy, or the same visitor to the same copy by address.
  • HTTP or TCP. An HTTP listener can check a path (/health, healthy on 2xx and 3xx) and keep each visitor on the same copy with a cookie. A TCP listener (a database, a message broker) checks that the copy accepts connections.
  • Public. Tick Also reachable from the internet and the listener is published on a public port of the region (shown on the device's page). The balancer then runs as one copy on the region's entry machine. Otherwise it runs two copies, so an update never interrupts it.

Refresh status shows each backend copy as the balancer sees it: UP, DOWN, or still being checked.

Router

A router joins two or more of your networks and carries only the routes you add. Each route gives one service on the destination network a name on the source network:

route  db:  from front  ->  to back
            billing-db:5432  ->  acme-postgres:5432 (TCP)

An application on front connects to billing-db:5432. Nothing else on back is reachable from front, and nothing on front from back, unless another route says so. A route only accepts connections from its source network. You can narrow it further to some addresses (allowed_sources, in the JSON editor). A route can listen on a different port from the service's (target_port). Routes carry TCP or UDP.

Switch

A switch is a segment of its own: plug applications into it and they reach each other directly, by their internal name or the extra name you give each port, even when they live on different networks. Plugging an application in restarts it once, copy by copy. It then stays on the segment through every later deploy. An application that is not deployed yet joins at its first deploy.

NAT gateway

Many banks, payment providers and government APIs only accept calls from addresses they know. A NAT gateway gives your applications one: outgoing traffic sent through it leaves from the address of one machine of the region, shown on the device's page as Outgoing address.

Send an application's traffic through it by setting, on that application:

HTTP_PROXY=http://egress:3128
HTTPS_PROXY=http://egress:3128
NO_PROXY=localhost,127.0.0.1

(the console shows the exact values for your gateway). The allowed destinations are domains (api.bank.dz, or .bank.dz for the domain and everything under it) and address blocks. Leave the list empty to allow any public destination. Private addresses, the cluster's own networks and cloud metadata addresses are always refused, whatever the list says. Allowed ports are 80 and 443 unless you change them.

Site-to-site VPN

Availability: site-to-site VPN is currently available only to businesses, for their on-premise servers.

A site-to-site gateway connects a private network to the LAN behind your office or data-centre router, over WireGuard. You describe:

  • Networks at the site: the address blocks behind your router, for example 192.168.10.0/24.
  • Servers your applications reach: each one a name, an address at the site and its ports. With erp=192.168.10.20:443, your applications connect to erp:443 and reach that server.
  • Your router's public address (optional). Without it your router connects to ISOGrid; with it, either side can start the tunnel.
  • Whether the site may also reach the services on the network.

Then download the site configuration and import it on your router (MikroTik, OPNsense, pfSense, Ubiquiti, OpenWrt or any WireGuard device). It holds the router's private key. One step stays on your side: route the tunnel's addresses (shown on the device's page) to the router on your LAN, so your servers can answer. Rotate keys replaces both ends' keys; the router imports its configuration again afterwards.

Check that it works

ISOGrid has no shell into your containers, so test a device from a small probe application: deploy a public image (Deploy an app → From another registry → Public image) on the network to test from, tick Runs without a port, set its Command under Rollout & placement → Container, and read its Logs. Delete it when you are done.

Device Probe image Command Working
Load balancer busybox:1.37 sh -c "while true; do wget -S -q -O /dev/null http://web/ 2>&1 | head -1; sleep 5; done" HTTP/1.1 200 OK
Router busybox:1.37 sh -c "while true; do nc -zv -w 3 billing-db 5432; sleep 10; done" billing-db (10.0.67.2:5432) open
NAT gateway curlimages/curl:8.11.1 + HTTPS_PROXY sh -c "while true; do curl -sS https://api.ipify.org; echo; sleep 30; done" the Outgoing address
Site-to-site busybox:1.37 sh -c "while true; do nc -zv -w 3 erp 443; sleep 10; done" erp (…:443) open
  • Refresh status on the device page shows each load balancer backend copy as UP or DOWN, and a site-to-site tunnel's Last handshake.
  • A public load balancer can also be tested from your own computer: curl -i http://<public endpoint>/.
  • Through a router, open only proves the router answered. Make a real request too (pg_isready -h billing-db -p 5432 from postgres:17-alpine, or wget on a health page), and check from the destination network that the route's name does not resolve (nc: bad address).
  • Through a NAT gateway, a destination that is not allowed answers curl: (56) CONNECT tunnel failed, response 403.

The ISOGrid Academy courses Load balancers, Routers and switches and NAT gateways and site-to-site VPN walk through each test.

Pricing

Each kind of device is priced per region, like everything else; a region that has not priced a kind does not offer it yet.