SerpApi.Org
There’s no shortage of AI extensions for VS Code, whether you need something like Claude Code, Copilot, or Supermaven. I use many of these extensions every day, and there’s no doubt they’re helpful, but they’re not my favorite VS Code feature. That title goes to Dev Containers.
This feature allows me to run every project inside its own container, with the correct language versions, dependencies, extensions, and tools already configured. It also keeps my main system clean, prevents projects from breaking each other, and lets me recreate an entire development environment from a configuration file. I think that’s a more useful VS Code upgrade than adding another AI assistant.
Every project left something behind
And that piles up over time
VS Code makes switching between projects easy, but the underlying development environments still share the same computer. One project might require a particular version of Node.js, while another needs Python, system libraries, command-line tools, or a local database. The editor keeps the workspaces separate, but everything outside those folders can quickly become tangled.
I tried handling this through virtual environments, version managers, and project-specific configuration files. These tools helped, but they only covered parts of the setup. A Python virtual environment isolates packages, for example, but it doesn’t install the required interpreter or system libraries. Node version managers solve the runtime problem, but every project can still depend on globally installed tools and other software running on the machine.
The problems appeared when I returned to an older project. A package had been updated, a global tool was missing, or I could no longer remember which combination of commands had originally made everything work.
Over time, my system collected runtimes, packages, databases, and utilities from projects I wasn’t even using anymore. Removing them was risky because I couldn’t always tell whether another project still depended on them. I wanted every project to carry its development environment with it, so I could open the folder and get the same tools without rebuilding the setup manually. That’s the problem Dev Containers finally solved for me.
I gave each project its own development environment
Setup was easier than I thought
Setting up a dev container is easier than I initially expected, especially because VS Code handles most of the Docker work. You need Docker running on your computer and the Dev Containers extension installed in VS Code. Once you open a project, you can launch the Command Palette and select Dev Containers: Add Dev Container Configuration Files. VS Code then lets you choose a predefined configuration for environments such as Node.js, Python, Java, Go, or several other development stacks.
You can select the language version you need and add optional tools through Dev Container Features. VS Code creates a .devcontainer folder inside the project, with a devcontainer.json file controlling the environment. This file can point to a prebuilt container image or use an existing Dockerfile or Docker Compose configuration. It can also define the extensions VS Code should install, the ports it should forward, the commands it should run after creating the container, and additional tools the project requires.
Once the configuration is ready, you run Dev Containers: Reopen in Container from the Command Palette. VS Code reloads the window, downloads or builds the required image, starts the container, and connects the project to it. The first build takes some time because Docker needs to download the image and install everything, but subsequent launches are quicker as long as the container already exists.
The experience inside VS Code is identical to a normal workflow. I can edit files, open the integrated terminal, run the project, use IntelliSense, and start the debugger as usual. The important differences are that the terminal, runtime, dependencies, and project-specific extensions now operate inside the container.
Dev Containers still come with tradeoffs
There are performance issues you can't avoid
Dev Containers add another layer to the development process, and that layer isn’t free. Docker consumes memory, processing power, and storage, while its images and stopped containers can accumulate surprisingly quickly. Projects that bind-mount files from the main system can also encounter slower disk performance on Windows and macOS, especially when they contain thousands of dependencies or frequently changing files. For a small script or a simple project that already runs fine on my system, creating a separate container can require more effort than the project deserves.
Some projects also need additional configuration before everything works properly. You don't always have things like hardware access, graphical applications, and services running outside the container automatically. For example, a database, backend, and frontend might require multiple containers managed through Docker Compose, which makes the configuration more complicated.
VS Code is still the IDE I use
There has been an influx of code editors recently, many of them based on VS Code itself but with a few modifications and extras added here and there. I have experimented with all of them, but my daily driver is still VS Code. I’m not a fan of all the telemetry Microsoft adds, but VS Code offers by far the most complete experience.
