API Testing Behind the Firewall: How Remote Executors Work

The hardest question for any cloud-based testing platform isn't about features. It's the one the security team asks in the first meeting:

"Our staging environment isn't reachable from the internet. How exactly is your SaaS going to test it?"

The traditional answers are all bad. Whitelisting the vendor's IP range means opening your perimeter to a third party. A site-to-site VPN is a months-long project with its own audit burden. Running the whole test platform on-premises means you lose the SaaS: no managed updates, no shared dashboards, no cross-team visibility.

The remote executor model

A remote executor inverts the connection. Instead of the cloud reaching into your network, a lightweight agent inside your network reaches out:

1. You run a small executor process anywhere inside the private network — a developer laptop, a CI runner, a container in your cluster.
2. The executor authenticates with a scoped API key and polls the cloud platform over outbound HTTPS for pending jobs.
3. A job is nothing more than a batch of HTTP requests to execute: method, URL, headers, body.
4. The executor runs the requests against your internal APIs — traffic that never leaves your network — and posts the responses back over the same outbound channel.

The security profile is what makes this work in enterprise environments:

• No inbound firewall rules. Nothing listens. There is no port to open, no tunnel to maintain.
• No VPN. The only network requirement is that the executor can make HTTPS calls out — the same requirement as any workstation browser.
• Dumb by design. The executor doesn't know what a "test" is. It executes HTTP requests and returns results. All orchestration, comparison, and analysis stays in the platform. Less logic inside your perimeter means less to audit.
• Heartbeats and status. The platform tracks executor health (online/offline, last heartbeat, version), so a silent failure is visible immediately.

Scoping: who gets to use which executor

In practice, one executor is never enough, and "everyone shares one tunnel" is how test runs end up hitting the wrong environment. Executors should be scoped:

Scope	Typical use
Organization	A shared executor in the corporate network that any team can route jobs through.
Brand / project	An executor colocated with a specific brand's staging stack.
User	A personal executor on a developer's laptop for testing services running locally.

The routing rule is simple: most specific wins. A developer with a personal executor tests against localhost; everyone else falls through to the brand or organization executor.

What this unlocks

Once executors are in place, the distinction between "internal API" and "public API" disappears from your test strategy. The same regression suite, the same baselines, the same dashboards cover both — including the pre-production environments where regressions should be caught in the first place.

APIpact ships this model natively: register an executor with an API key, and every snapshot or comparison can be routed through it. If your APIs live behind a firewall — which is to say, if you're an enterprise — we should talk.