A surprising number of teams we consult for still debug broken Docker builds the same way they did five years ago: sprinkle RUN echo statements through the Dockerfile, rebuild, read the log, delete the echo, repeat. Docker Desktop 4.50 removes most of the excuse for that workflow — Docker Debug, previously gated behind a paid tier, is now free for every user, and it ships with real IDE integration instead of a bare CLI.
What's actually new
Docker Desktop 4.50's headline changes:
- Docker Debug is free for all users — no subscription required to drop an ephemeral shell into a running or crashed container
- Dockerfile debugger in the VS Code extension — step-through analysis of image builds, inspecting the filesystem state at each layer
- WSL2 stability and performance improvements on Windows, aimed at inconsistencies reported in larger enterprise environments
- Refined Compose-to-Kubernetes tooling, improving how local multi-service Compose setups translate into Kubernetes manifests
- Expanded MCP Toolkit — the MCP catalog now lists 270+ servers, over 60 of them remote with built-in OAuth (Notion, Linear, and similar)
The free Docker Debug change matters most for smaller teams. A step-through debugger you have to pay for tends to get used by one senior engineer and nobody else; a free one gets used by whoever hit the failing build at 4pm.
Debugging a build step by step
The practical difference is inspecting container state without polluting the Dockerfile with temporary instrumentation:
# Attach an ephemeral debug shell to a running container —
# busybox tools available even if the base image has none
docker debug my-broken-container
# Debug a specific build stage directly, without a running container
docker debug --target builder .Inside that shell you get a real toolset (ls, cat, ps, curl) even when the target image is a minimal distroless or scratch base that ships none of it. That's the case that used to force people into a throwaway FROM debian rebuild just to poke around.
Why the VS Code integration is the bigger deal
The CLI debugger existed before 4.50 in a more limited form. What's new is stepping through the build — not just the running container — directly in the editor, watching the filesystem diff at each RUN, COPY, and ADD instruction.
For a multi-stage build like this:
FROM node:22-slim AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]A build failing at npm run build used to mean re-running with --progress=plain and reading log output. With the VS Code debugger, you can step to the layer right before the failing RUN, inspect exactly what COPY . . actually copied, and confirm whether the problem is a missing file, a stale .dockerignore entry, or a genuine build script bug — without rebuilding the image again for each guess.
Compose-to-Kubernetes, still evolving
Docker's Compose-to-Kubernetes conversion tooling (branded as Kanvas in the broader Docker ecosystem) gets incremental refinement in 4.50 rather than a rewrite. If your team develops locally with docker-compose.yml and deploys to Kubernetes, it's worth re-running the conversion on your existing Compose files — past versions have had rough edges around resource limits and multi-network setups that this release specifically targets.
Our recommendation
Upgrade for the free Docug Debug alone if your team has ever burned an afternoon on a broken multi-stage build — that alone pays for the version bump. The VS Code integration is genuinely useful for anyone maintaining nontrivial Dockerfiles, not just people chasing esoteric bugs.
The MCP catalog expansion is a smaller story for most teams right now, but worth knowing about if you're already using Docker Desktop's MCP Toolkit to run local MCP servers for AI-agent workflows — the OAuth-backed remote servers reduce a real amount of credential-wiring boilerplate.
Sources: