Localdock Gives Busy Developers Stable Local URLs

A development server rarely stays where you left it. One project takes port 3000, another claims 5173, and a third starts on 8000 because something else is still running. Add several projects, containers, or AI coding agents, and the port number becomes a poor way to know what you are looking at.

Localdock is built around a simpler identifier: the project name. It is a paid macOS menu bar app that gives local servers names such as dashboard.localhost, then forwards those names to whichever port the matching project is using.

The problem is not starting the server

Most web tools already handle the difficult part of starting a development server. The nuisance comes afterwards. Bookmarks point to old ports. OAuth callbacks contain URLs that need editing. A framework increments its port because the preferred one is occupied. Testing on a phone means finding the Mac's address and checking whether the server accepts connections from the network.

Localdock addresses the naming problem rather than replacing the server. According to the developer, it watches local projects and containers, uses their folder or container names, and keeps a project name connected to the current port. A project can therefore keep the same address even when its server moves from one port to another.

That makes the app most relevant to developers who run several projects at once. It also fits the particular irritation described by its creator: coding agents that start servers on whichever port is available. The app does not make those servers less resource-hungry or stop them colliding. It gives the resulting process a stable way to reach it.

Three useful levels of reach

The first level is local. A name such as dashboard.localhost opens on the Mac, while the original localhost:3000 address continues to work. Localdock adds an address rather than taking the existing one away. Names can be renamed from the app, and the developer says duplicate names are refused instead of silently reassigned.

The second level extends a selected project to the Wi-Fi network. A developer can open the same project on an iPhone or another laptop using a .local address, without installing anything on that device. This is the practical answer to the common need to test localhost on a phone with a real browser and real device hardware.

The third level creates a temporary public HTTPS link. That could be useful for showing a client an in-progress page, receiving a webhook from a service, or letting a colleague inspect a build from another location. The link requires no app or account on the receiving end. The page says it includes a secret key, expires after an hour, and stops working when sharing is disabled or the app quits.

Those levels matter because they keep the default scope narrow. A project is local unless the developer chooses to expose it over Wi-Fi or the internet. Other local servers are not meant to become reachable just because one project is shared.

What sits between the name and the server

Localdock acts as a local reverse proxy on macOS. It reads the hostname requested by the browser and forwards the connection to the appropriate development server. The landing page says it passes WebSockets, hot module replacement, server-sent events, and streaming through without rewriting the traffic. That is important for modern development workflows, where a page that loads is not enough if live updates stop working.

The setup is intended to avoid DNS configuration, hosts-file edits, administrator passwords, and command-line cleanup of occupied ports. If port 80 is unavailable, Localdock can serve from another port, which means the address gains a port suffix such as dashboard.localhost:7777. That fallback preserves access but makes the result less tidy and less suitable for a callback URL or bookmark.

Public sharing has a separate dependency. The developer says traffic goes between the Mac and Cloudflare's network, which carries the traffic and terminates TLS. Localdock's own service is described as handling the initial permanent address and licence check, not storing project names or ports. That may be a reasonable design for short-lived sharing, but it still means public links depend on an external network service. They are not a purely local feature.

Who should use it

Localdock is aimed at web developers who build a lot and regularly have several dev servers open. It is especially suited to people who want project-based localhost domains, need to check work on a phone, or occasionally need a public link without changing application configuration. The paid licence is for macOS, and the developer lists macOS 14 or later as the requirement.

It is not a general hosting service, a team dashboard, or a replacement for a proper deployment environment. A public link is temporary, tied to the Mac running Localdock, and unsuitable when a stable production endpoint is required. The app is also a poor fit for anyone on Windows or Linux, or for a team that needs shared ownership, multiple device licences, or persistent remote environments.

For the right Mac-based developer, the value is straightforward: stop treating changing port numbers as project identity. Localdock gives that identity a local name first, then adds Wi-Fi and temporary internet access when needed. Its narrow scope is also its boundary. If your main problem is juggling local projects, it fits. If your problem is deploying or collaborating on a durable environment, it does not.