Skip to main content

Frequently Asked Questions (FAQs)

Can I use Okteto with Minikube?

Yes. Okteto accelerates your development workflow regardless of where your Kubernetes cluster is running.

If you can run kubectl apply, you can benefit from Okteto.

For Minikube, k3s, or similar local Kubernetes distributions, you can directly use our open source project. For shared remote clusters, we recommend to install Okteto Enterprise to handle credential management, namespace isolation, or custom application catalogs, among other things.

Why is Okteto better than traditional development?

Among the many advantages, Okteto allows developers to:

  • Reduce local setup and eliminate integration issues by developing the same way your application runs in production
  • Test your application as fast as you type code, without needing to use docker or kubectl in your inner loop cycle
  • No more CPU cycles wasted in your machine. Hardware and network just limited by the power of the cloud
  • Your development endpoints are always available. No need to expose your local machine to the internet through remote tunnels

How is Okteto different from other tools like Skaffold?

Skaffold automates the workflow for building, pushing, and deploying your application. You iterate on your application source code locally and then deploy to local or remote Kubernetes clusters.

Okteto's philosophy is to move development entirely to Kubernetes. The Skaffold pipeline, even though automated, is still slow. With Okteto, you code locally in your favorite IDE and Okteto automatically synchronizes your changes to your remote development environment. No commit, build, push, or deploy required.

The main differences from tools like Skaffold are:

  • Okteto decouples deployment from development. You can deploy your application with kubectl, Helm, a serverless framework or even a CI job and use Okteto later to develop any component of your application
  • Use any docker image as your remote development environment, with your favorite tools. Okteto doesn't require you to change the way you build, debug, or deploy your applications. Since builds are executed in your remote development environment, you benefit from fast incremental builds, hot reloaders, or the dependency caching offered by your programming language. Native builds are always faster than building images and redeploying containers
  • You can integrate Okteto with your local IDE remote plugins, making it possible to execute your favorite IDE extensions and debuggers as you develop your application directly in Kubernetes
  • Okteto provides bidirectional synchronization. For example, you can execute package managers like npm or pip in your remote development environment and the changes are synchronized back to your local file system

Is Okteto compatible with Flux/ArgoCD?

Okteto decouples deployment from development, making it possible to use it with tools like Flux or ArgoCD.

We recommend you to stop the Flux/ArgoCD reconciliation loop while running okteto up. For example, add this field to your Okteto Manifest to stop the Flux reconciliation loop:

annotations: "true"

How to use private images?

In order to use your private registry credentials you must configure a pull secret and use it in your Kubernetes manifests.

Alternatively, follow these steps if you want to configure your private registry credentials for your default service account:

  • First, create a docker-registry secret with your registry credentials:
$ kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

More information on how to create docker-registry secrets is available here.

  • Update your service account to automatically inject the registry secret when deploying resources in the namespace:
$ kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "regcred"}]}'

If your resources use a different serviceAccountName, replace default with that value in the command above.

With this configuration, all the deployments, stateful sets, jobs, and development containers launched in your namespace will automatically use your registry credentials when pulling private images.

Every time I make a change, tsc detects two changes:

This is related to how syncthing interacts with tsc. Syncthing creates a temporary file and replaces the original file with the new one.

To solve the problem you just add the flag --synchronousWatchDirectory to your tsc command.