Miren Anywhere
We’ve always wanted the first time you install Miren on your laptop to feel a little magical. Most of it does. You boot a cluster, you deploy to it, your app comes up, and Miren hands you a URL. Then you open the URL and get a timeout. Or a “this port is blocked” page. Or, when the dice land badly, the login screen for your own router.
We watched this happen over and over, and honestly, it’s fair. When you launch something from a laptop, there usually isn’t a direct path from the internet back to a server running on it. Your machine is behind a home router with one shared address, or on coffee-shop wifi, or inside a corporate network that has opinions. Whether that’s a flaw in how the internet turned out or a perfectly good default depends on which IPv6 evangelist or NAT-head you last got cornered by. Either way it’s the normal state of things, and it sits right between “my app is running” and “my app is on the internet.”
The same wall shows up for a home lab in the basement, or a VM in a locked-down VPC that policy says gets no public IP. The laptop is just where most people meet it first.
Our first move was to give people a cluster that was already out there. That’s Miren Club, a shared cluster we run and keep on the open internet so anyone can deploy something real without standing up a server first. It’s a lovely way to kick the tires on Miren, and if you just want a cluster to already exist, give us a holler in Discord and we’ll grant you access.
But Miren Club works by not being your machine at all. We also wanted the box right in front of you to work, the laptop or the home lab that’s actually yours. The app running on it should be out on the internet and reachable, without you fighting your router or your ISP or your network admin for it.
That’s Miren Anywhere. Turn it on, and a cluster with no public address of its own can serve its apps to the whole internet. Your router never opens. Nothing forwards a port, nothing waits for an inbound connection, and there’s no new address for you to babysit.
How does the internet reach a closed box?
The whole thing turns on which way the connection runs.
Instead of waiting for the internet to come knocking, your cluster reaches out. It opens a connection to Miren Cloud and keeps it open. When a request for one of your apps shows up, it comes to us first, at a server we run on the public internet called a POP (a Point of Presence). The POP holds the TLS certificate for your hostname, takes the request, and hands it down the connection your cluster already opened.
From your firewall’s point of view, nothing is listening and nothing is dialing in. The only thing your cluster does is make an outbound connection, which is the one thing almost every network already lets you do. That is the same move a laptop makes to load a web page. No port forward, no static IP, no dynamic DNS, no inbound rule at all.
Traffic stays encrypted the whole way across the internet. Your visitors reach the POP over HTTPS, and the POP forwards their requests to your cluster over an encrypted QUIC connection. It works the way a CDN does: the POP terminates TLS at the edge so it can route your traffic, which means it is not end to end. If that distinction matters for what you are running, it is worth knowing up front.
If you think you’ve seen this trick before, you have
Cloudflare Tunnel and Tailscale Funnel (and presumably a whole family of other products ending in -unnel that we’ve yet to discover) run the same play: a daemon on your machine dials out to a fleet of edge servers, and public traffic rides home on the connection it opened. ngrok has done a developer-flavored version of it for years. They’ve made it genuinely good, and we didn’t invent any of it.
What’s ours is where it sits. With those tools you’re bolting a tunnel onto your setup: a separate daemon to run, its own account, a config file that maps ports to hostnames, your domain living in someone else’s dashboard. Miren Anywhere isn’t something you add. You deployed an app to your cluster, and the same platform that runs the app carries its traffic. The POP already knows your app’s hostnames, because Miren already manages them, so there’s nothing to wire up. For the laptop-and-Docker case that needs it most, it’s on before you think to look for it.
Turning it on
For the setups that clearly need it, Miren just does this for you. A containerized install, Docker or Podman, generally can’t accept inbound traffic from the internet at all, so when a cluster like that comes up with no reachable public address, Miren routes its apps through the POP network without you asking.
Every existing cluster starts with Anywhere off, on purpose. We’ve thought a lot about how to roll this out, and we’re doing it carefully. There’s real machinery behind the scenes: your clusters and Miren Cloud coordinate to work out the network environment a cluster is sitting in and map a path back to it. Even with that in place, we wanted it to stay opt-in for clusters that already exist. Network environments are wide and varied, and an oversight in our detection heuristics could reroute a perfectly healthy cluster’s packets through our POPs when they never needed to leave home. A cluster that’s already reachable is working fine, and we’d rather leave it alone than move its traffic on a hunch.
So when you want Anywhere on a cluster that isn’t already getting it, you turn it on from the Miren Anywhere setting on the cluster’s page in Miren Cloud. The docs walk through the modes and what each one does. As the feature grows up and we trust the detection across more of those environments, expect the cautious defaults to open up.
What it covers, and what it doesn’t yet
Miren Anywhere is young, and we’d rather tell you where the edges are than let you find them.
It covers the hostnames Miren manages for you: your cluster’s cluster-xyz.miren.systems address and any Miren Cloud subdomains you have claimed. Bringing your own custom domain through Anywhere is not supported yet, so for now a custom domain still needs a cluster that is directly reachable.
It carries app traffic, not deploys. The HTTP and HTTPS your visitors load, on ports 80 and 443, ride the POP network. The control plane does not, so miren deploy, miren logs, and the rest of the CLI still need a direct network path to the cluster. In practice a cluster with no public address can serve its apps to the entire internet through the POP network while you deploy to it from across the same LAN. Carrying that traffic over Anywhere too is on the list.
Under the hood
You don’t need to understand how Miren Anywhere works to use it. This overview is here because the handshake is a neat little piece of work and some of you will want to see it.
Your cluster’s outbound connection to Cloud is a long-lived WebSocket. That is the channel Cloud uses to reach back to a cluster it cannot dial directly. When a request arrives at a POP for a cluster that is not connected to that POP yet, a few things happen in quick succession.
The POP holds that request open and asks Cloud to wake the cluster. Cloud relays the wake down the cluster’s WebSocket along with a one-time token. The cluster dials the POP directly over QUIC, presents the token, and the POP registers the link. Then the held request forwards straight down the fresh tunnel, and the visitor gets their response a second or so later, no retry and no error page. Every request after that skips the whole dance, since the tunnel stays up. (If the cluster somehow takes more than fifteen seconds to dial in, the POP gives up and asks the visitor to retry, but that’s the failure case, not the normal one.)
That token is doing quiet, important work. Behind carrier-grade NAT, a pile of clusters can share one public IP, so the POP cannot tell them apart by address. It matches the incoming connection to the right cluster by its token instead. That is what lets this stay safe when the network underneath is crowded and anonymous.
Try it
If you’re already running Miren, you can turn this on right now. Open your cluster’s page in Miren Cloud and switch Miren Anywhere on, and your app is out on the internet. If your cluster runs in Docker or Podman with no public address, it’s likely on already.
The full details, including how the connectivity checks read and how to tell the deploy path from the app path, live in the Miren Anywhere docs.
And if you have not tried Miren yet, this is a good reason to start. You can put an app on the internet from a box in your house, with your router still closed, in about the time it took to read this.