Testkube

Visit Website

Introduction

Testkube describes itself as ‘the open testing platform for AI-driven engineering teams’. Its core idea is to run your existing tests and tools inside Kubernetes rather than in CI runners. You define how a test runs (which image, which command, which files) and Testkube schedules it as Kubernetes workloads, collects logs and artifacts, and stores results centrally.

The README lists four pillars. Run any tests: API, end-to-end, performance, security and infrastructure tests at scale. Trigger tests whenever needed: manually, on schedules, from CI/CD and GitOps pipelines, on Kubernetes events, through the REST API or through MCP. See everything: results, artifacts, logs and resource metrics in one place. Integrate natively through webhooks and other integrations.

Running tests in-cluster has practical benefits for testing services: tests can reach internal endpoints without exposing them, load tests can be distributed across nodes, and the same test definitions can be triggered from different CI systems. Test Workflows, defined as Kubernetes custom resources, describe multi-step and parallel runs.

There are two ways to run it. The open-source agent in the GitHub repository installs with Helm or the CLI and runs standalone. The commercial control plane adds one dashboard across unlimited clusters, Testkube AI for workflow generation, failure investigation and remediation pull requests, and enterprise features such as SSO, SCIM, RBAC and audit logs. The repository’s code is variously licensed under the MIT licence and the Testkube Community License.

Testkube has about 1,700 GitHub stars and is released frequently (2.15.0 on 29 October 2026). Its pricing page lists a free open-source option, and Pro pricing that starts at $700 a month for a single connected agent.

In the quality loop, Testkube sits in the release and CI gate stage as orchestration across API, end-to-end and performance tests. It suits platform teams that want testing to be a Kubernetes-native service rather than something each pipeline reinvents.

Testkube makes the most sense when tests already run as containers and the team operates Kubernetes confidently. Because tests execute inside the cluster, they can reach internal services without exposing them, and test runs can be triggered by events, schedules or CI jobs. The trade-off is operational: you are adding another control plane to maintain, and debugging failures may involve pods, logs and cluster permissions rather than just a CI console. A sensible pilot is to move one existing suite, such as a k6 load test or a Playwright smoke test, into a Testkube workflow and compare reliability and feedback time with your current pipeline before migrating more.

Features

1. Run any tool: Container-based execution for k6, Postman, Playwright, Cypress, JMeter and more.
2. Test Workflows: Kubernetes custom resources for multi-step and parallel runs.
3. Flexible triggers: Manual, schedules, CI/CD, GitOps, Kubernetes events, API and MCP.
4. Central results: Logs, artifacts and resource metrics in one place.
5. In-cluster access: Test internal services without exposing them.
6. Distributed load: Spread performance tests across nodes.
7. Webhooks: Notify other systems on test events.
8. CLI: Run and inspect tests from the terminal.
9. AI features: Commercial Testkube AI for analysis and remediation (vendor claim).
10. Enterprise controls: SSO, SCIM, RBAC and audit logs in the commercial plan.

Pros

1. Tool-agnostic: Keeps your existing tests and frameworks.
2. Decouples tests from CI: Same tests triggered from any pipeline.

Cons

1. Kubernetes required: Not useful without a cluster.
2. Mixed licensing: Parts of the code are under the Testkube Community License, not an OSI licence.
3. Commercial features: Multi-cluster dashboard and AI features need a paid plan.
4. Learning curve: Workflows and CRDs take time to learn.

Usage and Links (Example)

Install the CLI and the open-source agent:

brew install testkube
testkube init

A simple Test Workflow running a k6 script:

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: api-smoke
spec:
  content:
    files:
      - path: /data/smoke.js
        content: |
          import http from 'k6/http';
          import { check } from 'k6';
          export default function () {
            const res = http.get('http://my-api.default.svc/health');
            check(res, { 'status 200': (r) => r.status === 200 });
          }
  steps:
    - name: run k6
      run:
        image: grafana/k6:latest
        shell: k6 run /data/smoke.js

testkube run testworkflow api-smoke -f

Practical tips:

1. Start by moving one slow or network-restricted test (such as a load test) into Testkube.
2. Trigger workflows from CI with the CLI so pipelines stay thin.
3. Use Kubernetes event triggers to run smoke tests after deployments.

Resources:

• Testkube website
• GitHub repository

Pricing

Open-source agent available free. Pro plan from $700 a month for a single connected agent; Enterprise by quote. See site.

Recommended for?

1. Platform teams on Kubernetes that want a shared testing service.
2. Teams running load or API tests against internal services.
3. Not a fit without Kubernetes, or for small projects with simple CI.

Conclusion

Testkube turns Kubernetes into a test execution platform for the tools teams already use. Its open-source agent is a practical way to run tests close to services and trigger them from anywhere.

Check the licensing and which features need the commercial control plane before standardising on it.

On CheckOps, Testkube is filed under the API & contract testing, Release & CI gates and Performance & load stages. Related tools listed here include K6, Newman, Playwright, JMeter, Currents and Cypress. Before choosing, compare them on licence, supported languages and platforms, hosting model, and how well each fits your existing CI pipeline. Facts on this page were checked against the official website, documentation and repository on 11 November 2026; statements the vendor makes about its own product are marked as vendor claims.