Testkube: running your existing test tools inside Kubernetes

What Testkube actually replaces

Most teams already have tests. What they do not have is a single place where those tests live as first-class objects with an identity, a schedule, a result history and an API. Testkube's pitch is that it gives you that without asking you to port anything: the README states you can "Execute any tests/tools/scripts at scale; API, E2E, Performance, Security, Infrastructure", which in practice means the platform wraps a container image or a script rather than a test framework. If your suite already runs as `pytest`, `newman`, `k6` or a shell script in CI, the migration is mostly packaging.

The target reader is a platform or QA engineer running workloads on Kubernetes who is tired of test logic being scattered across CI YAML, cron jobs and laptops. It is a weaker fit for a team with no cluster, or one whose tests are inseparable from a CI provider's build environment. The README frames the split explicitly: an MIT-licensed standalone agent for "single-cluster setups, self-managed environments, and evaluating Testkube", and an Enterprise tier that adds SSO/SCIM, RBAC, Teams, Resource-Groups and Audit-logs.

TestWorkflows, executors and the agent's data flow

The repository layout is a Go monorepo with `cmd/`, `internal/`, `pkg/`, `api/` and `proto/` at the top level, plus a `k8s/` directory and a `sqlc.yaml` that points at generated database access. That combination tells you the shape of the system: a Kubernetes operator and API server written in Go, a gRPC surface defined in `proto/`, and a persistent store behind SQL queries. The `.env.sample` file shows the agent can run in two modes, with `TESTKUBE_PRO_URL`, `TESTKUBE_PRO_API_KEY`, `TESTKUBE_PRO_ORG_ID` and `TESTKUBE_PRO_ENV_ID` used when it connects out to a Control Plane instead of standing alone.

The unit of work is the TestWorkflow, which the README describes as building "up from a single test to a fully orchestrated pipeline". Results, artifacts, logs and resource metrics are aggregated, per the README's "See Everything" bullet, for centralized troubleshooting. Triggering is deliberately plural: manual, scheduled, from CI/CD or GitOps pipelines, from Kubernetes events, via the REST API, or through MCP. That last one matters if you are wiring an AI agent into the loop, because the MCP server is a supported integration path rather than a side project.

The honest trade-off is that this is a lot of machinery. An operator, an API server, a database layer and a gRPC contract exist so that tests become addressable objects. If you only need to run one script on a schedule, a Kubernetes CronJob is a smaller thing to own.

Installing the standalone agent and running a first test

The README points at two installation routes for the open source agent: a Helm chart or the CLI, documented under the standalone agent install page. The repository also ships an `install.sh` at the top level and a Makefile that detects Linux, Darwin and Windows. Because this article has not executed any of it, treat the commands below as the documented entry points rather than verified output.

Start with the CLI, which is the interface most of the rest of the workflow assumes:

testkube install

The README describes this as the easiest path to set up Testkube and run your first tests. The CLI installs the agent into the current Kubernetes context, so confirm you are pointed at the right cluster before running it.

If you prefer Helm, the README directs you to the Helm installation section of the standalone agent docs. The repository's `tilt-values.yaml` and `Tiltfile` show the maintainers use Tilt for local development, which is a reasonable signal about how the components are expected to be wired together, though it is a development path rather than an end-user one.

Once the agent is running, tests are defined as Kubernetes resources and executed through the CLI. The README's quickstart is the reference for the exact resource shape; the important thing to understand is that a test references a container image or script, and the agent schedules it as a workload in your cluster. Results and artifacts land back in the agent's store, which is what the dashboard reads from.

For CI/CD integration, the README lists webhooks and the Testkube REST API as the two native integration surfaces, with the MCP server as a third for AI-driven workflows. If your pipeline already calls HTTP endpoints, the REST API is the least invasive hook.

Where Testkube stops being the right tool

Testkube runs tests, it does not generate load. The README lists performance testing among the categories you can execute, but that means Testkube can orchestrate a k6 or similar run as a workload, not that it provides the load-generation engine. If you need a distributed load generator with its own metrics pipeline, you are bringing that tool and Testkube is only the scheduler.

Second, the open source agent is scoped to a single cluster. The README is direct about this: the standalone agent is for "single-cluster setups". Cross-cluster aggregation is a Control Plane concern, and the Control Plane is the Enterprise side of the product, configured through the `TESTKUBE_PRO_*` variables in `.env.sample`. A team that adopts the OSS agent and later discovers it needs a unified view across ten clusters is looking at a commercial conversation, not a configuration change.

Third, the licence metadata on the repository is reported as NOASSERTION even though the README describes the open source agent as MIT-licensed. That mismatch is worth resolving with your own legal review before you build a dependency on it; GitHub's classifier failing to identify a licence is common when a repository carries multiple licence files, and this one has a `licenses/` directory. It is not evidence of anything sinister, but it is not the same as a clean MIT badge either.

Finally, Testkube does not replace your CI system. It does not build images, manage environments or deploy. It triggers and observes tests. Teams expecting it to absorb the whole pipeline will be disappointed.

Testkube compared with k6 and Jenkins

The two comparisons people search for most are k6 and Jenkins, and they are different kinds of comparison.

k6 is a load-testing tool. It generates traffic from a runner and reports on latency and throughput. Testkube is an orchestrator: it can run k6 as one of its executors, per the README's claim that you can execute "Performance" tests among other categories, but it contributes scheduling, artifact collection and result history rather than virtual users. Choosing between them is a category error; the realistic option is running k6 inside Testkube when you want the results in the same place as your functional tests.

Jenkins is a general-purpose CI server. It owns source checkout, build, test and deploy, and it has a plugin ecosystem that reaches into almost everything. Testkube owns only the test execution and observation slice, and it does so from inside the cluster rather than from an external controller. The practical difference shows up in where test definitions live: a Jenkins pipeline keeps them in a Jenkinsfile next to the application code, while Testkube keeps them as Kubernetes resources that can be applied, versioned and reconciled like any other cluster object. That is a real advantage for GitOps shops and a real disadvantage for teams that want test configuration to travel with the repository and nothing else.

For open source alternatives in the same space, the relevant question is not which tool has more features but which one your existing test images can run under with the least repackaging.

Maintenance, releases and licence cost

The repository is not archived, and the last push was on 2026-09-10. Recent tagged releases include 2.13.1 on 2026-08-27, 2.12.2 on 2026-08-20 and 2.12.1 on 2026-08-10, so the release cadence over that window is roughly weekly to fortnightly. The `go.mod` pins `go 1.26.0` with a `go1.27.1` toolchain, which means building from source requires a recent Go toolchain and will not work on an older one.

Upgrade cost depends on which mode you run. The standalone agent is a Helm release or a CLI install, so upgrades follow whatever the chart supports; there is no documented rollback procedure in the README, which is something to establish before you upgrade a cluster that other teams depend on. If you run in agent mode against a Control Plane, the version compatibility between agent and control plane becomes a variable you do not control on your own schedule, and the README does not document that compatibility matrix.

On licensing: the README states the open source agent is MIT-licensed, while the repository's licence field is reported as NOASSERTION and the tree contains a `licenses/` directory. The Enterprise tier is a separate commercial product. Nothing here is legal advice, but the practical implication is that if you need written certainty about what you may redistribute or embed, the README's MIT statement and the repository's licence metadata are not currently saying the same thing, and that is a question for your legal team rather than a README.

Editorial conclusion

Adopt the standalone agent if your tests already run as containers or scripts and you want Kubernetes-native scheduling, artifacts and a CLI instead of a pile of CI jobs. Do not adopt it as a load-testing engine or as a replacement for a CI system that owns your build and deploy pipeline. Before committing, verify three things in your own cluster: that your test images can run under the agent's execution model, that the namespace and RBAC the Helm chart creates match your multi-tenancy rules, and whether you need the Control Plane for cross-cluster results, since that moves you off the MIT-licensed agent and onto the Enterprise offering.

Frequently asked questions

Official sources

1. Issues
2. kubeshop/testkube on GitHub
3. Project website
4. README
5. Releases