An AI app you can actually open: how mk0r turns a build into a real URL
Most pages that show off an AI app give you a screenshot, a video, or a zip of code you have to wire up yourself. mk0r does something different. The moment a sandbox boots, you get a public HTTPS URL that any browser on any device can open, with no deploy step in between. Here is exactly what that URL is, where it comes from, and why it works on your friend's phone.
"Open" is doing a lot of work in that sentence
When someone says they want an AI app they can actually open, they are usually reacting to a long list of broken promises. A demo video that is not interactive. A "live preview" that throws a CORS error. A zip of code with a README that wants Node 22, three env vars, and a Postgres instance. A promo site that asks for an email before it will let you try anything. A QR code to a TestFlight that is full.
"Actually open" is shorthand for something specific. Anyone, on any device, can paste a string into a browser and the app appears. No install. No account. No deploy wait. No copy of the code in the wrong language. The link is the artifact.
What openable means, in six pieces
Real URL
https://<vmId>.mk0r.com, not a screenshot, not a CodeSandbox embed, not a zip. A bare hostname you can type or paste anywhere a string fits.
HTTPS by default
TLS terminates on Google Cloud Load Balancer at 35.186.212.31 using the appmaker-wildcard-cert. The hop to the E2B sandbox is also HTTPS, so the URL never falls out of TLS.
No install
No native app, no PWA registration, no helper extension. If a phone has Safari or Chrome, it can open the build.
No sign-in to view
The wildcard subdomain proxy does not gate viewers. The viewer never had to be on mk0r at all.
Live the second the VM is
Build and serve happen on the same VM. The dev server on port 3000 is reachable through the wildcard the moment the sandbox boots.
Stable across reloads
The vmId is persisted to Firestore under app_sessions and rehydrated on reload, so the URL you shared yesterday still resolves today.
The piece of code that makes the link work
The link works because of a single Next.js middleware file. When a request arrives at <vmId>.mk0r.com, the middleware extracts the subdomain, validates it against a regex, and rewrites the request to the E2B sandbox host on port 3000.
The regex matters. It is what stops random subdomains and traversal attempts from being silently proxied to anything internal. A vmId is, by spec, a lowercase alphanumeric string between 15 and 30 characters. Anything else falls through to the normal app.
That is the whole rewrite. There is no app server in front of your build. There is no edge worker reading bytes off a volume. The traffic walks straight from the load balancer, through the rewrite, into the sandbox where your code is running.
The path a click takes from the browser to the running app
<vmId>.mk0r.com to your running app
Where the URL comes from in the chat stream
The link is not built by your client. It is computed by the chat route on the server, off the request host, the second a session is provisioned. That means an anonymous visitor on the production domain gets https://<vmId>.mk0r.com and an anonymous visitor on staging gets https://<vmId>.staging.mk0r.com, automatically, with no client-side branding logic.
What it costs you, in numbers
You can hit the link with curl, right now, mid-build
The clearest way to feel "actually open" is to skip the browser entirely. The URL responds to plain HTTP requests from anywhere. Below is what an early hit looks like against a freshly booted VM, before the agent has even written a custom component.
The seven steps between a prompt and a link a stranger can open
You type a prompt
The textarea on the home page sends your first message. Behind it, the Bearer token is your anonymous Firebase ID token.
The session is provisioned
/api/vm/ensure-session calls getOrCreateSession in src/core/e2b.ts. An E2B sandbox is created or pulled from the warm pool with template mk0r-app-builder.
URLs are computed off the sandbox
sandboxToUrls() in src/core/e2b.ts derives previewUrl as https://<host>:3000/, where host is sandbox.getHost(3000).
publicUrl is branded onto the request host
src/app/api/chat/route.ts reads req.headers.get('host') and stamps the response with https://<vmId>.mk0r.com so the link uses your domain, not E2B's.
Wildcard DNS sends the request to the load balancer
The A record `*` in the mk0r-com Cloud DNS zone points at 35.186.212.31, the load balancer's static IP. So <anything>.mk0r.com lands on the same edge.
src/proxy.ts validates and rewrites
The middleware extracts the subdomain, checks it against /^[a-z0-9]{15,30}$/, and rewrites to https://3000-<vmId>.e2b.app via NextResponse.rewrite. No 30x redirect, the URL bar stays on mk0r.com.
The Vite dev server inside the sandbox responds
Port 3000 in the sandbox proxies to the live Vite + React app on 5173. Your friend's phone gets HTML back. No deploy ever ran.
Want to watch a stranger open your link in real time?
On a quick call we will build something live, share the URL, and open it from a second device while the agent is still writing code.
mk0r vs. the typical AI app builder, on the URL question
| Feature | Typical AI app builder | mk0r |
|---|---|---|
| URL exists during the build | No, only after a separate Deploy click | Yes, live the moment the sandbox boots |
| Where the URL lives | Random preview-host or *.vercel.app subdomain | <vmId>.mk0r.com on a wildcard cert |
| TLS coverage | Often per-deploy cert provision step | Wildcard cert covers every preview automatically |
| Auth required to view | Sometimes gated behind workspace login | None, public by default |
| Build artifact == serve artifact | Build artifact is rebuilt for serve | Yes, same VM, same dev server |
| Survives a refresh | URL often expires when preview is GC'd | vmId rehydrates from Firestore, same URL |
| Phone-openable without install | Frequently requires app or sign-in | Yes, plain HTTPS URL |
Places people actually paste the link
Why the same VM serving what it just built matters
Most "share your AI app" stories quietly skip the gap between the build environment and the serve environment. They produce code in one place (a sandbox, a notebook, an in-browser editor) and serve it from another (a static host, a CDN, a serverless function). When the two diverge, the URL you share is not the thing you tested. Edge cases appear in production that did not exist in preview.
mk0r refuses that split. The Vite dev server you see in the preview iframe inside mk0r is the same Vite dev server your friend hits when they open the link from their phone. The agent's last write is the build the visitor sees. By the time you hand out the URL, it has 0+ sibling links that have been opened by people who never had a mk0r account.
Frequently asked questions
What does an AI app you can actually open look like in practice?
When mk0r finishes building you, it gives you a URL of the form https://<vmId>.mk0r.com. The vmId is a 15-30 character lowercase alphanumeric string assigned by the E2B sandbox. You can paste that URL into Safari on your phone, into a Slack message, into a tweet, or into a friend's WhatsApp, and it loads the running app over HTTPS. There is no extra deploy step between the build finishing and the URL being live, because the same VM that built the app is serving it.
How is the URL public so quickly without any deploy?
There is no separate deploy. The VM that the agent uses to write your code is the same VM that hosts the dev server on port 3000. mk0r owns a wildcard DNS record (the A record `*` → 35.186.212.31 in the mk0r-com Cloud DNS zone) and a wildcard TLS certificate named appmaker-wildcard-cert that covers *.mk0r.com. When a request hits <vmId>.mk0r.com, the Next.js middleware in src/proxy.ts validates the subdomain against the regex /^[a-z0-9]{15,30}$/ and rewrites it to https://3000-<vmId>.e2b.app. The whole chain is alive the second the sandbox is alive.
Can someone else open the link without signing in to mk0r?
Yes. The wildcard subdomain proxy does not require any authentication. If you can read the URL, you can open the app. That is the whole point. Your friend on a 4-year-old Android phone, your designer on Safari, your VC on a hotel laptop, all just open the link and see the running app. The only place sign-in is required on mk0r is the dashboard where you manage projects and the publish flow that points a custom domain at the VM. The preview URL itself is public.
What about Quick mode, where there is no VM?
Quick mode generates a complete standalone HTML, CSS, and JavaScript document and streams it directly into the preview iframe. It is openable in a different sense: the entire app is a single self-contained document you can copy out, save as index.html, double-click, and watch run in your browser with no server at all. There is no link in Quick mode because there is no server to point at, but the app is still openable from any browser on any machine, offline, with one file.
Does the link survive a page refresh or do I lose it?
It survives. The vmId is persisted in two places: the in-memory active session map keyed by your sessionKey (see activeSessions in src/core/e2b.ts), and Firestore under the app_sessions collection. When you reload mk0r, the auth provider rehydrates your anonymous Firebase user, the session is reloaded by sessionKey, and the same vmId comes back. The URL is the same. If E2B has paused the sandbox in the meantime, the next request to the URL triggers an autoResume on the lifecycle config so the VM warms back up and serves the app again.
Can I open the app on a phone or only on desktop?
Both. The preview URL is a normal HTTPS URL with no client-side requirements beyond a browser that speaks TLS. There is no native app, no install prompt, no PWA registration step required. mk0r itself ships a phone-frame preview component that wraps an iframe of the same URL, so you can see how the build looks in mobile dimensions before you ever paste the link into a chat.
What about full HTTPS, not just HTTP?
Every preview URL is HTTPS. The wildcard cert appmaker-wildcard-cert is provisioned via Google Cloud Certificate Manager with DNS authorization, mapped onto the load balancer through cert map entries (appmaker-cert-wildcard-entry for *.mk0r.com), and terminates TLS at the static IP 35.186.212.31. The E2B sandbox itself also serves over HTTPS at 3000-<vmId>.e2b.app, so the rewrite hop never drops out of TLS.
How does this compare to AI app builders that say built-in hosting?
Many AI app builders advertise built-in hosting but route you through a separate deploy step: build first, then click Deploy, then wait for the worker or container to spin up, then receive a URL. In that model the artifact you tested is not the artifact you shared, and the URL only exists after the deploy succeeds. mk0r collapses build and serve into one VM, so the URL is live from the moment the agent starts writing code. You can refresh the link mid-build and watch the app appear.
Type a prompt. Watch the URL appear in the preview pane. Open it on your phone. That is the entire loop.
Build something with a real link