Vagrant Private Networks: Static IPs That Actually Work Across Providers

The Problem: Port Forwarding Fatigue

You spin up a Vagrant box, map port 8080 to 80, then 3000 to 3001, then realize your microservice needs to call another service on the same host. Suddenly you're managing a spreadsheet of port mappings instead of writing code. Vagrant's private_network gives each VM a real IP on a host-only subnet so services talk directly—no port gymnastics required.

How Private Network Differs from NAT and Bridged

NAT (the default) hides the guest behind the host's IP with port forwarding. Bridged puts the guest on your physical LAN, which works great until you move from office Wi-Fi to a coffee shop hotspot and the bridge interface disappears. Private network creates a virtual adapter visible only to the host and other VMs on the same subnet. The IP stays stable regardless of where your laptop connects.

Minimal Working Configuration

Add one line to your Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"
  config.vm.network "private_network", ip: "192.168.100.10"
end

Run vagrant up, then vagrant ssh -c "ip addr show eth1". You'll see 192.168.100.10/24 on the second interface (eth1 on most Ubuntu boxes). Your host can now curl http://192.168.100.10 directly.

Provider-Specific Gotchas

VirtualBox (default)

Creates a host-only adapter named vboxnet0 automatically. No extra flags needed.

VMware Fusion/Workstation

Requires a named bridge interface on macOS:

config.vm.network "private_network", ip: "192.168.100.10",
  bridge: "en0: Wi-Fi"

Omit bridge and vagrant up hangs waiting for a prompt you can't see in headless CI.

Hyper-V (Windows)

Uses an internal virtual switch. Create it once in PowerShell:

New-VMSwitch -Name "VagrantPrivate" -SwitchType Internal

Then reference it:

config.vm.network "private_network", ip: "192.168.100.10",
  bridge: "VagrantPrivate"

Speed Up Boot with auto_config: false

By default Vagrant rewires the guest's network scripts on every boot. For boxes with many interfaces or large cloud-init runs, that adds 10-30 seconds. Disable guest-side configuration and handle IP assignment yourself (via cloud-init, Netplan, or a shell provisioner):

config.vm.network "private_network", ip: "192.168.100.10",
  auto_config: false

You must then ensure the guest brings up the interface with the correct IP. On Ubuntu 22.04+ with Netplan:

config.vm.provision "shell", inline: <<-SHELL
  cat > /etc/netplan/99-vagrant.yaml <<EOF
  network:
    version: 2
    ethernets:
      eth1:
        dhcp4: false
        addresses: [192.168.100.10/24]
  EOF
  netplan apply
SHELL

Trade-off: you own the guest network config. If the interface name changes (eth1 vs ens8), your provisioner breaks.

IP Conflict Avoidance

Don't pick 192.168.1.x or 10.0.0.x—those collide with home routers and corporate VPNs. Use a dedicated range like 192.168.100.0/24 or 172.28.0.0/16. Document the range in your team's Vagrantfile template so two developers don't assign the same static IP to different projects.

Verification Checklist

1. vagrant up completes without "Waiting for network" timeout.
2. vagrant ssh -c "ip -br addr" shows the expected IP on a non-loopback interface.
3. From host: ping -c 2 192.168.100.10 succeeds.
4. From guest: curl -I http://192.168.100.1 (host IP on the same subnet) returns HTTP headers.

When to Skip Private Network

• Single-service apps where one forwarded port is simpler.
• Environments where you cannot create host-only adapters (locked-down corporate laptops).
• Ephemeral CI runners that tear down after each job—DHCP on a shared bridge is faster to provision.

Next Step

Pick a subnet, add the private_network line to your project's Vagrantfile, and run the verification checklist. If you support multiple providers, wrap the provider-specific bridge attribute in a provider block so the same file works everywhere.