How To Enable WSL and Use It as a Server on Windows

Running Linux on Windows with WSL (Windows Subsystem for Linux) is handy for development, testing, and even hosting small services. Many people want to enable WSL and use it like a server: hosting web apps, APIs, databases, or internal tools, all from a Windows machine.

This guide walks through how that works, what to expect, and the main variables that shape your own setup.

What Is WSL and How Can It Act as a Server?

WSL is a feature in Windows that lets you run a Linux environment without a virtual machine or separate hardware. You can install Linux distributions like Ubuntu, Debian, or Fedora directly from the Microsoft Store and run them alongside your Windows apps.

When you “use WSL as a server,” you’re typically doing things like:

• Running a web server (Nginx, Apache, Caddy)
• Hosting application servers (Node.js, Python/Flask/Django, Ruby, PHP-FPM, .NET on Linux)
• Running databases (PostgreSQL, MySQL/MariaDB, Redis for development)
• Providing local network services (internal APIs, test environments)

In WSL, these services run inside the Linux environment, but they can often be reached:

• From Windows itself (localhost access)
• From other devices on your local network (with some networking configuration)
• Through port forwarding or reverse proxies from the internet (if you set that up securely)

WSL behaves a bit like a lightweight VM, but with tight Windows integration, which affects how you enable it and how networking works.

Step-by-Step: How To Enable WSL on Windows

The exact steps differ slightly between Windows 10 and Windows 11, and between WSL 1 and WSL 2. For most people today, WSL 2 is the better choice because it gives you:

• A real Linux kernel
• Better compatibility
• More “Linux-like” networking and file system behavior

1. Check Your Windows Version

WSL works best on Windows 10 (newer builds) and Windows 11.

You can check your version:

1. Press Win + R
2. Type winver and press Enter
3. Note the edition and build number

Newer versions have the wsl --install command, which simplifies everything.

2. Enable WSL Using PowerShell

Open PowerShell as Administrator:

• Press Start, search for PowerShell
• Right-click Windows PowerShell (or Windows Terminal) → Run as administrator

Then run:

wsl --install 

This usually does three things:

• Enables Windows Subsystem for Linux
• Enables Virtual Machine Platform (needed for WSL 2)
• Installs a default Linux distro (often Ubuntu)

If the simple command isn’t available or fails, you can enable features manually:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 

Then restart your PC.

3. Install a Linux Distribution

On modern Windows builds, wsl --install may already install Ubuntu. If not:

1. Open the Microsoft Store
2. Search for a distro: Ubuntu, Debian, Kali Linux, etc.
3. Click Get / Install
4. After install, launch it from Start (it will initialize on first run)

The first time you open your Linux distro:

• You’ll be asked to create a UNIX username and password
• This is your Linux user, separate from your Windows account

4. Check and Set WSL Version

To see your WSL version:

wsl -l -v 

If you see WSL 1 and want WSL 2:

wsl --set-version <DistroName> 2 

For example:

wsl --set-version Ubuntu 2 

You can also make WSL 2 the default:

wsl --set-default-version 2 

Now you have a Linux environment ready to run server software.

Running a Server Inside WSL

Once WSL is installed, open your distro and you’re in a Linux shell. From here, hosting a service feels similar to any regular Linux server.

1. Update Packages

Inside your WSL terminal (e.g., Ubuntu):

sudo apt update sudo apt upgrade 

2. Install a Web Server (Example: Nginx)

sudo apt install nginx 

Start Nginx:

sudo service nginx start 

On many WSL setups, you can now open a browser in Windows and go to:

http://localhost 

You should see the default Nginx page, proving WSL is serving content.

3. Run an App Server (Example: Simple Python App)

Inside WSL:

sudo apt install python3-pip pip3 install flask 

Create a file app.py:

from flask import Flask app = Flask(__name__) @app.route("/") def home(): return "Hello from WSL!" if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) 

Run it:

python3 app.py 

Then in Windows:

http://localhost:5000 

Now WSL is acting as an application server, reachable from your Windows browser.

Networking: Accessing WSL Services as a “Server”

How WSL networking behaves depends on whether you use WSL 1 or WSL 2.

WSL 1 vs WSL 2 for Server Use

For many server-style uses, WSL 2 is preferred, but the network differences matter.

1. Access from Windows (Localhost)

On current Windows builds, services running in WSL 2 that listen on 0.0.0.0 or localhost are usually accessible from Windows at:

http://localhost:<port> 

Examples:

• Nginx on port 80 → http://localhost
• Flask app on port 5000 → http://localhost:5000

If it doesn’t work, common checks:

• Is the service running inside WSL?
• Is it listening on 0.0.0.0 rather than only 127.0.0.1 in some configs?
• Is Windows Firewall blocking the port?

2. Access from Other Devices on Your Network

This is what many people mean by “use WSL as a server”: they want a phone, tablet, or another PC on the LAN to reach that service.

Here it gets more nuanced:

• WSL 1: Shares the same IP as Windows. If a server listens on 0.0.0.0 inside WSL 1, other devices can often reach it via your Windows machine’s IP (e.g., http://192.168.1.50:5000), assuming firewall rules allow it.
• WSL 2: Runs in a small virtual machine with its own IP. Windows and WSL talk through virtualization networking. Other devices on the LAN see only the Windows host, not the WSL IP directly.

On WSL 2, you usually handle this by:

• Binding services to 0.0.0.0 in WSL
• Creating port forwarding rules on Windows so that traffic to your Windows IP is forwarded to WSL
• Or using a reverse proxy on Windows (IIS, Caddy, Nginx on Windows) that proxies requests to WSL

One simple approach uses netsh (run in an elevated PowerShell or CMD):

netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=<WSL_IP> 

You can get the WSL IP inside the distro:

ip addr 

Once forwarding is configured correctly and firewall rules allow inbound traffic, devices on your network can use your Windows machine’s IP:

http://192.168.x.x:5000 

Where 192.168.x.x is your Windows host’s local IP.

Security and Stability When Using WSL as a Server

WSL is great for development and testing. Some people also use it for light internal services. But there are some factors to be aware of before treating it like a full-blown production server.

Key Considerations

• Firewall and Exposure
  • Windows Firewall controls the ports visible on your network.
  • If you forward ports or open them, you should know who can reach them and from where.
• Updates and Restarts
  • Windows updates and restarts will interrupt WSL.
  • WSL doesn’t boot like a long-running server; it starts when you open it or a service triggers it.
• Service Autostart
  • By default, services inside WSL are not always set to start automatically when Windows boots.
  • You may need custom scripts, systemd (where enabled), or scheduled tasks on Windows to restart WSL services.

Types of Loads WSL Is Best For

WSL shines for:

• Development environments (web dev stacks, API backends, dev databases)
• Personal tools (internal dashboards, home lab experiments)
• Testing Linux-specific behavior from a Windows workstation

Heavier, always-on, critical workloads are usually better on dedicated Linux servers, cloud VMs, or full hypervisors, where resource allocation and uptime are more predictable.

Variables That Change How You Should Use WSL as a Server

There isn’t one “correct” way to use WSL as a server. Several variables heavily influence what makes sense.

1. Hardware and Performance

• CPU and cores: More cores help if you’re running multiple services (web + DB + queues).
• RAM: WSL 2 is a lightweight VM; it still uses memory. Running many services can be demanding on low-RAM machines.
• Disk type and speed:
  • SSDs improve performance for databases, web frameworks, and file-heavy operations.
  • Where you store your code/data (WSL’s Linux filesystem vs. Windows filesystem) significantly changes speed.

2. Windows Version and WSL Features

• Older Windows 10 builds have more workarounds needed for networking and install.
• Newer builds and Windows 11 make wsl --install and localhost access smoother.
• Features like systemd support for WSL (on recent versions) change how you manage services and autostart.

3. Type of Server Workload

What you’re hosting affects your setup:

• Static websites / simple apps
  • Often simple: Nginx or a Node/Python app exposed over a single port.
• Full stacks (web + DB + cache)
  • You might use Docker inside WSL, or install each component manually.
• Databases for development
  • Fine in WSL for most local dev needs, but configuration, persistence, and backup matter if you rely on them.

4. Network Environment

• Home network vs corporate network
  • Corporate policies, VPNs, and firewalls can block or limit inbound connections.
• Need for outside access
  • If you want internet access to your server, you need router port forwarding, DNS, TLS certificates, and strong security practices.
• Local-only use
  • If only your Windows machine needs access, setup is easier: mostly just localhost.

5. Your Comfort Level With Linux and Windows Admin

• If you’re comfortable with Linux, setting up Nginx, systemd services, and firewall rules inside WSL is straightforward.
• If you’re more Windows-centric, you might prefer:
  • Simpler dev-only servers
  • Or using WSL for the app, but handling network-facing parts on Windows

Different User Profiles, Different WSL Server Setups

To see how these variables play out, here are a few typical profiles.

1. Web Developer on a Laptop

• Goal: Run local copies of websites and APIs.
• Likely setup:
  • WSL 2 with Ubuntu
  • Nginx or a dev web server (Node/Python/Ruby)
  • Databases (PostgreSQL, MySQL) for dev only
  • Access via localhost in the browser
• Networking: Typically doesn’t expose WSL to other devices; keeps everything on the laptop.

2. Home Lab Enthusiast

• Goal: Host dashboards, small services, or a personal wiki that other home devices can access.
• Likely setup:
  • WSL 2 on a desktop or always-on mini PC
  • One or more web apps inside WSL
  • Port forwarding from Windows IP to WSL services
  • Possibly a reverse proxy to group services behind one domain or port
• Networking: Accessible from other devices on the LAN, but usually not from the public internet.

3. Corporate User or Student on Managed Device

• Goal: Run dev environments without changing corporate servers.
• Likely setup:
  • WSL 2 (if allowed) for Linux-specific tools and containers
  • Services available on localhost only
  • Limited ability to open inbound ports due to IT policies
• Networking: Constrained by organizational rules; external access often not allowed.

Where Your Own Setup Becomes the Missing Piece

The mechanics of enabling WSL and running servers inside it are fairly consistent: turn on the feature, install a distro, install server software, and configure networking. The part that changes from person to person is how far you take it and how you expose it.

Your:

• Windows version and update level
• Hardware and how heavily you plan to load it
• Need for LAN or internet access to your services
• Network environment (home, school, work)
• Comfort level with Linux, Windows Firewall, port forwarding, and security

will all shape whether WSL is just a convenient local dev box, a modest home server reachable by a few devices, or something more complex.

Understanding the building blocks lets you see what’s possible; mapping them to your own hardware, network, and risk tolerance is the step that determines how you’ll actually enable WSL and use it as your server.