Most of us have dealt with Node.js version conflicts at some point:
- One project needs Node 18.
- Another needs Node 20.
- A global upgrade breaks something.
- Corporate or restricted laptops don’t allow installers.
- CI/CD behaves differently from local environments.
- Teammates run “slightly different” versions and bugs magically appear.
On Linux/macOS, tools like nvm, asdf, volta, and fnm help…
But on Windows, especially without admin rights, things get messy.
So I started experimenting with a simple idea:
What if every project had its own Node.js runtime, completely local, portable, and isolated?
Just like Python has .venv.
That experiment grew into a small open-source tool called nenv.
🚀 nenv — Portable Node.js per project (Windows)
nenv is a lightweight script that downloads Node.js directly into your project folder and makes all Node/npm commands use that local runtime — even if no global Node is installed on the system.
It's basically:
node.exe + npm + npx
... stored inside the project
So project A can use Node 18
and project B can use Node 20
with zero conflict.
📂 Example Project Structure
After initializing:
project/
│ nenv.cmd
│ .nenv-version
└── .nenv/
├── cache/
│ └── node-v18.20.0-win-x64.zip
└── node-v18.20.0-win-x64/
├── node.exe
├── npm.cmd
├── npx.cmd
└── all Node core files
Everything stays inside your project.
Nothing touches your system installation.
📦 Installation
Run this inside your project root:
Invoke-WebRequest -Uri "https://cdn.jsdelivr.net/gh/tabreezsajjad/nenv@v0.5.0/nenv.txt" -OutFile "nenv.cmd"
Initialize:
.\nenv.cmd init
Enter the Node version you want (e.g., 20.11.1).
nenv downloads the ZIP from the official Node.js site and sets it up inside .nenv/.
🧪 Usage
Check Node version:
.\nenv.cmd node --version
Install dependencies:
.\nenv.cmd npm install
Run scripts:
.\nenv.cmd dev
.\nenv.cmd build
.\nenv.cmd start
These behave exactly like:
npm run dev
npm run build
npm run start
but always using the project-local Node runtime.
✔ Supported Versions
nenv supports any official Node.js Windows x64 ZIP:
- 14.x (legacy)
- 16.x (legacy)
- 18.x (LTS)
- 20.x (LTS)
- 22.x (Current)
- 24.x (Latest)
💡 Why this approach?
- No admin rights needed
- No global Node installation required
- Fully self-contained environments
- Perfect for Windows developers
- Great for corporate/restricted laptops
- Reproducible environments across teams
- CI/CD matches local dev
One project’s Node version never affects another
🔗 GitHub Repo
https://github.com/tabreezsajjad/nenv
The project is still early, but it works reliably and I’d love feedback, feature requests, or edge cases to test.
🙏 Thanks for reading!
If you try it out, I’d love to hear how it works for your workflow — especially if you're on Windows or dealing with Node version chaos across multiple projects.
Top comments (0)