Skip to content
Mike Evans-Larah By Mike Evans-Larah Software Engineer III
Supercharge Your Dev Containers on Windows

For developers on Windows, the speed of VS Code Dev Containers is often limited by a hidden bottleneck: filesystem I/O. When your source code resides on the Windows filesystem, Docker must use a slow network-based protocol to mount it into the container environment running within the Windows Subsystem for Linux (WSL). This can cripple the performance of I/O-heavy tasks.

As an example, we were recently working on a Python project that involved a data transformation pipeline with numerous dependencies. We adopted Dev Containers to ensure a consistent development environment and smooth onboarding for new developers. However, there were many I/O intensive operations involved, such as:

  • installing dependencies (using poetry and later uv)
  • running a large suite of data processing tests
  • or even just using Git operations

Due to this, using the Dev Container felt sluggish, with operations taking several times longer than they should have.

The solution is simple yet incredibly effective: clone your repository directly inside the WSL filesystem. By doing so, Docker can use a native, high-speed bind mount, completely bypassing the cross-operating-system performance penalty. This simple change can make your devcontainer feel as responsive and fast as a native Linux machine, dramatically accelerating your development workflow, especially for large projects or those with numerous dependencies.

Let's look at how you can make this performance boost a reality.

Step 1: Set up a WSL Distro

Firstly, you'll need a Windows Subsystem for Linux (WSL) distribution installed. Ubuntu is a popular and well-supported choice. If you don't have one, it's straightforward to set up.

Open PowerShell or Command Prompt as an administrator and run:

wsl --install

This command will install the default Ubuntu distribution. On first start, you'll be prompted to create a username and password for your new Linux environment.

If you already have WSL, you can check your installed distros with:

wsl --list --verbose

SCREENSHOT: wsl --list --verbose command output

Step 2: Ensure WSL Integration is Enabled for Docker Desktop

For Docker to seamlessly interact with your WSL distro, you need to ensure that WSL integration is enabled in Docker Desktop.

Open Docker Desktop settings. Navigate to Resources > WSL Integration. Make sure the toggle for your specific WSL distro (e.g., Ubuntu) is enabled.

SCREENSHOT: Docker Desktop settings showing WSL Integration enabled for a specific distro

Note:
Whilst Docker Desktop is the most commonly used tool today, there is a growing trend toward open alternatives such as Podman and Rancher Desktop. These tools also support WSL integration, though the setup steps differ.
Rancher Desktop has a similar process - navigate to Preferences > WSL Integration and enable the integration for your desired WSL distro.
Podman is a bit more involved - see the docs for Accessing Podman from another WSL distribution for details.

Step 3: Clone Your Repository into the WSL Filesystem

This is the crucial step! Instead of cloning your Git repository to a Windows drive (like C:\Users\<YourUsername>\Repos), you'll clone it directly into your WSL filesystem.

Note:
If you normally use Git Credential Manager to authenticate with your git repos, see Git Credential Manager setup for WSL before cloning your repository.

Open your WSL terminal (e.g., by typing wsl in Command Prompt or searching for Ubuntu in the Start Menu). Navigate to your desired location, for example, your home directory or a repos folder you create.

cd ~
mkdir repos
cd repos

Now, clone your repository. For example:

git clone https://github.com/<your-org>/<your-repo>.git

Why this matters: When your code lives within the WSL filesystem (e.g., /home/<yourusername>/repos/<your-repo>), Docker can use highly efficient bind mounts. If it were on your Windows drive (/mnt/c/Users/<yourusername>/repos/<your-repo>), Docker would have to rely on less efficient network protocols, slowing things down significantly.

Step 4: Open the Repository in VS Code

Once your repository is cloned into WSL, you can open it directly from your WSL terminal using VS Code's remote development capabilities.

Note:
You will need to have Visual Studio Code installed on your Windows machine, along with the necessary extensions for working with WSL and Dev Containers (Remote - WSL and Dev Containers - or install the Remote Development Extension Pack).

In the terminal, navigate into your cloned repository's directory:

cd <your-repo>

Then, simply type:

code .

This command will launch VS Code on your Windows desktop, but it will automatically connect to the WSL environment and open the folder within it. You'll notice an indicator in the bottom-left corner of VS Code, showing that you are connected to WSL: Ubuntu (or your distro name).

SCREENSHOT: VS Code connected to WSL, showing the indicator in the bottom-left

Step 5: Reopen in Container

With your repository open in VS Code via WSL, and Docker Desktop configured, you're ready to launch your Dev Container (we're assuming your repository already has a .devcontainer folder set up with the necessary configuration files).

Click the blue indicator in the bottom-left corner of VS Code, and select "Reopen in Container" from the command palette. Alternatively, you can press Ctrl+Shift+P to open the command palette and type "Reopen in Container".

GIF: Demonstrating opening the command palette and selecting "Reopen in Container"

VS Code will now build (if necessary) and connect to your Dev Container. Because your source code is already within the WSL filesystem, Docker will use a native bind mount, and you should experience significantly faster performance for all I/O-intensive operations within your Dev Container.

Experience the Speed!

You've now successfully set up your Dev Container environment for optimal performance on Windows. Tasks like uv sync, npm install, dotnet build, or large Git operations will feel dramatically snappier. This simple change can improve your development workflow, making your Dev Container feel as responsive as if you were working directly on a native Linux machine.


Important Considerations

While setting up your Dev Container with WSL for optimal performance is straightforward, there are a few important considerations and best practices to keep in mind to ensure a smooth development experience.

Git and Line Endings (CRLF vs. LF)

One common source of frustration when mixing Windows and Linux environments (like WSL) with Git is line ending inconsistencies.

  • The Problem: Windows typically uses CRLF (Carriage Return + Line Feed) for line endings, while Linux (and therefore WSL and Docker containers) uses LF (Line Feed). If not handled correctly, Git can report numerous "changes" to files just because of differing line endings, especially when collaborators are on different operating systems.

  • Best Practice: .gitattributes: The most robust solution is to use a .gitattributes file in the root of your repository. This file allows you to define how Git should handle line endings for different file types. For most text files, the recommended setting is:

    * text=auto eol=lf
    

    This tells Git to automatically handle text file conversions but to enforce LF line endings when committing to the repository. This ensures consistency across all environments and prevents spurious line ending changes.

Accessing Files from Windows

While you should primarily interact with your code via VS Code connected to WSL, there might be times you need to access files from the Windows side.

  • Access via File Explorer Your WSL filesystems are accessible from Windows via a network path. The simplest way to navigate to the filesystems is from File Explorer using the 'Linux' shortcut in the left-hand pane. From there, you can navigate to your Ubuntu (or other distro) filesystem and then to your cloned repository.

  • Warning: Avoid modifying files with Windows apps: It is important to avoid modifying files located within the WSL filesystem using Windows applications other than VS Code (with the Remote - WSL extension). Directly opening and saving files from the Linux filesystem with applications like Notepad, Visual Studio (non-Code), or other Windows-native IDEs can corrupt file permissions and metadata within the Linux filesystem. This can lead to broken builds, permissions errors, and other unpredictable behavior. Always use VS Code connected to WSL or your Dev Container, or perform file operations directly within the WSL terminal.

The Introduction to Rx.NET 2nd Edition (2024) Book, by Ian Griffiths & Lee Campbell, is now available to download for FREE.

If you want another detailed a step-by-step guide, Carmel Eve has recorded Dev Containers: The ULTIMATE Python & Streamlit Dev Setup (VS Code).

Mike Evans-Larah

Software Engineer III

Mike Evans-Larah

Mike is a Software Engineer at endjin with over a decade of experience in solving business problems with technology. He has worked on a wide range of projects for clients across industries such as financial services, recruitment, and retail, with a strong focus on Azure technologies.