WireGuard gateway

How it works

Every VPC has a WireGuard gateway. A client authenticates with its WireGuard key and receives its own address from your private network range (for example, 10.50.0.200/32).

The tunnel exposes all resources of the VPC:

• virtual machines and containers;
• internal DNS resolution;
• services that are not published to the internet.

VM ports stay closed to the outside: inbound connections are only possible through the WireGuard gateway, the SSH gateway, or the HTTPS gateway.

Scenario: database access from your laptop

1. Deploy PostgreSQL on a VM inside the production-vpc (10.50.0.0/16). The machine gets an internal address, for example 10.50.0.21.
2. Bring up the tunnel on your work machine:

$ wg-quick up microsrv-vpc
[#] ip link add microsrv-vpc type wireguard
[#] ip address add 10.50.0.200/32 dev microsrv-vpc
[#] ip route add 10.50.0.0/16 dev microsrv-vpc

3. Reach the database over the private address:

$ psql -h 10.50.0.21 -U app
psql (16.3, server 16.3)
Type "help" for help.

app=> SELECT inet_server_addr();
 inet_server_addr
------------------
 10.50.0.21
(1 row)

The database is unreachable from the internet, yet your laptop can query it as if it were attached to the office LAN.

Scenario: hybrid Kubernetes (multicloud)

microsrv nodes can join existing infrastructure as WireGuard gateway clients. With Kilo, microsrv nodes become members of your Kubernetes cluster and appear in your cloud with private addresses — no public IPs and no hand-configured VPN.

Reverse reachability (microsrv nodes → pods and services of your cluster) depends on address translation in your network layer: if it performs SNAT/DNAT over the tunnel (Kilo does this automatically), traffic flows in both directions.