7.2 Deploying CertiQA in Private VPCs, On-Premises & Air-Gapped Environments

How to deploy runner agents inside private AWS/Azure/GCP VPCs, Kubernetes clusters, and air-gapped networks behind corporate firewalls.

Reaching What the Public Internet Can’t

Most of what enterprises actually want tested – a staging web app, an internal agent endpoint, a database sitting behind a VPN – was never meant to be reachable from the public internet, and most security teams won’t open an inbound rule for a third-party SaaS product regardless of how well-intentioned the request is. A CertiQA runner agent solves this by living inside your own network instead of asking your network to open up to it: deployed in your VPC, it reaches internal services the same way anything else already inside that VPC does, with no new inbound path created for CertiQA specifically.

One Network Contract, Three Deployment Shapes

Whether the runner ships as a long-lived Docker container, an ECS Task, or a Kubernetes Pod, the network contract behind it is identical: the runner dials outbound over HTTPS to the CertiQA control plane to pick up work and report results, and nothing needs to accept an inbound connection on your side for the runner itself. The deployment variables are covered in the CLI Runner guide.

Air-Gapped, With One Honest Caveat

A genuinely air-gapped network – zero egress, full stop – can’t reach a SaaS control plane, and there’s no self-hosted, fully offline control-plane mode of CertiQA to fall back to; the outbound-only model above assumes the runner can reach the CertiQA control plane over HTTPS, even if nothing else in that network segment can. In practice, “air-gapped” enterprise environments almost always mean an isolated segment with one narrow, explicitly allowlisted egress path rather than literally zero connectivity – and that’s the shape this deployment model is built for: point the runner’s outbound access at that single allowlisted path, and everything else in the segment stays exactly as isolated as it was before.

Corporate TLS Inspection and Multi-Cloud Parity

• If your egress path runs through a corporate proxy that terminates and re-signs TLS, mount your proxy’s CA certificate into the runner container and set NODE_EXTRA_CA_CERTS – see the CLI Runner guide for the exact flag, since the runner’s outbound HTTPS calls fail verification the same way any other Node process behind that proxy would otherwise.
• The runner needs nothing cloud-specific to function – the same container image and environment variables work identically whether the VPC is AWS, Azure, or GCP, since the only requirement is outbound internet reachability, not an integration with any one cloud’s networking primitives.

• CLI Runner & Headless Execution — The exact docker run command, environment variables, and exit codes a pipeline gates on.