Self-Hosted AI Testing with Your Own Keys

"Self-hosted AI testing" usually gets asked as one question but is really two: where does the platform run, and where do the AI provider keys and application data actually go? NexGen QA answers both. Deployment can be cloud SaaS, on-premise via Docker/Kubernetes, or fully air-gapped; separately, the BYOK (Bring Your Own Key) model controls where AI provider keys live regardless of deployment mode.

Deployment options

Enterprise and Government plans include on-premise deployment with full feature parity, multi-tenant organization isolation, and field-level AES-256-GCM encryption. On-premise deployment also supports a private container registry, so images never have to be pulled from a public registry in an air-gapped environment.

BYOK: where your AI provider keys go

Separately from where NexGen QA itself runs, BYOK controls where your AI provider keys live and where AI inference happens. From Settings → Custom Models you can register any OpenAI-, Anthropic-, or Gemini-compatible endpoint — including a private or self-hosted model deployment — alongside the built-in GPT-4o, Claude, Gemini and DeepSeek options. The GitHub Actions runner integration (see the dedicated GitHub Actions testing page) takes this further: AI-powered tests execute inside your own CI runner using a key from your own GitHub Secrets, so the key is never even transmitted to NexGen QA.

• Register a custom AI endpoint from Settings → Custom Models — OpenAI-, Anthropic-, or Gemini-compatible, including self-hosted models.
• Run AI-powered tests inside your own GitHub Actions runner with a key from your own GitHub Secrets.
• Combine self-hosted deployment (Docker/Kubernetes/air-gapped) with BYOK for a fully self-contained testing environment.

What this does and doesn't change

Self-hosted deployment does not reduce which testing modules are available — Enterprise and Government on-premise deployments have full feature parity with the hosted platform. What it changes is who controls the infrastructure, network boundary, and key material. If your requirement is specifically CI-scoped key isolation rather than hosting the whole platform yourself, the BYOK GitHub Actions runner alone may be enough without a full on-premise deployment.

Kubernetes and container details

The Kubernetes path uses Helm charts intended for production clusters, while Docker Compose covers single-node deployments for smaller teams or evaluation environments. Both paths support a private container registry, which matters specifically for air-gapped installs where pulling images from a public registry like Docker Hub is not possible or not permitted by policy. On-premise deployment also carries multi-tenant organization isolation and field-level AES-256-GCM encryption forward from the hosted platform, so self-hosting does not mean giving up the isolation guarantees a multi-team organization relies on.

A note on evaluating "self-hosted AI testing" claims generally

When comparing platforms on this specific point, it's worth separating three things that get conflated in marketing copy: where the platform's control plane runs, where your AI provider key is stored, and where AI inference actually happens. A platform can be "self-hosted" in the first sense while still sending prompts to a third-party AI API, or "BYOK" in the second sense while still executing on the vendor's infrastructure. NexGen QA's BYOK GitHub Actions runner addresses the second and third together for CI-triggered tests: the key stays in your GitHub Secrets and the AI call is made from your own runner. Full on-premise deployment (Docker/Kubernetes/air-gapped) additionally addresses the first, for teams that need the whole platform inside their own network boundary.

Who this is for

Teams with data-residency obligations, classified or disconnected network requirements, or a policy against sending source code and AI provider keys to third-party infrastructure. If your specific concern is FedRAMP/FISMA/IL5 requirements for a government workload, see the FedRAMP and FISMA compliant testing guide linked below.

Planning a self-hosted rollout

A typical rollout starts smaller than a full on-premise install: many teams begin with the BYOK GitHub Actions runner alone, since it addresses the key-isolation concern for CI-triggered tests without requiring a Kubernetes cluster or an air-gapped network to stand up first. Moving to full on-premise deployment — Docker Compose for a single node, or the Kubernetes Helm chart for a production cluster — becomes the next step once the requirement extends beyond CI to the platform's dashboard, test case management, and reporting also needing to live inside your own network boundary.

Before committing to a fully air-gapped install, it's worth confirming which specific requirement is driving it: a contractual data-residency clause, a classified-network mandate, or an internal security policy against any external network call. Each of those is satisfied differently — a data-residency requirement may only need sovereign cloud deployment in a specific region, while a classified-network mandate genuinely requires the offline, air-gapped installation path with no external dependency at all.