Kvindo™ Cloud Docs
A basic private network: a folder to hold everything, a VPC with a floating IP attached for outbound NAT, and a subnet. Attaching a floating IP to the VPC (natFloatingIpId) gives every resource in it outbound internet access — no separate NAT gateway is needed.
Save this as stack.yaml:
Apply it — the order of documents in the file does not matter: kc apply sorts them by their dependencies, and resources reference each other by name:
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 directly in this one
--wait apply. 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.
Save this as stack.yaml:
Both peers are already Stable — read back their private IPs and apply both routes. Run this
whole block as a shell script as-is — no need to copy values by hand. --wait can
still report a peer as applied a moment before its status is fully populated — if either IP
below comes back empty, wait a few seconds and re-run this block.
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 directly in this one --wait apply, 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.
Save this as stack.yaml:
The internal peer is already Stable — read back its private IP alongside the target VM's
public/private IPs (only known once it reconciles), then apply the route and create the
External Peer itself in one --wait apply — again, runnable as one shell script
with no manual editing.
Resource docs
More in this section