Why I Built PortZero, a New Local Dev Proxy

The Problem

If you work on more than one microservice at a time, you know the drill. You spin up a frontend on :3000, an API on :8080, maybe a worker on :9090. You juggle ports, forget which service runs where, and when something breaks you have no idea what request caused it.

Your browser history is full of localhost:3000, localhost:3001, localhost:8080. You mix them up between projects. And if you need someone else to see your local work? Time to set up a tunnel.

I hit this problem daily. I tried the existing tools. Each solved part of it, but none solved all of it. So I built PortZero.

What I Was Using Before

Nginx / Caddy / Traefik

Great reverse proxies — for production. For local dev, they're overkill. You need config files, you need to manage them separately from your services, and they don't know anything about your dev processes. No traffic inspection, no process management, no hot-reload awareness. They're designed for deployed infrastructure, not for pnpm dev.

Ngrok

Ngrok is excellent at what it does: exposing local ports to the internet. But it's a tunnel, not a local dev environment tool. You still need to manage ports yourself, it doesn't give you stable local URLs across projects, and there's no built-in traffic inspection, mocking, or process management. It solves the "show this to a teammate" problem, not the "I have 5 services running locally" problem.

Portless (Vercel)

Portless tackles the same core problem: giving your local dev servers human-readable URLs instead of random port numbers. It's a CLI tool from the Vercel ecosystem that maps .local domains to your services.

Portless validated the problem — port juggling is real and developers hate it. But it's CLI-only with no visual dashboard, no traffic inspection, no request replay or mocking, and no process management. I wanted something that went further: not just stable URLs, but a full local dev companion that lets you see, debug, and simulate everything flowing through your services.

What PortZero Does Differently

PortZero is a single Rust binary that combines five things that usually require separate tools:

1. Reverse proxy — route <app>.localhost to your local ports, powered by Cloudflare Pingora
2. Process manager — spawn, monitor, and auto-restart your dev services with deterministic port assignment
3. Traffic inspector — capture every HTTP request and response with full headers and bodies, persisted to SQLite
4. Request replay & mocking — re-send captured requests with overrides, or create mock responses without hitting upstream
5. Network simulation — inject latency, packet loss, and bandwidth throttling per-app to test degraded conditions

Here's what it looks like in practice:

# Start your frontend — it gets http://web.localhost:1337
$ portzero web pnpm dev

# Start your API — it gets http://api.localhost:1337
$ portzero api cargo run

# See everything running
$ portzero list
  web   Running  http://web.localhost:1337  (pid 12345)
  api   Running  http://api.localhost:1337  (pid 12346)

# Tail logs from your API
$ portzero logs api -f

No config files. No port numbers to remember. Just names.

Why Rust?

A dev proxy sits in the hot path of every HTTP request you make during development. It needs to be fast enough that you forget it's there. Rust gives us that — sub-millisecond proxy overhead — plus a single static binary with no runtime dependencies.

We built on top of Cloudflare Pingora, the same proxy framework that handles a significant chunk of internet traffic at Cloudflare. It gives us HTTP/1, HTTP/2, and WebSocket support out of the box, with battle-tested connection pooling and TLS.

The Desktop App

One thing that sets PortZero apart is the native desktop app, built with Tauri v2. While the CLI gives you full control, the desktop app makes traffic inspection and mocking visual and immediate:

• See all running apps with CPU, memory, and uptime at a glance
• Browse and filter every HTTP request flowing through the proxy
• Create mock responses with a form instead of writing JSON
• Configure network simulation per-app with sliders
• Manage the daemon from the system tray

This is the biggest gap I saw in tools like Portless — when you're debugging a tricky API interaction, you want to see the requests, not grep through logs. A visual dashboard turns traffic inspection from a chore into something you actually use.

Multi-App Config

For projects with multiple services, PortZero supports a portzero.toml config file:

[proxy]
port = 1337
https = true

[apps.web]
command = "pnpm dev"
cwd = "./apps/web"

[apps.api]
command = "cargo run"
subdomain = "api"

[apps.worker]
command = "node worker.js"
subdomain = "worker"

Run portzero up and all three services start with stable URLs. Run portzero down to stop them all. That's it.

What's Next

PortZero is open source and actively developed. Coming soon:

• Public tunnels — expose local apps to the internet with a single command, built on QUIC
• Windows support — currently macOS and Linux only
• API schema inference — automatically detect and document your API's shape from captured traffic
• Team sharing — share mock configurations and traffic snapshots with your team

Try It

# Install
curl -fsSL https://goport0.dev/install.sh | bash

# Run your app
portzero my-app next dev

# Open http://my-app.localhost:1337

Check out the GitHub repo, read the docs, or download the desktop app.