Every developer has been there. You change a single line of code, push it to a branch, wait for the CI pipeline to build, test, and deploy – just to see if your fix actually works. Five minutes. Ten minutes. Sometimes more.
Multiply that by dozens of iterations a day, and you’ve got a serious bottleneck that’s silently eating your engineering velocity.
And if your application happens to depend on a beefy database, a mesh of micro-services, or a mountain of environment-specific configuration, walking down the aisle of developing locally brings a new pain-point to the table, the good old “works on my machine” loophole.
There has to be a better way. Spoiler: there is.
A real-world example of this comes from my client, where developers and QA teams were running 14 environments on a single manually-configured remote server, syncing files directly from their machines.
When we migrated to Kubernetes, Okteto let us preserve that familiar workflow while adding environment parity through GitOps, centralized configuration, and, for the first time, proper debugger and profiler support. The transition was smooth precisely because the experience felt the same, just faster and more stable.
Enter Okteto
Meet Okteto, a tool that falls under a category known as “Remocal Development” – the sweet spot between remote infrastructure and a local development experience.
At its core, the Okteto CLI is open source (Apache 2.0), while the full Okteto Platform offers additional paid features for teams and enterprises. In this article, we’ll focus on what you can do with the open-source CLI – which, frankly, is already quite powerful.
The idea is simple: you write code locally in your favorite IDE, and your changes are reflected instantly in a remote Kubernetes environment. No build. No push. No waiting on CI. Just code, save and receive instant feedback.
If your company already uses Kubernetes, adopting Okteto is practically a no-brainer.
How Does Okteto Actually Work?
If I were to boil Okteto down to one sentence: it replaces a running workload in your Kubernetes cluster with a Development Pod that syncs files from your local machine in real time.
When you run okteto up, this new Okteto-powered workload inherits the exact same configuration as the original – same environment variables, secrets, configmaps, volumes, and sidecars. The difference is that it now has bidirectional file synchronization between your local filesystem and the remote pod, powered by Syncthing under the hood.
All of this is configured through a single okteto.yaml manifest at the root of your project. Here’s a minimal example:
dev:
api:
command: bash
sync:
- .:/usr/src/app
forward:
- 8080:8080
- 9229:9229That’s it. You define the target workload, the directories to sync, and additional optional overrides. Simple, declarative, and version-controlled alongside your code.
Why Adopting Okteto is a Win?
I know what you might be thinking, “My app runs just fine locally, why do I need this?” Fair question. Here’s why adopting Okteto is still a win, even when local development works:
Production parity. Your development pod runs in a cluster, with a setup similar to your production workload. No more “works on my machine” surprises when you deploy. Okteto inherits the exact same configuration the original pod has, ideally managed through GitOps in a controlled and centralized manner, so what you develop against is as close as possible to what actually runs in production.
Standardized environments. Every developer on the team gets the same setup. No more spending half a day onboarding someone because their local Python version is different, or they’re missing some obscure system dependency. GitOps is the source of truth for the development environment, yet with the flexibility for overrides (like custom environment variables or image tags) that can be specified declaratively within the okteto.yaml manifest.
Remote debugging from your local IDE. This is where things get really interesting. Okteto sets up SSH-based reverse port forwarding between the remote pod and your local machine. By forwarding debugger ports (like 9229 for Node.js or 5005 for Java), you can set breakpoints in your local IDE that trigger on requests running inside the remote cluster. VS Code, IntelliJ, GoLand — they all work seamlessly. Your code is executing remotely, but your debugging experience is fully local.
Custom entrypoints and startup overrides. Dealing with a container that crashes on startup? Okteto lets you override the original entrypoint with a custom command — like dropping into a bash shell — so you can investigate, tweak, and iterate without fighting the deployment lifecycle.
Where Okteto is Your Game Changer
Now, let’s talk about the scenarios where Okteto isn’t just nice to have – it’s a game changer.
Applications with heavy dependencies. If your service depends on a large database, a message broker, or a dozen other microservices, replicating all of that locally is either impractical or impossible. Since Okteto runs inside your Kubernetes cluster, your application has native access to everything that’s already deployed there. No need to spin up a local Postgres with a subset of data or mock out half your architecture.
Slow CI feedback loops. If the only way to test a code change is to push it through a 10-minute (or longer) CI pipeline, your developers are spending more time waiting than coding. Okteto short-circuits this entirely, the feedback loop drops from minutes to seconds.
Complex configuration that’s impossible to replicate locally. Think service meshes, custom networking policies, specific cloud-provider integrations, or tightly coupled environment configurations. Some applications are simply not designed to run outside of Kubernetes. Instead of fighting that reality, Okteto leans into it.
Onboarding new developers. One of the most overlooked benefits: a new team member can install the Okteto CLI, run okteto up, and have a fully configured development environment connected to the cluster within minutes. No more week-long onboarding docs for setting up local dependencies.
Open Source vs. Platform
It’s worth noting that Okteto comes in two flavors. The open-source CLI (available on GitHub) supports the dev section of the okteto.yaml manifest — which covers everything we’ve discussed so far: development pods, file sync, port forwarding, and remote debugging. This is free and works with any Kubernetes cluster you have access to.
The Okteto Platform (their commercial offering) builds on top of this with features like preview environments on every pull request, a built-in build service, user authentication and RBAC, integration with GitHub/GitLab/Bitbucket, and a web dashboard for managing environments.
For the purpose of this article, and for what I implemented for my client, the open-source CLI was more than enough to make a significant impact on the development workflow.
Final Thoughts
Development workflows have lagged behind the speed at which we’ve adopted Kubernetes for deployment. We’ve mastered CI/CD, GitOps, and infrastructure-as-code — but the inner development loop? For many teams, it’s still painfully slow.
Okteto bridges that gap. It provides developers with a realistic, fast environment without requiring them to become Kubernetes experts. And for platform and DevOps engineers, it’s a tool that standardizes the development experience across the organization while keeping everything under the same infrastructure umbrella.
If you’re looking to tighten your team’s feedback loop and bring the development experience closer to production — Okteto is absolutely worth your attention.
