Networking Overview

Trailer workspaces run as containers, and each workspace attaches to one or more networks. This section covers how those networks work, how the agent discovers the host interfaces a network can use, and the details of the macvlan driver.

A workspace’s services can be reached in a few independent ways:

• Workspace URLs publish HTTP services at public host names, served either through the agent proxy or through Traefik. See Workspace URLs and routing.
• Port publishing exposes a container port through the host’s own IP address, the same as a Docker -p host:container mapping.
• Macvlan gives a workspace its own address directly on your LAN, as if it were a separate physical machine.

Network drivers

Trailer networks use one of two Docker drivers, selected at creation and immutable afterward:

• Bridge: the default. Docker manages an internal subnet and gateway, and containers reach the outside world through the host. No extra fields.
• Macvlan: gives the container a virtual network interface bridged at layer 2 onto a physical host NIC. Other machines on that LAN segment can talk to the container directly at its macvlan IP, as if the container were a separate physical device.

Most workspaces use the bridge driver. Reach for macvlan when a workspace needs to appear as a first-class device on your LAN, with its own IP that other machines can find. Creating a macvlan network means choosing a parent interface on the host, which is where interface detection comes in.

In this section

• Port Publishing: expose a workspace’s TCP or UDP ports through the host’s own address from the workspace form.
• Host Interface Detection: how the agent discovers the host’s network interfaces, and what to do when one is missing.
• Macvlan Networks: the macvlan driver in depth, including the routing caveat when you combine it with published host ports, and the Windows VDI specifics.