Okteto: Kubernetes Inner-Loop Development
One of the few CDE platforms you can still run inside your own Kubernetes cluster - as long as you understand which half of it is open source
The CLI and the platform are two different products. This page separates them, as of July 2026
What It Is
Okteto is a Kubernetes-native development platform. Its original and still strongest idea is that the inner development loop should happen against a real cluster rather than a local imitation of one. Rather than mocking dependencies on a laptop, a developer's code runs in a container inside the cluster, alongside the real services, real databases, and real configuration it will eventually ship next to.
The mechanism is a command called okteto up. It scales the target deployment to zero and creates a mirror deployment in its place - a copy of the original workload with development-time changes applied, inheriting the same service account, environment variables, secrets, volumes, and sidecars. A bidirectional file synchronization service then keeps your local filesystem and that remote container in step, and port forwarding is set up automatically. You edit locally and the process runs remotely, in the cluster, with the cluster's identity.
The positioning has shifted noticeably. Okteto's homepage now leads with agentic development rather than with human developer productivity, describing the product as an environment platform where "every agent task gets an isolated, production-like environment on your infrastructure," and promoting an AI Agent Environments beta for running fleets of agents. The underlying engineering claim is the same one it always made - realistic environments beat mocked ones - now aimed at a workload that needs a great many short-lived environments rather than one per developer.
Who It Suits, and Who It Does Not
A Good Fit
- Teams already running Kubernetes in production whose applications are too interconnected to reproduce faithfully on a laptop.
- Microservice estates where "run the whole system locally" stopped being realistic several services ago.
- Organizations that need many short-lived preview or agent environments and want them provisioned on their own infrastructure.
- Buyers who specifically want the control plane inside their own cluster rather than in a vendor's account.
- Small teams testing the water - the free tier genuinely covers five seats.
A Poor Fit
- Anyone not running Kubernetes. This is a hard architectural dependency, not a gap waiting to be filled - see the limitation below.
- Teams needing VM-shaped or bare-metal workspaces for kernel work, mobile toolchains, or licensed desktop software.
- Buyers who assumed "open source" meant they could run the full platform for free forever. They cannot; see the license section.
- Procurement processes that require a published price before a conversation. Only the free tier has a number attached.
- Teams wanting a full browser IDE experience as the primary interface - Okteto's strength is the local editor plus remote runtime, not a hosted workspace desktop.
Deployment Model
This is where Okteto is most often described incorrectly, so it is worth stating carefully. The Okteto Platform is distributed as a Helm chart that you install into your own Kubernetes cluster. The control plane and the workloads both live in your cluster, on your nodes, in your cloud account. In that sense it is genuinely self-hosted, and that is a real and increasingly rare property in this market.
But self-hosted is not the same as free, and it is not the same as open source. The Helm chart installs the commercial product, and it requires a license key. Okteto's self-hosted documentation states plainly that you receive a license key as part of your subscription, and the Helm values include a required license field. There is no configuration in which you install the full platform from open-source components and operate it indefinitely without a commercial relationship.
What the chart brings with it is a full stack rather than a single service: the documentation lists an ingress controller, the Okteto API, a BuildKit build service, the frontend, a migration component, a container registry, and a validation webhook. That is the operational surface you are taking on. It is a coherent, well-documented bundle, but it is not a small one, and it wants a Kubernetes team behind it.
| Component | Who Operates It | Notes |
|---|---|---|
| Okteto Platform (Helm chart) | You | API, frontend, BuildKit, registry, ingress, webhook - all inside your cluster |
| Kubernetes cluster and nodes | You | Okteto does not supply compute - you bring the cluster and pay your cloud provider |
| Development containers | You | Ordinary pods in your own namespaces |
| License key issuance | Okteto | Required even for the free evaluation - this is the commercial dependency |
| Anything in the serving path | You | Under the self-hosted install, no Okteto-operated component sits between your developers and their environments |
License and Open Source Reality
Okteto is frequently listed as an open-source CDE. That is true of one component and misleading about the product. The okteto/okteto repository is licensed Apache-2.0, and it contains the CLI. It does not contain the platform.
The project's own README draws the line explicitly, describing two different things under one name. The Okteto Open Source CLI requires access to a Kubernetes cluster and supports only the dev section of the Okteto manifest, exposing three commands: okteto context, okteto up, and okteto down. Support is community-based. The Okteto Platform CLI requires the Helm chart to be installed in your cluster and unlocks the rest - build, deploy, destroy, the build service, user management and access control, automated scaling, the secrets manager, and observability - with commercial support available.
So the accurate statement is this: the open-source part is a thin client, and the part you self-host is commercial. Both facts are true at once, and the two are routinely collapsed into one another by comparison articles.
Is the open edition production-viable on its own? For an individual developer who already has cluster access and wants the remote inner loop, yes - okteto up and okteto down deliver the core experience. As a platform for an organization, no. Everything an organization needs from a CDE - who may create environments, what quotas apply, how they are audited, how images are built centrally, how they are cleaned up - lives on the commercial side.
| Capability | Open Source CLI (Apache-2.0) | Okteto Platform (commercial) |
|---|---|---|
| Remote dev container with file sync | Yes | Yes |
| Manifest coverage | The dev section only | Full manifest |
| Build and deploy commands | No | Yes |
| User management and access control | No | Yes |
| Secrets manager and observability | No | Yes |
| License key required | No | Yes |
Pricing
As of July 2026, okteto.com/pricing lists three tiers, and only one of them has a number on it.
Starter
Free, 5 seats
Published as free for up to five seats as of July 2026, with no credit card required and no contact-sales step.
Scale
Not published
Contact sales. No seat count and no price are published as of July 2026.
Enterprise
Not published
Contact sales. No price published as of July 2026.
Clarify which free offer you are being given
The pricing page describes Starter as free for five seats with no stated expiry. The self-hosted documentation separately describes a free evaluation tier of five seats for one year. These are most likely two different offers rather than a contradiction, but the difference matters a great deal if you are planning to run the Helm chart, because one of the two descriptions is time-boxed and the other is not. Ask which one a quote covers, and ask what happens at the end of the term.
As with any self-hosted platform, the subscription is not the total. You are also paying your cloud provider for the nodes the development containers run on, the storage they persist to, and the registry traffic. Okteto's sleep and quota controls exist precisely because that bill is the one that grows quietly.
Architecture and Isolation
The unit of isolation is the Kubernetes namespace. Okteto's documentation describes personal namespaces generated automatically for each user, named after the user, and private by default, so that you are the only person with access to your own namespaces. Isolation between them is enforced with RBAC roles and bindings, resource quotas and limits, and network policies, all managed by the platform rather than hand-written per developer. Administrators can additionally set per-namespace CPU, memory, storage, and pod quotas.
Be clear-eyed about what that means. This is namespace-level isolation on a shared cluster, not per-tenant kernel isolation. Pods on the same node share a kernel, so a container escape is a cross-tenant event unless you have added a stronger runtime or node-level separation yourself. For most internal engineering organizations that is an acceptable and normal trade. For hostile multi-tenancy, or for regulated work where a shared kernel is disqualifying, it is a design constraint you need to price in and address at the cluster layer.
The runtime behavior is the mirror-deployment model described earlier: the original workload is scaled to zero and replaced by a development copy that keeps the same service account, environment variables, secrets, volumes, and sidecars. Files sync bidirectionally between your machine and that container, and ports are forwarded over SSH. Okteto's own status command surfaces Syncthing links for troubleshooting the synchronization service, which is a useful thing to know when sync misbehaves on a large repository.
The architectural limitation follows directly. Because okteto up works by mirroring a Kubernetes Deployment object, there is no path to a non-Kubernetes target. There is no VM mode and no bare-metal mode. If your development environments need to be anything other than pods, this product cannot get you there, and no roadmap item would change that without redesigning the core mechanism.
Status and Durability
Okteto is a privately held, venture-backed company that is still shipping under its own name. The strongest evidence of health is release activity rather than press: CLI release v3.21.0 was published on 07-02-2026, and the project's README describes a monthly release cadence across stable, beta, and dev channels. The pricing, documentation, and product pages are all current, and the company has launched new product surface rather than merely maintaining the old one.
One honest caveat on the corporate picture: continued shipping is evidence of activity, not proof of independence. No acquisition or shutdown announcement was found during this review, but a targeted funding-and-ownership check is worth doing yourself if that fact will carry weight in your decision. This site does not assert corporate status it has not verified against a primary source.
The strategic risk to weigh is direction rather than survival. Okteto has repositioned around agentic development, and the homepage now sells agent environments first. That is a reasonable read of where spending is going, and it is genuinely adjacent to the existing engineering - the same isolated, production-like environments serve both audiences. But if you are buying Okteto purely for the human inner loop on Kubernetes, understand that you are now a secondary audience for the roadmap, and ask directly how the classic developer workflow is resourced.
Your exit position is better than average but not unconditional. The Apache-2.0 CLI is yours permanently and the mirror-deployment workflow would keep working against any cluster. The platform is not: it runs on a license key you renew. Practically, what you own on the way out is Kubernetes manifests, container images, and a registry - all portable artifacts - while what you would lose is the management layer around them. That is a recoverable position, but budget real time for rebuilding the governance layer if you ever leave.
Related Reading
Other vendors in this directory, and the wider selection question
Coder vs Okteto
Where the developer machine lives against how the code runs - two different questions
Self-Hosted vs Managed
What a license key in your own cluster does and does not buy you
Coder
The comparison to make if you need VM or bare-metal workspaces rather than pods
Eclipse Che
The other Kubernetes-native option, and the one where the whole platform is open source
DevPod
A client-only alternative with no license key and no control plane at all
Kubernetes Development
Developing against a real cluster, and where the inner loop actually breaks down
Open Source CDEs
Which parts of each product are actually open, and which parts only look it
CDE Tools Comparison
Every platform side by side, with dated pricing
Ephemeral Environments
Short-lived preview and agent environments, and what they cost to run well
Vendor Evaluation
How to pin down what a vendor means by "self-hosted" before you sign
Sources
Every figure on this site, with its publisher, date, and link