Skip to main content

Virtual Private Cloud (VPC)

Introduction​

A Virtual Private Cloud (VPC) is your own private network for traffic between your virtual machines. VMs in the same VPC reach each other over a private, internal subnet — sealed from every other customer by default, so no one else can see or route to your traffic.

Every VM still gets its own public IP for the internet and SSH; the VPC is purely the private side. You don't trade away internet access to use a VPC — you add a private network on top of it.

Use a VPC when you want to:

  • Run a multi-node setup (training, inference, a database + app server) where the nodes talk to each other over a stable private address.
  • Keep service-to-service traffic off the public internet.
  • Give your VMs private IPs that don't change when you pause and resume them.
Availability

VPCs are available in the India-01 region. Support for more regions is rolling out — if your region doesn't show a VPC option yet, it isn't enabled there.

The dual-NIC model​

Every VM in a VPC-enabled region has two network interfaces:

InterfaceAddressPurpose
eth0Public IPInternet access and SSH. Always present — there is no toggle.
eth1Private VPC IPEast-west traffic between your VMs on the private overlay network.

Internet always comes from the public NIC (eth0), so a VPC never needs an "internet-enabled" setting, a NAT gateway, or a floating IP. It is simply a private network.

Key concepts​

  • Default VPC — every account in a VPC-enabled region gets a default VPC automatically. If you launch a VM without picking a VPC, it joins the default one. The default VPC is permanent and can't be deleted.
  • CIDR / private IP range — the block of private addresses your VPC hands out (for example 10.20.0.0/20). It must be a private (RFC1918) range between /16 and /28.
  • Gateway — the first address in your range (e.g. 10.20.0.1) is reserved as the network gateway.
  • Stable private IPs — a VM keeps the same private IP across pause and resume. The public IP, by contrast, can change on resume, so prefer private IPs for anything your VMs reference internally.
  • Tenant isolation — each VPC is its own sealed network. Two different customers can even use the same CIDR with zero risk of collision; the networks never see each other.

Creating a VPC​

You manage VPCs from the Virtual Private Cloud page on the dashboard: jarvislabs.ai/dashboard/vpc.

  1. Click Create VPC.
  2. Give it a name (any short label, e.g. training-cluster).
  3. Pick the region (India-01 today; locked when it's the only VPC region).
  4. Choose the private IP range:
    • Generate for me (recommended) — Jarvislabs picks a free, non-overlapping private range for you.
    • Configure my own — set the address prefix (e.g. 10.50.0.0) and the network size (/16 – /28). A summary shows the gateway, the address range, and how many usable hosts you'll get.
  5. Click Create VPC.

The new range can't overlap your other VPCs in the same region or any reserved infrastructure range — if it does, you'll get an inline error explaining the conflict.

Launching a VM into a VPC​

A VM joins a VPC when you launch it. On the VM launch page, in a VPC-enabled region, pick the VPC you want from the network/VPC selector. If you don't choose one, the VM joins your default VPC.

That's the only networking choice you need to make — the public IP is always included, so there's no "assign public IP" option to toggle.

Once the VM is running it has both addresses:

  • Public IP (eth0) — shown on the VM card with the SSH command, e.g. ssh -o StrictHostKeyChecking=no ubuntu@<public_ip>.
  • Private IP (eth1) — the VPC address other VMs in the same VPC use to reach it.

See the VM guide for the full launch and SSH walkthrough.

Connecting your VMs over the VPC​

Within a VPC, address your VMs by their private IP. Because private IPs are stable across pause/resume, they're safe to bake into config files, cluster manifests, or connection strings.

For example, from VM A you can reach a service on VM B directly on the private address:

# From VM A — reach VM B's service over the private VPC network
curl http://10.20.0.3:8000/health
ssh ubuntu@10.20.0.3

You can see every private IP currently in use on the VPC card: expand VMs on this network to view the list of members and their private addresses.

Moving a VM to another VPC​

There's no live attach/detach. To move a VM into a different VPC:

  1. Pause the VM.
  2. Edit the paused VM and select the target VPC.
  3. Resume the VM.

On resume the VM comes up in the new VPC with a new private IP, and the guest is reconfigured automatically — no in-VM commands needed. The public NIC (eth0) is unaffected. A VM always belongs to exactly one VPC at a time.

Deleting a VPC​

You can delete any VPC except the default one, and only once it's empty:

  • If the VPC still has VMs on it, deletion is blocked. Move those VMs to another VPC (see above) or destroy them first.
  • The default VPC has no delete option — it's permanent.

Deleting a VPC permanently removes its private overlay network and cannot be undone.

FAQ​

Do I lose internet access if I use a VPC? No. Every VM always has a public IP on eth0 for internet and SSH. The VPC only adds a private network.

Will my VM's private IP change? No — the private IP is stable across pause and resume. (The public IP can change on resume, so don't rely on it as a fixed identifier.)

Can two VPCs use the same IP range? Yes. Each VPC is fully isolated, so even identical CIDRs across different customers — or your own VPCs in different regions — never collide.

Why don't I see a VPC option? VPCs are only available in VPC-enabled regions (India-01 today). In other regions, VMs run on the standard flat network without a VPC.