Testing behind a firewall

Not every app is on the public internet. Pre-production and staging environments often sit behind a corporate VPN, a firewall, an IP allowlist, or on a developer’s localhost. AegisRunner reaches all of them — pick the option that matches your setup.

Your situation	Use
Staging is on the internet but IP-restricted	Static-IP allowlist
A dev app on localhost	aegis tunnel
Staging behind a VPN / firewall / air-gapped	Self-hosted runner

1. Static-IP allowlist

If your target is reachable from the internet but only from approved IPs, allow AegisRunner’s scanner addresses through your firewall or WAF. Find the current list under Project settings → Testing behind a firewall — the scanner egresses from a small, stable set of static IPs you can paste into an allow rule. No agent to install; scans run from our cloud as usual.

2. aegis tunnel (localhost)

Working on an app that’s only running on your machine? Open a temporary, encrypted tunnel from a local port to the cloud scanner — no deploy, no public URL.

# install the CLI once (zero dependencies, Node 18+)
npm install -g @aegisrunner/cli

# expose the app running on localhost:3000
export AEGIS_TOKEN=aegis_xxxxxxxx
aegis tunnel --port 3000

The tunnel stays open while the command runs and closes when you stop it. Point a scan at the URL it prints. It’s meant for quick, interactive checks against local dev — for always-on private environments, use a self-hosted runner instead.

3. Self-hosted runner (VPN / firewall / air-gapped)

Run AegisRunner inside your own network. The runner makes an outbound-only HTTPS connection to AegisRunner, claims jobs, executes them locally against your private targets, and reports results back. No inbound port is opened — so it works from behind a corporate firewall, a VPN, or NAT.

Docker (recommended)

docker run --network host \
  -e AEGIS_TOKEN=aegis_xxxxxxxx \
  aegisrunner1/runner

—network host lets the runner reach private hosts on your LAN/VPC. If your target is on a specific Docker network, attach the container to that network instead (—network my-net). The image is also on GitHub Container Registry: ghcr.io/aegis-runner/runner.

npm

npm install -g @aegisrunner/cli
aegis runner            # reads AEGIS_TOKEN from the environment

Get a token

Create a CI trigger token under Manage → CI/CD (Pro or Business plan). The runner is scoped to that token’s project; revoke it there to cut a runner off.

Queue a check

Once a runner is connected, queue work for it from the CLI, from CI, or from the dashboard (Project settings → Self-hosted runner → Run a check):

# waits for the result and prints it
aegis runner-enqueue --url http://staging.internal:8080 --note "nightly smoke"

# fire and forget
aegis runner-enqueue --url http://staging.internal:8080 --no-wait

Networking & security

• Outbound only. The runner initiates every connection; you never open an inbound port or expose your environment to the internet.
• Egress: allow HTTPS to app.aegisrunner.com (or your configured AEGIS_API host).
• Data stays local. The runner reaches your target directly; the target’s traffic stays in your network. Only the job result — status, timings, findings — is sent back.
• Least privilege. A single CI token, scoped to one project. The container runs as a non-root user and needs no privileges.

Which option should I use?

IP-restricted but public → allowlist. A local dev app → aegis tunnel. Anything genuinely private, on a VPN, or air-gapped → self-hosted runner. All three use the same project trigger token, so you can mix them as your environments differ.

Related

• CI/CD Integration — trigger scans and runs from your pipeline.
• Test Data & Environments — credentials, cookies, and headers for authenticated targets.