# Okteto: running your dev loop inside the Kubernetes pod

> The Okteto open source CLI swaps a running deployment for a development container, syncs your local files into it, and skips the docker build and redeploy cycle. Here is what it does, how to install it, and where it stops.

**okteto/okteto** — Develop your applications directly in your Kubernetes Cluster

- Repository: https://github.com/okteto/okteto
- Website: https://okteto.com
- Stars: 3,549 · Forks: 318
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/okteto-okteto

## The problem Okteto targets: the build and redeploy loop

The README opens with a plain observation. Kubernetes made deploying to the cloud easy, but development practices did not move at the same speed. The workflows it describes are the ones most teams fall into: run part of the stack locally, push integration testing into CI jobs, or repeat the docker build and redeploy cycle for every change. Each of those adds minutes to a loop a developer wants to run dozens of times an hour.

Okteto's answer is to stop rebuilding images during development. You write code on your laptop, the CLI detects the change, and the running Kubernetes application updates. The target user is a developer on a team that already has a cluster and a deployment manifest, and who is willing to trade local reproducibility for the cluster's hardware, network and configuration. It is not aimed at someone who has never deployed to Kubernetes, because the tool assumes a workload already exists there to attach to.

## What okteto up actually replaces in the cluster

The mechanism is a swap. When you run okteto up, according to the README, your Kubernetes deployment is replaced by a Development Container that carries your development tools, whether that is maven and a JDK, or npm, python, a Go compiler or a debugger. That container can be built from any docker image, and it inherits the secrets, configmaps, volumes and other configuration values of the deployment it replaced.

File movement is handled by a synchronization process rather than an image build. The repository Dockerfile pins syncthing 2.1.3 as the synchronization component, alongside a set of tools built from source in the tools/ directory (named remote, supervisor and clean in the build stage). The README describes the result as a remote cluster that your IDE and tools see as a local filesystem and environment. Save a file, the change lands in the development container, and whatever hot-reload mechanism your application already has takes over. No image is created and no manifest is applied.

That last point is the interesting design choice. Because the deployment is replaced rather than patched, the state of your cluster during development is not the state of your production manifest. The CLI keeps the original around so okteto down can restore it, but anything that reads the live deployment while you are in development mode will see the development container instead.

## Installing the Okteto CLI and running a first session

The README points to the install page rather than printing commands, so the exact package manager invocation is not documented there. What it does state is that all you need is the Okteto CLI and access to a Kubernetes cluster, and that the CLI is available for macOS, Linux and Windows. The Makefile shows how the project builds its own binaries: go build with CGO_ENABLED=0 and static tags, producing artifacts named okteto-Linux-x86_64, okteto-Darwin-arm64 and okteto.exe. If you build from source, that is the target you get.

Once the binary is on your PATH, the open source CLI exposes three commands, and the first one points it at a cluster:

```bash
okteto context
```

The README lists okteto context as the command that establishes which Kubernetes cluster and namespace subsequent commands use. Run it before anything else, and check that the namespace it selects is a development namespace, not one running production workloads.

With a context set, the command that starts the development container is:

```bash
okteto up
```

According to the README, this replaces the deployment with the development container, starts the file synchronization, and leaves your local editor talking to the remote environment. The manifest that drives it lives in an okteto.yml file at the repository root of the project, and the open source CLI reads only the dev section of that manifest. The samples/ directory in the repository carries getting started guides for ASP.NET, Golang, Java Gradle, Java Maven, Node.js, PHP, Python and Ruby, each with its own README.

To tear the session down and restore the original deployment, the third command is:

```bash
okteto down
```

The README does not document what happens to in-flight synchronization when down is interrupted, so treat that command as the one you want to complete cleanly.

## The open source CLI is a subset, and the manifest tells you so

The most consequential limitation is stated in a note in the README: the open source version of Okteto supports only the dev section of the Okteto manifest. Everything else in that file is inert unless you are on the commercial platform. The feature comparison table makes the split concrete. Development Containers are available in both. The Build Service and User Management are marked Not Available for the open source CLI.

The command list follows from that. The open source CLI supports okteto context, okteto up and okteto down. The platform CLI adds build, deploy, destroy and the rest, and requires the Okteto Helm Chart installed in your cluster, plus the identity provider integration, the build service, preview environments per pull request and the secrets manager.

So the honest framing is that this repository is the client half of a product. If your workflow needs okteto build to create images remotely, or okteto deploy to apply manifests, the open source binary will not do it. You can still deploy with kubectl or Helm and then attach with okteto up, which is exactly the deployment-independent workflow the README recommends. That path works, but it means your CI and your local loop use different tools, and the manifest you maintain for Okteto is a partial one.

## Alternatives and where the approach differs

Tilt and DevSpace are the two comparisons people search for most often alongside Okteto, and the difference is not cosmetic. Tilt is built around a live-update and build orchestration model: it watches your manifests, builds images, and applies targeted updates to running containers. That means it owns part of your build pipeline and expects to know how your images are produced. Okteto's open source CLI takes the opposite stance. It does not build anything. It replaces the deployment with a development container and syncs files, which is why the README can call it deployment independent.

Telepresence attacks a different layer again. It intercepts traffic and routes selected requests from a remote cluster to a process running on your laptop, so your local process participates in the cluster's network. Okteto does not run your code locally at all. Your code runs in the cluster, and your laptop supplies the files and the editor. If your problem is that a local process cannot reach cluster-internal services, Telepresence addresses it directly and Okteto does not.

DevSpace sits closer to Okteto in that it also synchronizes files into a pod and gives you a terminal inside it, but it bundles deployment and image building into the same tool rather than splitting them across an open source CLI and a hosted platform. The practical question is whether you want one tool that does build, deploy and sync, or a small client that only does sync and leaves deployment to whatever you already use.

## Maintenance, licensing and what a version bump costs

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: 3.23.1 on 2026-09-08, a 3.23.1-beta.1 the same day, and 3.23.0 on 2026-09-02. The project is written in Go, and go.mod declares go 1.26.6 with Kubernetes client libraries at v0.36.3 and Docker CLI at v29.7.2. That dependency surface is the upgrade cost. A bump to the Kubernetes client libraries, the Docker CLI or the buildkit module is a bump to four moving targets at once, and the go.mod carries a comment noting that updating go-containerregistry requires a specific google.golang.org/grpc version. Expect to spend time on transitive dependency alignment, not on the CLI's own code.

On licensing, the project is Apache-2.0, and the LICENSE file sits at the repository root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. Nothing in the README describes how the open source CLI and the commercial platform are licensed relative to each other, so if your organisation needs to know whether the split creates any obligation, that is a question for your own counsel rather than something the README answers.

## Conclusion

Adopt Okteto if your team already deploys to Kubernetes and the docker build, push and redeploy loop is the slowest part of the day. Skip it if you need the build, deploy and preview environment commands, since the open source CLI exposes only context, up and down and reads only the dev section of the manifest. Before rolling it out, run okteto context use against a non-production namespace and confirm that okteto up leaves your original deployment recoverable through okteto down.

## FAQ

### What is Okteto?

Okteto is a CLI that accelerates the development workflow of Kubernetes applications. When you run okteto up, it replaces your Kubernetes deployment with a development container that inherits the deployment's secrets, configmaps and volumes, and syncs your local code into it.

### How do I use Okteto?

Install the Okteto CLI, point it at a cluster with okteto context, then run okteto up to start the development container and file synchronization. okteto down restores the original deployment. The open source CLI supports only those three commands.

### Is Okteto free?

The README describes an open source CLI under Apache-2.0 that supports only the dev section of the Okteto manifest, and a separate commercial Okteto Platform that requires the Okteto Helm Chart and adds the build service, user management and preview environments. The README does not list prices for the platform.

### How does Okteto compare with Tilt?

Tilt watches manifests, builds images and applies live updates to running containers, so it participates in your build pipeline. The Okteto open source CLI does not build anything: it replaces the deployment with a development container and synchronizes files, which is why the README describes it as deployment independent.

### How does Okteto compare with Telepresence?

Telepresence routes traffic from a remote cluster to a process running on your laptop, so your local process joins the cluster network. Okteto runs your code inside the cluster and uses your laptop for files and the editor, so it does not solve local-to-cluster connectivity.

### Does Okteto work with VS Code?

The README states that Okteto provides IDE and tool integration so the remote cluster appears to your IDE as a local filesystem and environment, and that you keep writing code in your local IDE. It does not name specific editor extensions or list a VS Code setup.

## Sources

- [License: Apache-2.0](https://github.com/okteto/okteto/blob/master/LICENSE)
- [okteto/okteto on GitHub](https://github.com/okteto/okteto)
- [Project website](https://okteto.com)
- [README](https://github.com/okteto/okteto/blob/master/README.md)
- [Releases](https://github.com/okteto/okteto/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/okteto-okteto