A team running its own website-performance tests needs somewhere to submit jobs and inspect the collected results. A private WebPageTest server provides that coordination and result-storage layer, while separate agents run the browsers that make the measurements. It can support a controlled testing service for the team. Test results may include screenshots, request details and other sensitive information, so submission permissions, agent access and result retention need a deliberate design independent of the server’s web interface.
Current guidance
The historical incubator chart is unsupported. Current upstream source points to separate server, agent and documentation repositories and distinguishes Polyform Shield and Apache-licensed development branches. Select the intended branch and verify its deployment prerequisites rather than assuming the old chart represents current packaging.
A private instance needs access control for test submission and results, agent authentication, storage retention and a controlled network path from agents to targets. Tests can capture screenshots, page bodies, cookies and request details, so results should not become publicly readable merely because the tested URL is internal. Agent connectivity and the user-facing UI may warrant different exposure rules.
For migration, preserve server configuration, location definitions, API credentials and required result artifacts. Rehearse queue submission, agent pickup, result upload and historical-result access with a compatible pair of versions. Verify cleanup and backup restore independently from a successful new test. No maintained drop-in Kubernetes chart or automatic import path from every old private-instance release was established in this review.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
This chart bootstraps a private WebPageTest Server deployment on a Kubernetes cluster using the Helm package manager.
Depending on your configuration you can then use Official WPT agent instances to test your websites.
Ingress(es)
This chart provides support for ingress resources. If you have an ingress controller installed on your cluster, such as nginx-ingress or traefik you can utilize the ingress controller to service your WebPageTest application.
To enable ingress integration, please set ingress.enabled to true.
Hosts
Most likely you will only want to have one hostname that maps to this WebPageTest installation for scripts or end users to interact, then a separate instance for the AMI’s to operate on (see AgentIngress below). It is, however, possible to have more than one host. To facilitate this, the ingress. hosts object is an array.
For each item, please indicate a name, tls, tlsSecret, and any annotations that you may want the ingress controller to know about.
Indicating TLS will cause WebPageTest generate HTTPS urls, and WebPageTest will be connected to at port 443. The actual secret that tlsSecret references does not have to be generated by this chart. However, please note that if TLS is enabled, the ingress record will not work until this secret exists.
For annotations, please see this document. Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers.
TLS Secrets
This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are three common use cases:
helm generates / manages certificate secrets
user generates / manages certificates separately
an additional tool (like kube-lego) manages the secrets for the application
Generally speaking WebPageTest is difficult to secure / restrict access. In creating this chart the design is that a user would use the ingress listed above. The ingress above would have appropriate access restrictions using either whitelisted IP’s, http basic auth or both. This however would block access to the agents without significant additional config. Agents in a remote region would probably need a region to region VPN to get access. Rather than doing that we create a second host header and restrict the url path to /work, /cron and /jpeginfo. The agents use /work and the server connects to itself on /cron and /jpeginfo. This way 3rd parties do not have access to create tests, but any host (with the correct keys) can get work units and post results.
Sources & further reading
Spotted something that needs another look?
Help improve this page →