Real tests, in a real environment, in seconds.
Okteto Test runs your unit, integration and end-to-end suites inside a production-like Kubernetes environment, so developers and coding agents prove every change against real services before they open a pull request.
Runs in your cluster. Nothing to install but the Okteto CLI.
Your tests run in the wrong place.
Agents write code faster than ever. But if the only place to test it is a laptop or a CI queue, every change waits, or ships unverified.
Option 1
On a laptop or a fat VM
Compose stacks drift from production and mocks hide integration bugs. Agents need a privileged VM each, with dockerd and every credential inside.
Option 2
In CI, after the push
A separate platform with its own config. Every fix is a commit, a queue and a wait, so agents end up guessing instead of checking their own work against anything real.
Best option
In the environment the code runs in
Okteto Test runs your suites as containers inside the same Kubernetes namespace as your application, with direct access to every service.
Agents should prove their work, not guess.
Okteto keeps the agent's sandbox small and moves everything heavy into the application environment. The agent runs one command and gets real results back.
A tiny sandbox, a complete environment.
The agent only needs the source code, the Okteto CLI and a token. Builds, deploys and tests run in your cluster.
No privileges, no infrastructure credentials.
No dockerd, no nested virtualization. Okteto injects secrets at test time and masks them in the logs, so the agent never sees them.
Feedback in seconds, not CI cycles.
Code syncs into the test container and caches persist between runs, so the agent can test, fix and test again in one session.
Results the agent can act on.
Exit codes, logs and artifacts like Playwright reports come straight back to the agent, or to your developer.
How Okteto Test works.
Step 1
Define your tests
Add a test section to your okteto.yaml with the image to use, the folder to sync, the caches to keep between runs and the commands to run.
Step 2
Deploy the environment
okteto deploy brings up the full application in its own namespace, from the Helm charts, manifests or Compose files you already have.
Step 3
Run okteto test
Each test container runs inside the namespace and reaches your services by their internal names. No port-forwards, no exposed endpoints.
Step 4
Get results back
Pass or fail, logs and artifacts like Playwright reports sync back to the developer or agent that ran the tests. No waiting on a CI run to know what broke.
What makes Okteto Test different.
Inside the cluster network
Tests reach private APIs, databases and queues directly, with lower latency and no extra networking to set up.
One definition for everyone
The same test section runs for developers, coding agents and CI, in the same kind of environment.
Fast by default
Persistent caches skip reinstalling dependencies, and smart builds reuse images that someone already built.
Secrets stay in the cluster
Variables are injected only while tests run and masked in the logs. Nothing sensitive lives in the agent's sandbox.
Trusted by platform teams
"Developers love Okteto. They liked that they could click a button and arrive at the specially created feature branch for that specific problem. And they could test it before it went to stage, and even write end to end or integration tests."
"With Okteto, you can test code before it's merged and QA can catch issues and bugs right away - that saves time and money by avoiding building on a shaky foundation and reworking your code down the road."
Preview environments
Run the same tests on every pull request, then share a live URL for review.
Questions before you get started
Unit, integration and end-to-end tests, with any framework that runs in a container: Jest, Pytest, Go test, Playwright, Cypress and more. Each test container uses the image you choose.
No. Your CI keeps orchestrating, and calls Okteto to deploy and test in a real environment. That way development, CI and production all run on Kubernetes, and tests behave the same everywhere.
With the Okteto skill, agents like Claude Code, Codex, Cursor and Copilot deploy an environment, run okteto test and read the results from their own sandbox, before they open a pull request. See how Okteto works with coding agents.
No. Point a test container at the folder with your tests and list the commands you already run. Follow the getting started guide.
Yes. Okteto runs in your own cloud account (BYOC) or on your own Kubernetes clusters (Self-Hosted). Your code, images, environments and test data never leave your infrastructure.
Under BYOC, Okteto operates only a monitoring and control plane, and it holds no customer data and no PII. Okteto is SOC 2 Type 2 audited and pen-tested every year.
Self-Hosted is free for up to 5 users, and a trial covers up to 100 users for a month. For a team rollout, the fastest path is a 30-minute call with an Okteto engineer to scope a pilot around your stack.