Portless alternative

lokei vs Portless

Both products replace fragile localhost ports with stable HTTPS names. The meaningful difference is how much of the surrounding development lifecycle the tool owns.

Last verified: July 16, 2026

npm install -g @ulpi/lokei && lokei setup
See the feature comparison

At a glance

The fastest way to understand the product boundary.

Feature-by-feature comparison

Built in means the capability is owned by the product. External integration means another service provides it.

01

Local HTTPS and domains

02

Project and service lifecycle

03

Debugging and sharing

Where each product has a real edge

Both products solve the port-number problem. Their strengths diverge after that first step.

01

Where Portless has a real edge

A focused proxy with several useful networking modes.

  • Serve the same route under multiple local TLDs simultaneously.
  • Use built-in LAN and mDNS support for testing on nearby devices.
02

Where lokei has a real edge

A broader development lifecycle around the proxy.

  • Inspect, filter, replay, and export local traffic without another product.
  • Discover and route Docker Compose and Laravel Sail services automatically.
  • Model HTTP services, dependencies, workers, routes, and health checks together.
  • Share the active project natively and start it first when it is stopped.

Which one fits your workflow?

Choose based on the job you want the tool to own.

01

Choose Portless if you...

  • Want a compact named-localhost proxy and little else.
  • Need simultaneous local TLDs or built-in LAN discovery.
  • Already use Tailscale or ngrok and want Portless to hand sharing off.
  • Primarily run JavaScript workspace development scripts.
02

Choose lokei if you...

  • Want the tool to understand and start frontend and backend frameworks.
  • Run Docker Compose, Laravel Sail, or mixed-service repositories.
  • Need request inspection and replay as part of normal local development.
  • Want one project-aware command to start and share the current application.

Try lokei alongside a Portless project

The project files do not need to be rewritten. The only hard conflict is that both proxies normally own the standard HTTPS port.

  1. 01Stop the Portless proxy or startup service so port 443 is available.
  2. 02Install @ulpi/lokei globally and run lokei setup once.
  3. 03From the same project directory, run lokei doctor and then lokei run.
  4. 04Verify the assigned .test URL, then use lokei inspect or lokei share when needed.

Do not run both default HTTPS proxies on port 443 at the same time. You can return to Portless by stopping the lokei service before starting the Portless proxy.

lokei vs Portless FAQ

Direct answers to the differences most likely to affect a local setup.

Do both products provide trusted local HTTPS?

Yes. Both create and trust a local certificate authority and serve applications over HTTPS with HTTP/2. Their default names and resolution strategies differ.

Does Portless support monorepos?

Yes. Portless discovers npm-style workspaces and can start packages that expose the selected script. lokei additionally models service dependencies, internal workers, path routes, and health checks through lokei.yaml.

Can Portless create a public URL?

Yes, through documented integrations with Tailscale, Tailscale Funnel, or ngrok. lokei provides its own project-aware share session and hosted relay.

Can I use both products on the same machine?

Yes, but their default HTTPS proxies cannot both bind port 443 simultaneously. Stop one proxy or service before starting the other.

Which product is easier when I do not know the development port?

lokei is designed for that case: run lokei run from the project directory and it detects the command, framework, and port. Portless can run package scripts and inject a port, but its direct route commands remain organized around an explicit route name or script.

Which product is better for Docker Compose or Laravel Sail?

lokei has first-class Compose and Sail discovery, starts the stack, identifies public HTTP services, and keeps databases, caches, and workers private. Portless can persist a domain-to-port alias, but its public documentation does not describe ownership of the Compose or Sail lifecycle.

Does lokei support the multiple local TLDs that Portless offers?

Not simultaneously. lokei uses one active machine-wide development TLD, defaulting to .localhost on native Windows and .test on macOS, Linux, and WSL2, and supports changing that TLD. Portless can serve the same route under several configured TLDs at once, which is a real advantage when a project must be exercised under multiple local suffixes.

Sources and methodology

Competitor claims use Portless's official documentation. lokei claims use the public website and published npm package documentation.

Verified July 16, 2026. Product capabilities can change. Portless is a trademark of its respective owner. lokei is not affiliated with or endorsed by Portless. Where the reviewed documentation does not describe a capability, this page says “not documented” rather than claiming the capability does not exist.

$ lokei run

Run the complete local workflow

Install lokei, complete the one-time machine setup, then run it from an existing project directory.

npm install -g @ulpi/lokei && lokei setup
See lokei pricingAlso compare lokei and ngrok