WSL Development Setup

Windows + WSL Architecture

When you run a development server inside WSL (Windows Subsystem for Linux), it binds to the WSL virtual network adapter — not your Windows host. This means localhost in Windows and localhost in WSL are different network contexts.

FlareDeck runs as a native Windows application and spawns cloudflared on the Windows side. To tunnel traffic to a service inside WSL, the ingress rule needs to target the WSL instance's IP address rather than localhost.

How FlareDeck Handles WSL

FlareDeck can automatically detect and rewrite service addresses for WSL:

1. When you specify a service like http://localhost:3000, FlareDeck detects if the target port is only reachable inside WSL.
2. It resolves the WSL instance's IP address (typically something like 172.x.x.x).
3. The generated config uses the WSL IP so cloudflared can reach the service.

This happens transparently — you configure localhost in the UI, and FlareDeck handles the IP translation.

Setting Up Services in WSL

A typical workflow looks like this:

# Inside WSL terminal
cd ~/my-project
npm run dev -- --host 0.0.0.0 --port 3000

Common Patterns

React/Vite dev server in WSL

# WSL
vite --host 0.0.0.0 --port 5173

FlareDeck ingress: http://localhost:5173

Node.js API server in WSL

# WSL
node server.js  # listening on 0.0.0.0:8080

FlareDeck ingress: http://localhost:8080

Database in WSL

# WSL — PostgreSQL listening on default port
sudo service postgresql start

FlareDeck ingress: tcp://localhost:5432 (for TCP tunnels)