An AI mobile app builder where the preview URL is already a real URL

The 36 lines that turn a sandbox into a brand-domain URL

Most of the work happens in src/proxy.ts. It is a Next.js edge middleware that runs on every request that lands on our load balancer and decides whether the host header looks like a sandbox subdomain. If it does, the request is rewritten to the E2B ingress URL, transparently to the caller.

The vmId regex /^[a-z0-9]{15,30}$/ is what makes the wildcard safe. A real sandbox id is always lowercase alphanumeric in that length range, so a request forwww.mk0r.comfalls through to the marketing site, whileix37c4ka9q1mqyl3.mk0r.comgets routed at the cloud sandbox holding your build. There is no allow list to maintain. New sandboxes do not need a deploy step to be reachable; they just are.

Underneath, two pieces of infrastructure quietly carry the rest of the load. Cloud DNS holds an A record at *.mk0r.com pointing at our load balancer IP, and Certificate Manager owns a wildcard cert that covers every sandbox subdomain. Together they mean any sandbox id resolves and serves valid TLS without setup.

What happens when your phone hits the URL

Walk through one HTTP request, end to end. The phone is on cellular, the URL has been pasted into iMessage and tapped from the message bubble.

Nothing in that path requires the recipient to sign anything in. The cert is real, the host is the brand, the latency is one extra hop on top of the sandbox's own ingress. The phone treats it like any other web app, which is the entire point.

Why live reload survives the proxy

A static URL is one thing. A live one is another. The interesting property of <vmId>.mk0r.com is that the build keeps updating while the recipient holds the phone. That is not free; it is a single line of Vite config.

Without that line, the Vite client in the browser tries to open an HMR WebSocket back to the dev port directly. From a phone on a different network, that fails. With it, the client opens a wss://<vmId>.mk0r.com/ socket on the standard port that the proxy already terminates. The middleware happens to forward WebSocket upgrades, so the HMR channel rides through to the sandbox unchanged.

The visible result: you change a button color in the editor on your laptop, and the tester watching the URL on her phone sees the color change. No reload, no manual refresh. Most demos people remember are this kind of demo.

From your laptop to a home-screen icon, in four moves

With the URL behaving like a real URL, the share flow collapses to four steps. None of them requires a CLI, a tunnel, or an account on the recipient side.

What the public URL gives you that an iframe cannot

The in-editor 390 by 844 frame is a perfect dev surface, but there are a handful of things only a real URL on a real phone can show you. These are the cases where the brand-domain preview pulls weight you would not get from any sandboxed iframe, no matter how good the editor is.

What sharing looks like elsewhere, and what it looks like here

The contrast lives in the steps the user has to perform between "I have a thing" and "you can use this on your phone." Below is the typical flow on a tool that gates sharing behind a publish action, and the corresponding flow on mk0r.

// 1. sign in to the platform with the magic link they emailed
// 2. open the project, click the canvas, hit the "..." menu
// 3. pick "Publish" and wait for the deploy job to finish
// 4. open the project settings, set visibility to Public
// 5. copy the share-link slug from the modal
// 6. paste the slug into a URL builder for the platform host
// 7. test the URL once to confirm the deploy actually went live
// 8. text the link with a note: "you'll need to make an account"

The mk0r path is shorter because the URL is already alive. The traditional path is longer because most tools defaulted to a publish gate before anyone realized that a brand-domain URL is cheap once you own the wildcard cert and the middleware.

Three real reasons people use a phone-ready URL on day one

The patterns below come from how I have actually watched mk0r users hand off a build. Each one is a workflow that breaks the moment sharing requires an account or a publish step.

One detail to know about session lifetime

The brand-domain URL is bound to the sandbox id, not to a short-lived token. As long as the sandbox exists in any state (running, paused, restorable from Firestore), the URL resolves to it. When a session is fully released, the URL stops resolving and the proxy returns a 502.

The implication for sharing: the URL you pasted into iMessage on Monday will still work on Wednesday if you have not killed the session. If the recipient hits a 502, the agent can resume the same session and the URL comes back online without you having to send a new link.