When I began my development journey, with a very limited knowledge base, I had two key considerations I wanted to fulfil: to gain hands-on experience of maintaining a Linux environment because Linux is used throughout production environments, and to ensure I had good system security for my computer because I would inevitably be invoking other people’s code.
As it turned out my hybrid approach of using Windows Subsystem for Linux (WSL2) met those requirements, whilst allowing me to keep the familiar Windows OS I have been using for years - I did setup a dual-boot environment on my old laptop, experimenting and customizing Linux Mint.
WSL2 allows the best of both OS worlds; I can continue to use software that Linux currently doesn’t handle i.e. the Adobe suite, keep Windows as my native OS, have a degree of interoperability that a full virtual-machine doesn’t, and also get the security benefits of a more isolated development environment.
Why Linux Debian Trixie?
Initially I used the WSL2 Ubuntu distro from the Microsoft store, not knowing anything about the strengths and weaknesses of the different distributions. On my journey I have gone through upgrading one major version of Ubuntu, to switching over to Debian Bookworm, and then manually upgrading to Debian Trixie;
Eager to get Trixie running, before Microsoft added it to their store, I got the image tar on the day of release from debian.org; built the rootfs, keyring, updated, passed it over to WSL to import, assigned package sources, users and permissions, ssh/sshd, docker rootless, and all the other configuration and useful packages I’ve picked up on my journey so far.
Debian is very stable, more minimal than Ubuntu, and not the masochistic headache that Arch would give an amateur. Along with stability it prioritizes reliability, which is perfect from a security standpoint - this month (June 2026) Arch User Repository suffered a massive supply-chain attack! Not much more to say other than for myself, Debian was the only logical choice.
Why WSL2?
In conjunction with the introductory paragraph of reasons, WSL2 gives a consistent shell environment so OS toolchains can remain largely isolated to their respective OS. I also felt it would be easier for a total beginner to setup isolation practices e.g. not mounting the local drives in the Debian instance via wsl.conf, then setting proper users/permissions so only root can mount/unmount drives, than going for a full virtual-machine setup with its overhead and configuration. Using WSL2 also seemed like a useful skill to have.
All my project data lives on an external ext4 formatted drive, rather than within the WSL2 VHDX itself, giving portability and acting as a backup. It also makes permissions easier to deal with keeping everything Linux side than going between Windows and Linux. I also devised a system involving shell scripts to backup my distro and project data once a month to other devices for safe keeping.
The Windows 10 Terminal also allows you to easily spin up multiple distros with WSL2, along with other things like PowerShell and Windows CMD, which makes for a nice developer experience too.
Why VSCode on Windows?
VSCode is free, constantly maintained and evolving, and for a beginner the inevitable choice given virtually all tutorials work with it. But why on Windows, and not within WSL2? Initially it was just pure preference, knowing it would be easier to debug setup issues in Windows than potentially dealing with Linux issues on top that. Second, it was a chance to experiment with utilizing SSH, connecting from VSCode to the WSL2 Debian instance. From a security standpoint the line gets a bit blurred with VSCode extensions, however my curated list only involves well-known, well-established extensions so the risk is minimized from that vector. The UI remains Windows side, and the VSCode Server runs Linux side along with the majority of the extensions.
Why Docker Rootless?
In conjunction with WSL2, Docker could be setup solely inside the Debian instance - Docker Desktop for Windows has issues and using it would also break my desire for environment isolation. The key security consideration was enabling ‘Rootless’ mode, which avoids running Docker daemon as Root in order to limit the blast radius of potential container escaping malicious code. This did provide some headache moments - Iptables issue related to the way WSL2 distros handle things behind the scenes - but I was able to get it working successfully in the end, and it gave me more exposure to deeper Linux configuration.
Closing Thoughts
My setup is intentionally opinionated, and certainly not the simplest for a total beginner to setup. But I had confidence in my own ability to figure it all out, and I knew it would be worthwhile to take the approach I did. And it has paid off in respect to both of the initial considerations I listed; Linux experience and security.
Over time I have become very familiar with the Linux system, developed a nice toolchain and configuration for my productivity, and the result is a workflow setup that feels productive and predictable, and also allows for the continuing expansion of skills in Linux itself.
With all the NPM and other supply chain attacks it is also satisfying that I took the time to ensure personal security from the outset and that my initial concerns about invoking others code was a correct hunch.
Top comments (0)