Docker – namespace sharing

Create a service mesh directly with VeilNet using Docker network namespace sharing—no additional service mesh solution required.

You can create a service mesh directly with VeilNet—without adding another service mesh solution (e.g. Istio or Linkerd). This guide uses Docker network namespace sharing: run one veilnet-conflux container per host and run your application containers in the same network namespace as that host's Conflux using network_mode: "container:veilnet-conflux". For single-container setup and environment variable reference, see the main Docker guide.

Overview

Run one veilnet-conflux container per host.
Run your application containers in the same network namespace as that host's veilnet-conflux.
Reach services on Host A from Host B using Host A's VeilNet IP and the service port.
Ensure both hosts share at least one taint (otherwise they may not be able to communicate).

Note TUN device created by VeilNet Conflux is a virtual network interface that exists within the container namespace. It is not visible on the host network, unless you enable host network mode.

Host A (example: web frontend)

docker-compose.yml on Host A:

services:
  veilnet-conflux:
    container_name: veilnet-conflux
    image: veilnet/conflux:beta
    restart: unless-stopped
    env_file: [.env]
    cap_add: [NET_ADMIN]
    devices:
      - /dev/net/tun:/dev/net/tun

  web-frontend:
    image: your-web-frontend:latest
    network_mode: "container:veilnet-conflux"
    depends_on: [veilnet-conflux]
    # Expose ports from inside the shared namespace
    # (publish/ingress depends on your environment)

.env on Host A (note the shared taint):

VEILNET_REGISTRATION_TOKEN=<YOUR_REGISTRATION_TOKEN>
VEILNET_GUARDIAN=https://guardian.veilnet.app
VEILNET_CONFLUX_TAG=host-a
VEILNET_CONFLUX_IP=10.128.0.5
VEILNET_CONFLUX_TAINTS=mesh-prod

Host B (example: backend API)

docker-compose.yml on Host B:

services:
  veilnet-conflux:
    container_name: veilnet-conflux
    image: veilnet/conflux:beta
    restart: unless-stopped
    env_file: [.env]
    cap_add: [NET_ADMIN]
    devices:
      - /dev/net/tun:/dev/net/tun

  api-service:
    image: your-api-service:latest
    network_mode: "container:veilnet-conflux"
    depends_on: [veilnet-conflux]

  # Example: database on Host B, also inside the same namespace
  database:
    image: postgres:15-alpine
    network_mode: "container:veilnet-conflux"
    depends_on: [veilnet-conflux]

.env on Host B (same shared taint as Host A):

VEILNET_REGISTRATION_TOKEN=<YOUR_REGISTRATION_TOKEN>
VEILNET_GUARDIAN=https://guardian.veilnet.app
VEILNET_CONFLUX_TAG=host-b
VEILNET_CONFLUX_IP=10.128.0.6
VEILNET_CONFLUX_TAINTS=mesh-prod

Access across hosts

Host A frontend reachable at: http://10.128.0.5:<port>
Host B API reachable at: http://10.128.0.6:<port>

Rift and Portal

Full-tunnel (rift) and SD-WAN–style (portal) Conflux modes

Kubernetes – sidecar

Direct service mesh with VeilNet via Conflux sidecar in pods. No other solution needed.