When using kubernetes with minkube locally, what is best practice for a development environment?

When using docker, in development I have mounted a volume with the source code, so I can modify code and see the changes in real-time without rebuilding the image. In production I bake the app code into the image for obvious reasons.

What do people do when using k8s/minikube for development. Same idea? Mount a volume pointing to where the app code lives on the host machine so they don't have to push images? If so isn't editing the deployment image the main way the pods update?

  • 2
    Hi Aaron, you can look into skaffold.dev Commented Jul 17, 2021 at 21:47
  • This looks promising too.
    – Aaron
    Commented Jul 18, 2021 at 11:21

3 Answers 3


It's really up to your personal preference, but for minikube you can certainly follow the same standards that you would for production.

If your production environment will use some sort of volume mount for your application code, then follow that same workflow for local dev and just have a pod running that mounts to your local code.

If your production environment expects that application code inside of the container, then set up a local registry in minikube, and build/push images into that registry.


I'm looking at tilt, and so far it's awesome for this.


I would say the reason you are wanting to develop against Kubernetes locally is to see how the application works with within the pod, and how it interacts with other dependencies inside the Kubernetes instance.

In this case you want to go for speed of getting the code into the container. Here you want something like Tilt Live Update which will run your build of your code locally, and then sync it into the running container. This avoids needing to build a container and deploy a new resource each time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.