Okteto CLI: Development Containers Inside an Existing Kubernetes Deployment
Develop your applications directly in your Kubernetes Cluster
At a glance
- What is it?
- The open source Okteto CLI replaces a running Kubernetes deployment with a development container that inherits its config, so you edit locally and the cluster updates on save. It is a narrow tool: three commands, one manifest section, and a commercial product waiting on the other side of that boundary.
- Who is it for?
- Adopt the open source Okteto CLI if you already run a real deployment in a cluster and want a single developer to edit code against it without rebuilding images. Do not adopt it if you need remote builds, per-pull-request environments, or team-level access control: the README states those live in the Okteto Platform, which requires the Okteto Helm chart.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is the build and redeploy cycle, not Kubernetes itself
The README frames the problem in one sentence: most developers either run parts of the infrastructure locally or test integrations in the cluster through CI jobs or the docker build and redeploy cycle. It calls that workflow painful and slow. The point is not that Kubernetes is hard to deploy to. It is that the loop between saving a file and seeing the change in a cluster has too many steps.
Okteto targets the developer who already has a working deployment in a Kubernetes cluster and wants to iterate on it. The README describes the audience as cloud-native developers, and the getting started guides cover ASP.NET, Golang, Java with Gradle, Java with Maven, Node.js, PHP, Python and Ruby. That list matters: these are languages with hot-reload or fast native build tooling, which is what makes the save-and-see loop short once the code is already on the cluster.
It is not a tool for someone who has never deployed the application. The README's own precondition is access to a Kubernetes cluster, and the development container is described as replacing an existing Kubernetes deployment. Without a deployment to replace, `okteto up` has nothing to work from.
How okteto up swaps a deployment for a development container
The mechanism is a substitution, not a sidecar. When you run `okteto up`, according to the README, your Kubernetes deployment is replaced by a Development Container that contains your development tools: maven and jdk, or npm, python, a Go compiler, debuggers. That container can use any docker image, and the README points at the development images documentation for the available set.
The part that makes this more than a remote shell is inheritance. The README states the development container inherits the same secrets, configmaps, volumes or any other configuration value of the original Kubernetes deployment. So the environment variables your service reads, the mounted secrets it authenticates with, and the sidecars it talks to are the ones from the real deployment. That is the difference between developing against a realistic environment and developing against a laptop approximation of one.
The data flow runs in one direction. You keep writing code in your local IDE. On save, the change goes to the development container, and the application updates using whatever hot-reload mechanism you already have. The README is explicit that no docker images need to be created and no Kubernetes manifests need to be applied during this loop. The remote cluster is presented to your IDE and tools as a local filesystem and environment.
One architectural consequence deserves attention. Because the deployment is replaced, the original workload is not running its normal image while you develop. If that deployment is shared, you are occupying it.
Three commands and a manifest section: the open source boundary
The README lists exactly three supported commands for the open source CLI: `okteto context`, `okteto up`, and `okteto down`. A note states that the open source version only supports the dev section of the Okteto manifest, and points readers to the Okteto Platform for additional features.
That is a small surface, and it is worth being precise about what it excludes. The feature comparison table in the README marks the build service and user management as not available in the open source CLI and available in the Platform. The Platform CLI requires the Okteto Helm chart to be installed in your cluster, and the README lists what comes with it: authentication and access control through your identity provider, a build service for remote container image creation, integrations with GitHub, GitLab and Bitbucket, preview environments per pull request, dynamic scaling of environments based on usage, a secrets manager, and Okteto Insights for observability.
The comparison table in the supplied material is truncated partway through the user management row, so the remaining rows cannot be confirmed from what is available here. What can be confirmed is the direction: the open source CLI is the development-container half of the product, and the operational half sits behind the Helm chart.
Getting it running: install, context, up, down
The README's getting started path has two prerequisites: install the Okteto CLI and have access to a Kubernetes cluster. It links to its own install documentation and to a guide for setting up a cluster on AWS EKS.
The first command is `okteto context`. The README does not spell out its flags or its output, so the exact configuration it writes cannot be confirmed from the supplied material. What is clear from the command's presence in the three-command list is that it establishes which cluster and namespace subsequent commands act on.
The development loop is `okteto up`. It reads the Okteto manifest, and per the note in the README, the open source CLI only honors the dev section of that manifest. The manifest reference is linked from the README rather than reproduced in it, so the individual keys under dev are not available here and should be read from that reference before writing one.
Teardown is `okteto down`, which restores the original deployment in place of the development container.
If you want a worked example rather than the reference, the repository carries sample directories for each supported language: samples/aspnetcore, samples/golang, samples/java-gradle, samples/java-maven, samples/node.js, samples/php, samples/python and samples/ruby, each with its own README. Those are the concrete starting points the project provides. The README does not state which Kubernetes versions or which languages beyond that list are supported.
Where the substitution model breaks down
The deployment replacement is the design's main constraint. Because `okteto up` replaces the deployment rather than adding to it, the environment you are developing in is the environment that was serving traffic. On a cluster where that deployment is shared with other developers or with a staging consumer, the model does not hold. The README's own framing points the reader toward the Okteto Platform for teams that want to share a cluster for development, which is an acknowledgment that the single-deployment substitution is a per-developer arrangement.
There is a second limitation in the open source boundary itself. Without the build service, image creation is not part of this tool. The README's advantage list treats native builds inside the development container as the fast path, so this may not matter for languages where the compiler or interpreter is already in the image. It matters when your inner loop requires producing a container image.
A third is that the manifest surface is restricted. If your workflow depends on anything outside the dev section, the note in the README says plainly that the open source version does not support it. The supplied material does not enumerate failure behavior when a manifest contains unsupported sections, so whether that is an error or a silent ignore cannot be determined here.
Finally, the development container needs resources of its own: a pod, a volume for the synced code, and network access to the cluster. The README does not publish minimum requirements, so cluster policy is something to check rather than assume.
Skaffold and Telepresence solve adjacent parts of the same loop
Skaffold is the closest comparison for the build half. It watches source, rebuilds a container image, and deploys it, which means the artifact under test is a real image produced by a real build. Okteto's approach is the inverse: the README states no docker images need to be created and no manifests applied during the inner loop, because the code is synced into a container that is already running. If your correctness depends on the image build itself, Skaffold's model is the one that exercises it. If your build is slow and your hot-reload is good, Okteto's model removes the build from the loop entirely.
Telepresence takes a different route again: rather than replacing the deployment in the cluster, it intercepts traffic so a process running locally receives requests meant for a cluster service. The developer's code runs on the laptop, with cluster network access, instead of running in a container on the cluster. Okteto's README makes the opposite promise, that you get the hardware and network of the cluster and that dependencies need not be installed locally. Which of the two you want depends on whether the bottleneck is your machine's resources or the distance between your process and the cluster's services.
The choice is not about which tool is better. It is about where the code executes and whether the image build stays in the loop.
Licence, release cadence and what to verify before adopting
The repository is Apache-2.0 and the README carries the matching badge. That is a permissive licence, and it is the same licence covering the CLI itself rather than the commercial Platform, which the README describes as a separate product requiring the Okteto Helm chart. Nothing in the supplied material describes the Platform's licensing terms, so the split between the two should be read from the project's own documentation rather than inferred here. This is a description of the licence identifier, not legal advice.
On cadence, the release list shows 3.23.1 on 2026-09-08, a 3.23.1-beta.1 published the same day, and 3.23.0 on 2026-09-02. The pattern suggests a regular minor release rhythm with beta builds cut alongside. The repository is not archived and the last push date is 2026-09-10, two days after the latest release.
Upgrade cost is mostly the CLI binary itself, since the open source mode has no cluster-side component to maintain. That changes if you move to the Platform, where the Helm chart becomes something you operate.
What to verify first: that your target deployment's configuration can be expressed under the dev section of the Okteto manifest, since that is the only section the open source CLI reads; that the cluster allows the development container's pod and volume; and that the deployment you intend to replace is not one anyone else depends on while you work. Those three checks come before anything else in this article.
Editorial conclusion
Adopt the open source Okteto CLI if you already run a real deployment in a cluster and want a single developer to edit code against it without rebuilding images. Do not adopt it if you need remote builds, per-pull-request environments, or team-level access control: the README states those live in the Okteto Platform, which requires the Okteto Helm chart. Before committing, verify that your deployment's manifest can be represented under the dev section of the Okteto manifest, and that your cluster permits the extra pod and volume the development container needs.
Community notes