VisualRunner Enterprise

Run visual monitoring inside your own network

The Private Runner is a small Docker agent you host on your own infrastructure. It captures the environments our servers can't reach on their own — VPN-only staging, internal admin tools, services bound to localhost — and connects outbound only. No inbound port, and no VPN or network credentials are ever handed to VisualRunner. Environments that also sit behind a login work too: the credentials you configure are sent to your runner over its own outbound connection, decrypted per job.

Talk to us about a Private Runner Read the setup guide

Why self-host

Every screenshot needs a browser to run somewhere. VisualRunner's own capture servers sit on the public internet, so they can't see anything behind your firewall. The Private Runner runs where access already exists — inside your network — so it never has to authenticate its way in. It only ever does one thing: run the capture jobs you've already configured. It uses the same browser engine as our capture servers, pinned to the same version, so a runner screenshot matches one taken by us.

Outbound-only by design

The container long-polls VisualRunner over HTTPS for jobs and uploads the finished PNGs back. It opens no ports and needs no inbound firewall rule. Revoke its token from workspace settings and it stops immediately.

Bring your own storage

Point the workspace at your own object storage and both the capture execution and the stored screenshots stay on infrastructure you control. VisualRunner keeps only the metadata it needs to show you the timeline and comparisons.

You choose the throughput

One capture slot by default. Set RUNNER_CONCURRENCY (up to 16) to match the CPU and RAM of the box you run it on — no request to us, and nothing metered or billed per job.

Sizing & concurrency

Each concurrent capture slot is a fresh headless-Chromium context that spikes one CPU core while a page renders and holds ~2 GB of RAM. Size the host to the number of captures you want to run at once — and to whether those are dedicated or shared / burstable vCPUs.

Dedicated CPU

AWS c7/c6, DigitalOcean CPU-Optimized, GCP c2, Hetzner CCX — you get the whole core, so budget ~1 vCPU per slot plus one for the system.

RUNNER_CONCURRENCYSuggested vCPUSuggested RAMCaptures at once~100 captures
1 (default)2 vCPU4 GB1 at a time~50 min
23 vCPU6 GB2 at once~25 min
45 vCPU10 GB4 at once~13 min
89 vCPU18 GB8 at once~7 min
16 (max)17 vCPU34 GB16 at once~3 min

Shared / burstable CPU

AWS t3/t4g, DigitalOcean Basic, GCP e2, Hetzner CX/CPX — each vCPU is a scheduled slice of a core with a burst-credit budget, so roughly double the vCPU count and treat the times as best-case: a long backlog burns through the credits and then throttles.

RUNNER_CONCURRENCYSuggested vCPUSuggested RAMCaptures at once~100 captures
1 (default)2 vCPU4 GB1 at a time~50 min
24 vCPU6 GB2 at once~25 min
48 vCPU10 GB4 at once~13 min
816 vCPU18 GB8 at once~7 min
16 (max)32 vCPU34 GB16 at once~3 min

RUNNER_CONCURRENCY = N runs N captures at once, so a backlog clears roughly N× faster; the ~100 captures column is that backlog at a typical ~30 seconds per capture — planning estimates, not guarantees. RAM is the same either way — it tracks the number of slots, not the core type. Past the per-runner cap of 16, run another runner container on another host. Full sizing guidance is in the setup guide.

How it's licensed

The Private Runner is a capability we switch on for your workspace — not a metered add-on. You pay for VisualRunner scale through your custom Enterprise quote (monitors, storage, seats, automated captures, integrations); you provide and size the host the runner runs on. Its compute is never billed by us.

Get a quote

Tell us about the environments you need to monitor and we'll put together a custom Enterprise plan with the Private Runner enabled.

Talk to us about a Private Runner

Also available for managed environments: a minimal-permission browser extension .