Dev

Routeup: Development Tool for Assigning Stable HTTPS Names to Local Applications

A Go-based tool that provides project name-based, stable HTTPS URLs for local development environments. Features include public tunneling and selective path exposure.

4 min read Reviewed & edited by the SINGULISM Editorial Team

Routeup: Development Tool for Assigning Stable HTTPS Names to Local Applications
Photo by Nick Karvounis on Unsplash

Assigning Proper Names to Localhost

The open-source development tool Routeup has gained attention as infrastructure for providing stable HTTPS URLs to applications running in local environments. According to a report on Lobsters titled “routeup.dev by mukul,” this tool was designed based on the concept that “applications have names.”

In traditional local development, it’s common to distinguish apps via port numbers like http://localhost:3000 or http://localhost:5173. Routeup converts these into browser-trusted HTTPS URLs that include the project name, such as https://example-app.localhost. This eliminates the need to remember port numbers, and the same URL is maintained even after restarting.

Local-First and Public Tunneling

Routeup’s design philosophy is “local by default.” There’s no need for account registration, tokens, or external servers; all route configuration remains on the local machine. Public tunneling is only enabled as an option when access from outside is required.

This approach differs from traditional tunnel tools. Compared to Ngrok or Cloudflare Tunnel, Routeup offers more granular control over the application under development. Instead of exposing all routes, it allows only selected paths to be made public externally—a practically important feature.

Mechanism for Selective Path Exposure

By specifying paths to expose in a configuration file, only specific endpoints—like webhook handlers—can be exposed to the internet. In an example configuration, /api/webhooks/* is designated, while other paths return a 404.

This proves effective for collaborative development involving external APIs. Routes can be exposed only when receiving webhooks from Stripe or GitHub, while the admin interface and API under development remain local. This is a rational design from a security perspective, as it minimizes the attack surface.

Request Inspection and Live Logging

Routeup also includes built-in debugging support. It displays the status and timing of requests in real-time, with the optional capture of headers and bodies. Communication content can be checked immediately in the terminal, eliminating the need to open browser developer tools or launch a separate debugger.

An example of runtime output from the original Lobsters post is shown, using a format that displays time, HTTP status, request ID, HTTP method, and path each on a separate line.

Compatibility with Version Control

Routeup’s configuration can be written in routeup.json or within a routeup block in package.json. It defines the project name, target path, port number, and publication settings, which can be committed to a Git repository. This allows the same routing configuration to be shared among team members.

The configuration file can define multiple targets, using long prefix matching on paths to determine routing. Even if the frontend and API server are launched on different ports, they can be treated as a single origin. Cookies are shared between frontend and API, simplifying the development of authentication flows.

Integration with Application Startup

The routeup serve command adds routes to an already-running application, while the routeup command directly executes a configured command. The latter handles automatic port number assignment, waiting for the application to start, and cleanup upon exit in one go.

In the example configuration, a command like pnpm dev --port ${PORT} is defined, and Routeup starts it by replacing ${PORT} with the actual port number. This creates a low barrier to integrating into a developer’s workflow.

Technical Foundation and License

Routeup is distributed as a single Go binary and is released under the MIT License. No telemetry is collected whatsoever. It includes a self-hostable server component, enabling the construction of public tunnels without using a hosting service (try.routeup.dev).

Editorial Opinion

In the short term, Routeup provides a simple, project-name-based solution to the challenge of HTTPS in local development environments. As scenarios requiring HTTPS expand—such as WebSocket connections in development tools and testing environments, and enabling Service Workers—the benefit of being freed from managing port numbers is significant. For users of modern frameworks like Next.js or Vite, URL management at the project level directly contributes to an improved development experience. In the long term, the design philosophy of selective path exposure could influence development toolchains. If public tunneling and security policies can be centrally managed via configuration files, this foundation could also be applied to secret management and access control in DevOps environments. The single Go binary distribution form, coupled with its ease of integration into CI/CD pipelines, helps lower the barrier to adoption. Whether this tool successfully differentiates itself from conventional tunnel tools along the axes of Modularity, Observability, and Security will require observing its adoption trends in actual development environments.

References

  • “Routeup – stable local HTTPS URLs and opt-in public tunnels”, by routeup.dev by mukul — Lobsters, 2026-08-24T19:08:59.000Z (ARR)
  • Source URL: https://routeup.dev
Source: Lobsters

Comments

← Back to Home