Colima Bridged Networking Setup on macOS

April 21, 2026 ยท View on GitHub

This guide sets up Colima with bridged networking so the VM gets a real IP on your current network. For DVRTC, treat the Colima VM as the effective Linux host: containers using --network host share the VM network namespace, not the macOS host's network identity. Direct Docker Desktop deployment on macOS is not the supported path for DVRTC because the stack depends on host networking semantics.

Prerequisites

  • macOS with Homebrew installed
  • Docker CLI and Compose plugin installed (brew install docker docker-compose)
  • Colima installed (brew install colima)

Step 1: Configure Lima vmnet using the official docs

Follow Lima's official vmnet setup guide:

For DVRTC, use Lima's managed vmnet flow for bridged networking. That setup includes:

  • installing socket_vmnet in a root-owned, non-symlink path
  • configuring ~/.lima/_config/networks.yaml
  • installing the Lima sudoers entry
  • creating /private/var/run/lima

Do not use a separate brew services socket_vmnet launchd service for this workflow. Lima starts the managed daemon automatically when a VM using that network starts.

Step 2: Start Colima with bridged networking

If you have an existing Colima instance, delete it first (network mode can't be changed after creation):

colima stop
colima delete --force

Official Colima guidance keeps shared networking as the default and recommended mode. DVRTC is a repo-specific exception: use bridged here because the stack needs a VM address that is reachable as a real host on your LAN, and components such as Kamailio, RTPEngine, and coturn need explicit addresses to advertise. Colima may also mirror forwarded ports onto macOS, but that host-side forwarding is a convenience layer, not the canonical service identity for the stack.

Start Colima with bridged networking and enough resources for a full DVRTC stack:

colima start --network-address --network-mode bridged --vm-type vz --cpu 8 --memory 16 --disk 200

The default 2 CPU / 2 GB Colima allocation is too small for the full DVRTC stack. In practice, --cpu 8 --memory 16 --disk 200 has been a more reliable DVRTC baseline for local builds, packet capture, and the full testing workflow. These values are not general Colima requirements; they are a tested starting point for this repository.

The command above does not pass --mount-type virtiofs because current Colima releases already default VZ instances to virtiofs.

On Apple Silicon, include --vz-rosetta:

colima start --network-address --network-mode bridged --vm-type vz --cpu 8 --memory 16 --disk 200 --vz-rosetta

Rosetta support is required for this setup to work reliably with DVRTC's linux/amd64 image and build requirements on Apple Silicon.

If you prefer persistent config instead of passing CLI flags each time, run colima start --edit and set the same values in the profile. On Apple Silicon, make sure rosetta: true is set in ~/.colima/default/colima.yaml before starting the VM.

Changing resources on an existing instance

If you need to change the resource settings later, stop Colima and start it again with the updated values:

colima stop
colima start --cpu 8 --memory 16 --disk 200

Verify the current allocation:

colima list

Step 3: Set the bridged IPs

The setup_networking.sh script auto-detects the Colima VM's bridged IPv4 and, when the VM has a usable global or ULA address, its IPv6 too:

./scripts/setup_networking.sh

To verify the IPs manually:

colima ssh -- ip addr show
colima ssh -- ip -6 addr show scope global

Look for the bridged interface that Colima created. It should have an IPv4 address on your LAN subnet (for example 192.168.x.x). If your network provides IPv6, it should also have a usable global or ULA IPv6 address. If no usable IPv6 address is present, leave PUBLIC_IPV6 unset and DVRTC stays IPv4-only.

Optional: Add custom CA certificate

If you have a private registry with a custom CA:

cat /path/to/your-ca.crt | colima ssh -- sudo tee /usr/local/share/ca-certificates/your-ca.crt > /dev/null
colima ssh -- sudo update-ca-certificates

Usage

Once Colima is up with bridged networking, use the normal DVRTC setup flow from your host shell:

./scripts/setup_networking.sh
./scripts/generate_passwords.sh
./scripts/init-selfsigned.sh
./scripts/validate_env.sh
./scripts/compose.sh --scenario pbx1 up -d
./scripts/compose.sh --scenario pbx1 ps

For host-side access checks from macOS, prefer the bridged PUBLIC_IPV4 written to .env:

. ./.env
curl "http://${PUBLIC_IPV4}/"

Current Colima releases may also make the stack reachable on macOS 127.0.0.1 or the macOS host IP via automatic port forwarding. Treat that as a host-side convenience, not the address DVRTC components should advertise or the main mental model for the deployment.

If you specifically want to test loopback inside the Colima VM's own network namespace, use:

colima ssh -- curl http://127.0.0.1/

If you rebuild images locally on Apple Silicon, follow development.md and keep the linux/amd64 build requirement in mind.

Notes

  • The bridged IP is assigned via DHCP, so it may change across restarts
  • IPv6 availability depends on your LAN/router. Bridged Colima does not invent IPv6; it can only use an address actually assigned to the VM
  • Bridged means the VM is directly on your current network; if that network is private/NAT'd, inbound access from the public internet still requires port forwarding or a public IP
  • The CA certificate and other VM customizations won't survive colima delete - you'll need to re-add them
  • Consider setting a static DHCP lease on your router for a consistent IP