Journey Lanes

Relay agent

Reach a private network without opening it

For a staging server, a self-managed GitLab or Bitbucket, or an OpenAPI document that can’t be reached from the internet: a small agent in your network dials out to Journey Lanes and makes the calls it is sent, to the hosts you allow and nothing else.

How it works

The relay agent runs inside your network, opens one outbound WebSocket to Journey Lanes on port 443, and calls only the hosts on its allow list. Your network Journey Lanes runs, monitors, scans send calls to the agent Relay agent AGENT_ALLOW, AGENT_METHODS staging.internal:443 gitlab.corp:443 anything else: refused one outbound WebSocket, port 443
  • The agent opens one WebSocket out to Journey Lanes on port 443, like a browser. Nothing in your firewall opens, and the agent never listens on a port.
  • It only calls the host:port entries in its allow list, and never link-local, cloud metadata or multicast addresses, even when a listed name resolves to one.
  • It makes plain HTTP calls one hop at a time and never follows redirects itself, so every hop is checked against the allow list again.
  • Agents belong to your organization: one per network, used by any of its projects. Owners and admins make them under Organization → Relay agents; the token is shown once, stored as a hash, and replaced in one click.

What you trust Journey Lanes with

Within the allow list, the agent makes the calls Journey Lanes sends it, with the methods, headers and bodies Journey Lanes chooses, and sends back the answers: that is what it is for. So list only the hosts Journey Lanes needs. For read-only use, such as a code host or an OpenAPI document, set AGENT_METHODS=GET,HEAD and the agent refuses every other method itself. The agent checks every call on its own; it doesn’t rely on Journey Lanes to stay inside the list.

The agent logs one line per call (time, method, host, path without the query, status and duration), never headers or bodies.

Settings

VariableMeaning
JOURNEY_LANES_URLThis installation: https://flow.developerlab.nl
AGENT_TOKENThe agent’s token, shown once when you make it
AGENT_ALLOWHosts it may call, as host:port, comma-separated; *.svc.corp:8443 covers subdomains
AGENT_METHODSOptional: the only methods it makes, such as GET,HEAD
AGENT_MAX_CALLSCalls at once, 32 by default

Run it

The app shows the exact command when you make an agent. This installation publishes the agent as a container image, pinned by digest: one binary on a distroless base, running as a non-root user, without a shell.

docker run -d --restart unless-stopped --name journey-lanes-agent \
  -e JOURNEY_LANES_URL=https://flow.developerlab.nl \
  -e AGENT_TOKEN=jla_… \
  -e AGENT_ALLOW=staging.internal:443,gitlab.corp:443 \
  ghcr.io/developer-lab/flow-creator-agent:src-3dbbc67b052e@sha256:9e384ab398ef697525b85c2219c488609f125fe6412e8b16794cc60661543ea9

Several copies can run on one token, for availability: they share the calls, and one going away doesn’t take the agent offline. The agent reconnects by itself when its connection drops.

What goes through it

An environment, a self-managed GitLab or Bitbucket, or an OpenAPI URL picks an agent under “Reach through”. Calls to hosts that agent allows go through it: runs, monitors, deploy checks, audits, load tests, connection tests, sign-ins, inbox reads and scans. Other calls, such as a public identity provider, stay direct with every check they had. Alerts always go direct; gRPC over HTTP/2 and the sign-in browser don’t use an agent.

Limits

Per agent, at most 16 calls at once and 1,200 a minute, bodies up to 5 MB and 30 seconds per call. Load tests through an agent run at most 8 calls at once.

Test the environment behind your firewall

Make an agent under Organization → Relay agents and run it next to your staging server.

Create an account See how it works