Skip to main content
Version: 1.47

Known Issues

Development environments do not hot-reload code changes​

If you are using a hot reloader in your development environment, it might happen that your hot reloader does not pick the code changes even when they are properly synchronized to your development environment.

This is usually because the default max watchers value on your Kubernetes nodes is too low. To fix this issue, update the value of /proc/sys/fs/inotify/max_user_watches in all your Kubernetes nodes (we recommend the value 10048576).

For example, you can do it by running this command on each node:

$ sudo sysctl -w fs.inotify.max_user_watches=10048576

Okteto uses a Daemon Set to apply this change automatically to every Kubernetes node.

The okteto prompt doesn't look right in Windows​

Okteto's remote prompt uses ANSI escape sequences to display the namespace and development environment name in different colors.

If you're using PowerShell and the terminal looks funky, this feature might not enabled. Run the command below to enable ANSI Color globally:

Set-ItemProperty HKCU:\Console VirtualTerminalLevel -Type DWORD 1

This stackoverflow answer has more information on this topic.

Pulling an image fails with an EOF error​

Image pulls run on the Kubernetes node, not on your machine, so a pull can fail for any pod the cluster schedules. During okteto up, the failure surfaces as a Development Container that won't activate:

couldn't activate your development container
    Failed to pull image "node:25-alpine3.22": failed to pull and unpack image "docker.io/library/node:25-alpine3.22": failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://production.cloudfront.docker.com/...": EOF

The EOF means the connection to the host in the error closed before the image layer finished downloading. The usual cause is an egress policy on the cluster — a firewall, proxy, or domain allowlist — that doesn't permit that host. Registries commonly serve manifests from one host and redirect layer downloads to a separate CDN or storage host, and those hosts change over time, so an allowlist scoped to the registry alone starts failing on layer downloads while the manifest still resolves.

Docker Hub is the most common case. It serves manifests from registry-1.docker.io (after authenticating against auth.docker.io) and redirects layers to a CDN host. Docker added the CDN domain production.cloudfront.docker.com in May 2026, so allowlists that only covered the registry and an older CDN began failing with this error.

To resolve it:

  1. Allow egress from your cluster to your registry's hosts over HTTPS, including the CDN or storage host it redirects layer downloads to. Because these hosts can change, prefer wildcards where your firewall supports them. For Docker Hub, allow *.docker.io and *.docker.com; Docker's allowlist reference lists the current hosts, including registry-1.docker.io, auth.docker.io, and production.cloudfront.docker.com.
  2. If a TLS-inspecting proxy sits in front of the cluster, trust the certificate authority that signs the registry and CDN hosts. Docker Hub's CloudFront CDN uses Amazon Trust Services, for example, so its certificates fail validation when your trust store only includes a previous CA.
  3. Mirror the image in the Okteto Registry or another registry your cluster can reach, and reference it with the image field in your Okteto Manifest.