Portless

A dev-server proxy that gives every local app a fixed name, so bookmarks and agents stop breaking

Replace port numbers with stable, named local URLs. For humans and agents.

Category
Developer tools
Audience
Developers
Language
TypeScript
Licence
Apache-2.0

Updated

Portless is a command-line proxy that replaces the port number of a local development server with a stable, named .localhost URL. It is aimed at web developers who start and restart dev servers dozens of times a day, and at the coding agents that now have to find those servers too. The project comes from Vercel Labs, is written in TypeScript, and is published under the Apache-2.0 license.

What it does

The everyday problem it targets is small but constant: your app answers on http://localhost:3000 today, on some other port after the next restart, and every bookmark, saved cookie and pasted link built on the old number quietly stops working. The channel's video makes the same point about AI agents — a shifting localhost port is one more thing for an agent to get wrong.

Portless puts a proxy in front of the dev server and hands it a name instead. You run your usual command through it and the app lives at https://myapp.localhost, the same address every single time. The README frames the change as a one-line edit to a package script:

- "dev": "next dev"                  # http://localhost:3000
+ "dev": "portless run next dev"     # https://myapp.localhost

HTTPS with HTTP/2 is on by default, so the local URL behaves like a real origin rather than a bare port. If you would rather not deal with certificates, --no-tls gives you plain HTTP.

How it works

The proxy starts automatically the first time you run an app through it. Portless picks a random port in the 4000–4999 range and passes it to your process in the PORT environment variable. Most frameworks — Next.js, Express, Nuxt and friends — respect that variable with no further work.

For frameworks that ignore PORT, portless injects the right flag itself. The README names Vite, VitePlus, Astro, React Router, Angular, Expo and React Native, and says the tool adds the appropriate --port flag plus a matching --host flag where one is needed. That injection reaches through a package script whose command starts with the framework or a known runner, so "dev": "vite" and "dev": "bunx vite" are both handled.

The careful part is what portless refuses to touch. Only the framework's server commands get the flags — dev, serve, preview, start, a bare vite, or vite [root]. A command that does not serve anything, such as vite build, vite optimize, vp test or astro check, is left alone rather than handed a port it cannot use. Expo's connection modes (--localhost, --lan, --tunnel) are preserved while the assigned port is still injected. And when portless cannot confidently classify a script — the README's example is a flag placed before the subcommand on a CLI whose flag grammar it does not track, vp --mode dev build — it leaves that script alone too.

TLS is set up on first run: portless generates a local certificate authority, trusts it, and binds port 443, auto-elevating with sudo on macOS and Linux.

Getting started

The recommended install is global, npm install -g portless; it can also go in a project as a dev dependency with npm install -D portless. Then you name the app and pass your normal command:

portless myapp next dev
# -> https://myapp.localhost

One caveat the README raises itself: portless is pre-1.0. Installed per project, different contributors can end up on different versions, and the state directory format may change between releases — which can mean re-running portless trust after an upgrade.

When to use it / when not

It fits best when you juggle several local apps at once, when you want links and cookies that survive a restart, or when an agent is driving your dev environment and needs an address it can rely on. The framework-aware flag injection means most existing scripts work without being rewritten.

It fits less well if you cannot install a local CA or let a tool bind port 443 with elevation — though --no-tls sidesteps that — or if you run exactly one app on exactly one pinned port and the churn the tool solves simply is not your problem. This is a local-development convenience, not production infrastructure, and a pre-1.0 tool that may ask you to re-trust its certificate authority after an upgrade is worth weighing before you put it in a shared repository's scripts.

Developers who lose small amounts of time every day to moving ports, and teams whose agents keep chasing a URL that will not hold still, should take Portless seriously. It solves a narrow annoyance, but a universal one, and the design details — respecting PORT where it exists, injecting flags only into commands that actually serve, declining to guess when it cannot parse a script — suggest the authors understood that a tool wrapping everyone's dev command has to be conservative. Nearly 12,000 stars since its February 2026 launch and steady pushes through late August 2026 say plenty of people agree. Just go in aware of the pre-1.0 label.

More in Developer tools

All of Developer tools →