What it does
Testkube provides a control plane and Kubernetes runners for defining, triggering, and reviewing automated tests. Instead of replacing the test tools in a project, it orchestrates workflows built around existing scripts and frameworks such as k6, Cypress, Playwright, or Postman. Teams can run the control plane in their own infrastructure or use the hosted service, while runners execute work in the clusters that need coverage.
Pick where the control plane and test runs live
Testkube's quickstart separates its Dashboard and workflow management from the Test Execution Runner that launches jobs in a Kubernetes cluster. A team can run both on its own infrastructure, or use the hosted control plane while installing runners where its tests should execute. Even the local evaluation path expects a Kubernetes environment, so it is not a drop-in desktop test runner.
To try a workflow, start with an existing test script and define the image, source, and command it needs in a TestWorkflow YAML file. The quickstart also supports importing a workflow in the Dashboard's Workflow Wizard. A sample flow can then be applied and run with commands such as kubectl apply -f my-workflow.yaml && testkube run tw my-test --watch. This is an illustrative command from the official guide, not a command run for this record.
After execution, inspect the workflow status and logs, then open its artifacts in the Dashboard or retrieve them with the CLI. The quickstart describes adding triggers from CI, a schedule, or a Kubernetes event. This is useful when a team wants existing load, browser, API, or other tests to run in the right cluster and leave a traceable result. Testkube coordinates the job; your team still supplies the test itself, expected behavior, data, and credentials.
Pricing has a paid Pro control plane and a custom Enterprise offering, alongside a separately described open-source runner. The public repository's top-level license says files use a mix of MIT and the Testkube Community License, so verify component-level terms before relying on an assumed license for the whole platform.
Strengths
- Workflows can wrap existing testing tools and scripts rather than requiring teams to rewrite every test in a proprietary language.
- Runners execute tests in Kubernetes infrastructure near the application or environment being checked.
- The Dashboard and CLI expose execution status, logs, and artifacts, with documented CI, schedule, and Kubernetes-event triggers.
Watch out for
- A Kubernetes environment is required for test execution, and a self-hosted shared deployment adds control-plane and runner operations.
Best for
- Centralizing test workflows that already use tools such as k6, Playwright, Cypress, or Postman
- Running integration or performance checks in Kubernetes clusters close to the target service
- Collecting workflow logs and artifacts while triggering tests from CI or cluster events
Sources
- Testkube: The Testing Platform for Cloud-Native Teams (Oct 25, 2026)
- Testkube Quickstart | Testkube Documentation (Oct 25, 2026)
- Testkube Pricing | Open Source & Commercial Plans (Oct 25, 2026)
- kubeshop/testkube (Oct 25, 2026)
- testkube/LICENSE at main · kubeshop/testkube · GitHub (Oct 25, 2026)