Networking

Kvindo™ Cloud Docs

Concepts

Language

A basic private network via the Python SDK: a floating IP attached to a VPC for outbound NAT (no NAT gateway needed) plus a subnet. Each create_or_update() returns the new resource's id, which the next call references — the SDK takes ids, not names, and hostingProviderId is itself a ULID looked up by name.

Run the Getting started snippet first (it builds client):

Peering

Creates two VPCs, each with its own subnet, and peers them via a VPC Peering with a Peering Peer gateway on each side — both created and confirmed Stable directly below. A Route Table in each direction lets a whole subnet — not just its own gateway VM — reach the other side, so any VM in subnet "a" can talk to any VM in subnet "b" and back; the routes themselves need each peer's private IP, only known once it reconciles, so they're added in the follow-up step below. Reuses client from Getting started, same as above.

Peers and routes

Both peers are already Stable — read back their private IPs and route each subnet at the other's gateway:

External peers

Another self-contained example — its own folder/VPC/subnet with one internal Peering Peer, plus a VM standing in for whatever is on the other side, connected via an External Peer instead of a second Peering Peer. Kvindo reaches an External Peer over SSH directly, so it needs no floating IP of its own on the Kvindo side — only sshIpV4/sshUser/sshPrivateKeyId/ privateIpV4 to reach whatever's actually on the other end. Paste your own SSH key pair in place of the SshKey/SshPrivateKey placeholders below and replace the VM with your real external network to use this for real. The Peering Peer and a Route Table are both created and waited on directly here, same as Peering above — a Route Table Route lets the rest of the own subnet, not just the peer's own gateway VM, reach whatever's advertised on the other side too, added in the "Peer and connect" step below once the target VM's real IPs are known.

Peer and connect

The internal peer is already Stable — read its status back, wait for the target VM's public/private IPs to reconcile, then apply the route before creating the External Peer itself.

As a single transaction

Submit the whole stack at once so it's created atomically — all resources succeed together or none do, with quota checked up front. Cross-references use client-generated ULIDs assigned before the PUT:

Resource docs