Localdock

Product Introduction

1. Definition: Localdock is a macOS menubar application that functions as a localhost reverse proxy and secure tunnel service. It automatically assigns stable, human-readable domain names (like projectname.localhost) to development servers running on a local machine, eliminating the need to track or manually configure IP addresses and ports.
2. Core Value Proposition: It exists to solve the fundamental problem of port collision and unstable localhost URLs in modern development workflows, particularly those involving multiple parallel servers or AI coding agents. For a one-time fee of $9, it provides developers with permanent, shareable addresses for their local projects, extending access from their own machine to Wi-Fi-connected devices and the public internet via secure, temporary links.

Main Features

1. Stable .localhost Addressing: Localdock listens on a local port (default 80, falls back to 7777) and intercepts requests to the *.localhost domain. It uses the hostname from the HTTP request to dynamically route traffic to the correct local server port, regardless of port changes. This leverages the web standard where the .localhost top-level domain always resolves to the loopback address (127.0.0.1). No DNS or hosts file configuration is required.
2. Wi-Fi Network Sharing ("Reach: Wi-Fi"): When enabled per-project, Localdock makes a specific dev server accessible to other devices on the same local Wi-Fi network using a .local address (e.g., projectname.local). This is achieved through mDNS (Bonjour) advertisement and local network proxying, allowing for instant testing on mobile devices or colleague laptops without cables or client-side software.
3. Secure Public Tunneling ("Reach: Internet"): This feature creates a secure, ephemeral HTTPS tunnel to a local server. It generates a unique, secret-key-protected URL (e.g., quiet-lion-7f3a.localdock.link) that expires after one hour. The tunnel is established directly between the user's Mac and Cloudflare's network, which handles TLS termination. Localdock's servers only facilitate the initial tunnel handshake and never inspect the proxied traffic, project names, or ports.
4. Automatic Project Discovery & Management: The application automatically detects running servers and creates names based on project folder names or Docker container names. It provides a centralized dashboard to view all active servers, rename projects, and control their "Reach" level (Localhost, Wi-Fi, Internet) with a single toggle.
5. MCP Server for AI Agents: Localdock includes a Model Context Protocol (MCP) server exposing tools (list_ports, get_free_port, cleanup) specifically designed for AI-assisted development environments like Claude Code and Cursor. This prevents AI agents from colliding on ports and incorrectly "fixing" code due to EADDRINUSE errors.

Problems Solved

1. Pain Point: Port Collision and Unstable Localhost URLs. Developers, especially those using AI agents or running multiple microservices, constantly face EADDRINUSE errors. Frameworks often auto-increment ports (e.g., from :3000 to :3001), breaking bookmarks, OAuth callback URLs, and mental context.
2. Target Audience: Solo Developers, Freelancers, and Small Teams working with modern web stacks (Next.js, Vite, etc.); AI-Powered Development Workflows using Cursor, Claude Code, or GitHub Copilot; Full-Stack and Mobile Developers who need to test responsive designs on real iOS/Android devices; Developers who need to share previews with clients or test webhooks from external services like Stripe.
3. Use Cases: Providing a stable dashboard.localhost URL for a Next.js dev server that persists across restarts; instantly testing a local React Native app's web view on an iPhone over Wi-Fi via app.local; securely sharing a feature branch preview with a remote stakeholder via a temporary HTTPS link; allowing Stripe to send webhook events directly to a local backend server during payment integration testing.

Unique Advantages

1. Differentiation: Unlike ngrok, which exposes raw ports, Localdock is project-centric. It exposes a named service behind a key-gated, auto-expiring link, with no account required for the recipient. Unlike traditional hosts file edits or local DNS servers (dnsmasq), it requires zero system-level configuration or admin rights and dynamically adapts to port changes.
2. Key Innovation: The "three rungs" model (Localhost, Wi-Fi, Internet) built on a single, stable project name. The core innovation is decoupling the accessible endpoint (projectname.*) from the underlying, volatile transport layer (localhost port). This, combined with the one-time purchase model and deep integration for AI agent stability, creates a uniquely frictionless developer experience.

Frequently Asked Questions (FAQ)

1. Is Localdock a secure alternative to ngrok for sharing localhost? Yes, for the specific use case of temporarily sharing a development server from a Mac. Localdock provides key-gated, ephemeral HTTPS links that expire after one hour and are terminated the moment the user disables sharing. It is not designed as a replacement for production-grade ingress or persistent tunnels.

2. How does Localdock handle WebSockets and hot module replacement (HMR) for frameworks like Vite? Localdock operates as a TCP-level reverse proxy. After resolving the hostname, it forwards raw network traffic to the target port. This means it fully supports WebSockets, HTTP/2, Server-Sent Events, and Vite's HMR protocol without any modification or performance overhead, as it does not inspect or rewrite application-layer data.

3. Can I use Localdock with Docker and Docker Compose for multi-container projects? Absolutely. Localdock automatically detects containers by their service names and assigns corresponding .localhost addresses (e.g., a postgres container becomes postgres.localhost). This simplifies access to individual services within a composed application without needing to map numerous host ports.

4. What happens if I already have a service running on port 80 on my Mac? Localdock automatically detects the conflict and falls back to using port 7777. All your project URLs will then be accessible at projectname.localhost:7777. You can also manually configure the listening port in the application settings.

5. Does the Wi-Fi sharing feature expose all my local servers to others on the network? No. Network sharing is an opt-in, per-project feature. By default, all projects are only accessible via *.localhost on your own machine. You must explicitly toggle the "Reach" setting to "Wi-Fi" for each project you wish to expose, ensuring no unintended services are made network-accessible.