Route Network

network.routes sends a connection to one host:port to another, as a container’s port mapping does. The agent keeps the address its task names, and each workspace reaches its own copy of the service:

network:
  allowed_domains: ["127.0.0.1:61001"]
  routes:
    localhost:5003: 127.0.0.1:61001

curl localhost:5003/messages      # reaches 127.0.0.1:61001
curl localhost:5004/messages      # refused: no route, not allowed

A second workspace on the same server can route localhost:5003 to 127.0.0.1:61002 and allow only that, so neither reaches the other’s.

How a route applies

Every connection in the workspace follows it: curl, CLIs, mounts, and Python or JavaScript code. HTTPS, WebSocket and database connections too. Over HTTPS, the service’s certificate must still match the address the agent typed.
allowed_domains, denied_domains and pre_network policies check where the route goes, not the address the agent typed.
local and Sandlock runtimes don’t run in a workspace with routes, and sandbox runtimes (Docker, SSH) aren’t routed.
In a browser, a route for an https or wss address can change only the port.

Per session

A profile can set routes for its sessions. They replace the workspace’s routes for the same address, and the workspace’s allowed and denied lists still apply:

network:
  allowed_domains: ["127.0.0.1"]
  routes:
    localhost:5003: 127.0.0.1:61001
profiles:
  staging:
    network:
      routes:
        localhost:5003: 127.0.0.1:61002

Getting Started

Examples

Agents

VFS

Integration

CLIs

Mirage Shell

Agent Profiles

Policy

Runtimes

Infrastructure

Configuration

Notifications

Help

How a route applies

Per session

​How a route applies

​Per session

How a route applies

Per session