Testkube Open Source: What It Is and What You Can Do With It

AI writes more code than ever, and every line of it still needs testing. That pressure is pushing test execution out of the build pipeline and into the cluster where applications actually run. Testkube open source is a Kubernetes-native framework built for exactly that: it runs your existing tests inside your clusters, decoupled from any single pipeline tool. This guide explains what Testkube open source is, how it works, and when to reach for it, based on a webinar with Testkube CTO Ole Lensmar.

What is Testkube open source?

Testkube open source is a framework for running automated tests inside your Kubernetes clusters. The project started as a single in-cluster component, and that agent remains the heart of it today. Rather than tying your tests to a build runner, you define them as Kubernetes resources and let Testkube handle in-cluster test execution.

It runs any test that can be packaged as a container image. That covers end-to-end tests, load tests, API tests, security tests, and infrastructure tests. Because the work happens inside the cluster, test runs inherit the scalability of Kubernetes itself, so a heavy load test or a large parallel run is constrained only by the resources your cluster has available.

You can schedule a test in several ways: trigger it from CI/CD, run it on a cron schedule, fire it from a Kubernetes event, or call it through the CLI or the REST API. Whatever path you choose, Testkube captures the logs, results, and artifacts from every run and keeps them in one storage layer. That single source of truth is the foundation for centralized test observability.

How Testkube open source works

Testkube has two pieces. There is a control plane that you install in your cluster, and there are agents that run your tests. The agents are open source, and they are what this guide focuses on. You can think of it as an open-core model: the open source agent does the test execution, while the commercial control plane adds enterprise orchestration on top.

A Testkube open source installation has a few core components:

• A CLI you install with Homebrew or another package manager. The CLI is also a kubectl plugin, so you can run it standalone or through kubectl.
• The open source agent, installed with the CLI or a Helm chart. It contains the Kubernetes CRDs and controllers, an API server that exposes the REST API, a workflow execution runtime, and a storage layer.
• A storage and event layer based on MongoDB, PostgreSQL, MinIO, and NATS.

The installation itself is lightweight. The heavy lifting happens in the tests as they run. When Testkube is asked to run a test, it generates a Kubernetes job and pod that executes the actual test, captures the output, and then tears the pod down. Those short-lived jobs and pods are the only load Testkube places on your cluster.

Beyond the CLI and agent, the ecosystem includes a GitHub Action, a Backstage plugin for visualizing executions in a developer portal, a workflow marketplace for ready-to-use infrastructure tests, and a Tilt setup for local development. The agents overview in the documentation covers the architecture in more detail.

What Testkube open source is not

This is where most of the confusion comes from, so it is worth being precise.

It is not a testing tool. Testkube does not replace your frameworks. It provides an execution engine that runs your existing test scripts. You do not rewrite anything. If you use Playwright today, Testkube runs the Microsoft Playwright image; if you use k6, it runs the Grafana k6 image, and the same applies to Cypress, Postman, and your own custom images.

It is not a CI/CD tool. Testkube complements CI/CD with continuous testing. Teams adopting it do not get rid of Jenkins or GitHub Actions. They augment their pipelines to run tests through Testkube.

It is not an analytics tool. The open source agent is a storage layer for results, not a reporting engine. For trend analysis over time, you extract that data and push it into another system.

It is not a dashboard. Testkube open source does not have a visual interface. An earlier version did, about two years ago, but that is no longer part of the product. You interact with the open source agent through the CLI and the REST API.

Core resources: test workflows, test triggers, and webhooks

Testkube defines its core constructs as Kubernetes CRDs, which means you can manage them with GitOps, validate them with admission controllers, and version them like any other resource.

Test workflows and templates

A test workflow is the core abstraction for running a specific test. It is a YAML vocabulary designed for testing, similar in spirit to a workflow engine like Argo Workflows but built around the needs of test execution. Each workflow defines the content (where the test lives), the container image to run it, the steps to perform, and the artifacts to collect when the test finishes. Test workflow templates let you reuse common snippets, for example a standard set of resource limits for all your load tests, so configuration stays consistent across workflows.

Test triggers

A test trigger defines how a Kubernetes event runs a workflow. You specify which resources to watch, which events to listen for, and which workflows to fire when those events happen. A common pattern is to run a short safety-net test whenever a deployment is updated. One useful property is that triggers cannot be bypassed: however the resource changes, by kubectl apply or through a GitOps tool, the tests still run. For that reason, teams keep trigger-based tests short and run long end-to-end suites on a schedule instead.

Webhooks

A webhook integrates Testkube with external tools. When a workflow finishes, a webhook can notify Slack or Teams, create a Jira issue, or open a PagerDuty alert. You can listen for specific events, including state-change events such as a workflow moving from failing to passing, so you are not notified on every single run. Webhook templates let you reuse a core definition across many webhooks with different parameters.

Why run tests with Testkube instead of CI/CD

If your tests are already automated in Jenkins or GitHub Actions, why move them? A few reasons come up repeatedly with open source users.

• Scalability. Tests run in your cluster, so they use whatever resources Kubernetes has available. This matters most for resource-heavy work such as load testing, where a CI runner is often too slow or too costly.
• Security and in-cluster access. To test an internal microservice or validate low-level cluster constructs, you do not need to open network access from the outside. The tests already run where the application lives.
• Consistency. The classic problem of a test that passes locally but fails in the pipeline shrinks when every run happens in Kubernetes, whether that is minikube or kind locally, an ephemeral cluster in CI, or a staging cluster.
• Decoupling. Testers are no longer tied to a CI build to rerun a test or put it on a schedule. They can trigger tests whenever they need, through any of the supported methods.
• Centralized results. No matter how a test was triggered, the results land in one place. This is the heart of test orchestration, and many teams find they are already doing it in an ad hoc way.

Common use cases

Decoupling test execution from CI/CD

When you want to run the same tests from multiple pipelines, for example Jenkins and Argo, and have all results in one place, you install the open source agent and automate workflow execution with the CLI or API. A webhook can push results into a tool such as Datadog at the end. This is the decoupled testing pattern, and it is also the main remedy for pipeline sprawl.

GitOps and progressive delivery

For asynchronous validation after a GitOps reconciliation, or continuous validation during a canary rollout, you install the agent and use test triggers on resource updates. You can also automate the CLI through GitOps mechanics, such as an Argo CD post-sync hook or an Argo Rollouts analysis step, then scrape execution metrics from the Testkube Prometheus endpoint.

Infrastructure testing

Because Testkube runs inside the cluster and is itself a Kubernetes component, it is well suited to low-level infrastructure tests. Platform teams use it to validate a cluster before handing it to an application team, or to run continuous checks as cluster components and network policies change. Real examples include validating that provisioned GPU resources are adequate for AI workloads, checking network endpoints, and confirming that components such as PostgreSQL, Redis, and Kafka are configured correctly. The workflow marketplace ships ready-to-use validations for many of these, and you can contribute your own.

Open source vs commercial: which is for you?

Testkube open source is a single-cluster test execution framework. Testkube commercial is a multi-cluster test orchestration platform for scaling testing across an enterprise. Both run on the same open source agent, so the core engine is identical. The commercial layer adds the orchestration, visibility, and governance that larger organizations need.

A common path is to start small with open source on a single cluster, then move to commercial as the team grows, runs more tests, and needs features such as multi-cluster orchestration, RBAC, or SSO. If you want to evaluate the core engine, open source is a good place to begin, since it is the same agent the commercial control plane uses.

How to get started

The open source project is primarily MIT licensed and free to run. To try it:

1. Install the CLI with Homebrew or another package manager.
2. Deploy the open source agent into your cluster with the CLI or a Helm chart.
3. Define a test workflow as a CRD, apply it, and run it with testkube run.
4. Retrieve logs and artifacts through the CLI or the REST API.

The Testkube repository on GitHub includes a contributor guide, an architecture guide, and a development guide, along with a Tilt setup that redeploys your changes automatically as you work on the agent. Recent open source improvements include input and output parameters between workflows, execution timeouts, PostgreSQL support, and the new workflow marketplace.

Key takeaways

• Testkube open source runs your tests inside Kubernetes. It is a Kubernetes-native framework that executes any containerized test in your own clusters, using the tools you already run.
• It complements CI/CD instead of replacing it. Teams keep Jenkins, GitHub Actions, or GitLab and use Testkube to run the tests those pipelines trigger, with all results in one place.
• You do not rewrite your tests. Testkube is an execution engine, not a testing tool, so your Playwright, k6, Cypress, and Postman tests run as they are.
• Test workflows, triggers, and webhooks are Kubernetes CRDs. That makes test execution GitOps-friendly and well suited to infrastructure testing and progressive delivery.
• Open source and commercial share one engine. Open source covers single-cluster execution; commercial adds a dashboard, multi-cluster orchestration, analytics, access control, and AI on top of the same agent.

Frequently asked questions