Routeup – stable local HTTPS URLs and opt-in public tunnels
7 points by mukul
7 points by mukul
I built Routeup around a simple idea: local apps should use their real names.
It was inspired by Portless, but I also wanted built-in public tunneling, selective path exposure, request inspection, and live logs.
Instead of opening localhost:3000, I can give a project a stable, trusted HTTPS URL and keep using it across restarts:
https://example-app.localhost
The app stays local by default. When an external service needs access, I can expose the whole route or only selected paths such as /api/webhooks/*:
local: https://example-app.localhost
public: https://example-app.try.routeup.dev
expose: /api/webhooks/*
Exposure has its own lifecycle. I can expose an already-running route from another terminal and stop sharing it without stopping the local app.
For quick, temporary exposure, Routeup provides names under *.try.routeup.dev without requiring an account or token. For stable public names, a token claims a namespace such as team.routeup.dev. Apps can then use names beneath it, such as api.team.routeup.dev and docs.team.routeup.dev. The same namespace model works with a self-hosted Routeup server and your own domain.
Routeup grew out of frustrations I had using ngrok and localtunnel. They could expose a port, but their tunnel-first model was not the workflow I wanted. I wanted the app to have a stable local identity first, with public access added only when and where it was needed.
I use this workflow heavily at work and for personal projects. Routeup currently supports multiple path targets behind one origin, repository-level configuration, running an app command, request inspection, hosted public URLs, and self-hosted servers.
The local workflow requires no account, token, DNS, or remote server. Routeup is a single Go binary, has no CLI telemetry, and is MIT licensed.
I'd appreciate any feedback on the project, especially ideas for improving the workflow, documentation, or features. If you run into any issues during setup or while using the tool, please open a GitHub issue or email help@routeup.dev.
I'm not an expert but everything about this screams "LLM, generate all the stuff".
The commits, the readme, the website.
It's gonna be a no from me dawg.
There's an LLM Usage section in the README. The website and documentation is LLM generated. The core implementation was mostly written by hand — LLMs helped with tests, a few specific feature phases, and documentation which I reviewed. I've tried to be transparent about exactly what was generated and what wasn't.
But that isn't even what that text in the readme says.
The core implementation was mostly written by hand... LLMs helped with tests, a few specific feature phases
is not the same as
Most of the groundwork was written by hand. LLMs were used to generate and review code
Also, asking an LLM, where hallucinations are an everyday thing to review code is fucking insanity.
If you insist on being a software developer who doesn't want to write code, at least read the fucking code yourself.
The first five milestones — the core tunnel and routing logic — were written by me with no LLM involvement beyond planning. For later phases, some of the code was generated by LLMs: tests, the process runner, logs, examples. I'll update the README to make that breakdown explicit.
Coming to code review: All of it has been reviewed by me. When I say LLM review: I mean using an LLM to understand the generated code, not approve it blindly. I could improve that phrasing too
I mean using an LLM to understand the generated code
This just sounds like a blind guy painting eyeballs on his eyelids and saying "Look I can fly a plane".
If you can't understand it yourself, and you're relying on a known hallucinator to explain to you what the output of another (or the same!) known hallucinator does, that is no better than a blind approval.