I built a venv-style environment manager for WSL2 — and benchmarked it honestly against Docker Desktop
I kept spinning up throwaway WSL distros by hand — `wsl --export`, `--import`, remember
which one belonged to which project, forget to clean up. So I wrote a CLI that treats a
WSL2 instance the way venv treats a Python environment: it belongs to the project
directory, one command creates it, one command destroys it.
cd my-project
lenv init
lenv run "ls -a"
lenv destroy
Config lives in .lenv/ next to your code. No daemon, no Dockerfile, no registry.
Because the obvious question is "why not Docker Desktop," I benchmarked it properly and
published the results including the parts where I lose:
- Warm command execution: `docker exec` beats `lenv run` by ~46ms. Docker's CLI is compiled
Go, mine is Python. That gap is structural.
- True throwaway (create → run → destroy): Docker wins by ~8x. `lenv init` costs ~2.8s.
- Cold restart of a stopped environment: tie.
- Idle RAM: Docker Desktop ~2.4GB working set. lenv's marginal cost over a machine that
already runs WSL2 is ~0.1GB.
- Disk: Docker Desktop install+data ~5.4GB. A lenv environment is ~100MB.
So it's not faster. It's lighter, and it doesn't leave anything running. If you're on a
16GB laptop and Docker Desktop's idle footprint annoys you, that's the pitch.
Benchmark with method and raw numbers: https://github.com/pranavpd24/lenv/blob/main/BENCHMARK.md
Repo: https://github.com/pranavpd24/lenv
pip install lenv-manager
Not a container engine — no image layers, no registry, no build. And not a security
sandbox: WSL2 distros share the host VM kernel.
https://i.redd.it/jys3m8m6p4ih1.gif
Happy to take criticism on the methodology, it's a single-machine benchmark.