What it actually takes for an AI app maker to produce openable demos
Most pages on this topic stop at the words shareable link. They do not tell you whether the link is openable by a stranger on a phone six hours later. That second question is the only one that matters, and it is a lifecycle question, not a URL question. Here is the five point test, and the one line of code that makes mk0r pass it.
Shareable is not the same as openable
Every AI app maker on the planet says shareable. The word shareable only commits the platform to producing a string that looks like a link. It does not commit to anything about what happens when somebody actually clicks that string later, on a device that has never seen the platform. Watch what happens to most of these links the day after a build:
- The link redirects to a sign in screen because the builder gates anonymous viewing.
- The preview hostname has been rotated, the old preview has been garbage collected, and the URL returns 404.
- The link opens a marketing page asking the visitor to create their own project.
- The link works only inside the platform’s native app, not in a normal mobile browser.
- The link works, but the build artifact is now stale because the live preview was rebuilt off a different commit while you slept.
None of those failures look like a failure to the platform making the claim, because the link string was technically shareable. They all look like a failure to your friend with a coffee in one hand. So the bar I want to push for on this page is openable, and openable has a checklist.
The five point openability test
A demo URL is openable if and only if all five of these are true. Three or four out of five is still shareable, not openable. The whole point of the bar is that any failure breaks the friend with a coffee.
Openability Test
- Anonymous: a visitor with no account on the platform can render the running app.
- Cross device: the URL opens on a phone, on a laptop, on a tablet, in any modern browser, with no install.
- Time delayed: the link still works hours after the build session ended and the original tab was closed.
- Stable identity: refreshing the platform a day later returns the same URL, not a new one.
- No deploy step in the middle: the thing the visitor opens is the same artifact you tested, not a redeploy.
Where most platforms drop one of the five
The first failure is usually anonymity. A lot of builders quietly require a workspace login before they will render a preview, even one made by someone else. The second failure is time delay. The platform pauses or recycles the preview when the build session goes idle, and rather than waking it on demand, it returns an error and asks you to rebuild. The third failure is identity drift. The URL you shared yesterday no longer points at the right artifact because the preview slot was reused for something else.
None of those are bugs. They are sensible defaults for a platform that treats previews as ephemeral build artifacts and treats deploy as the thing you do when you want a stable URL. The trade is that a demo you handed out yesterday is dead today. mk0r picks a different default, which is what the rest of this page is about.
The one line that turns the URL into an openable demo
The behavior comes from one option on the E2B sandbox the agent uses to write your code. The sandbox is created in src/core/e2b.ts with { onTimeout: "pause", autoResume: true }. That single object is what makes the difference between a link that dies when the build session ends and a link that wakes up the VM on the next visit.
src/core/e2b.ts, around line 309
const sandbox = await Sandbox.create(E2B_TEMPLATE, {
timeoutMs: E2B_TIMEOUT_MS,
lifecycle: { onTimeout: "pause", autoResume: true },
});onTimeout: pause freezes the sandbox instead of destroying it when the session goes idle. autoResume: true tells E2B that the next inbound request to a paused sandbox should resume it, not error. There is no app server in front of the VM that has to remember to do this. The platform handles the wake on the request path.
Where the request actually goes when a stranger hits the link
A demo URL on mk0r looks like https://<vmId>.mk0r.com. The vmId is a 15 to 30 character lowercase alphanumeric string. When somebody hits that hostname, three things happen in order, all of them visible in the source.
First, the load balancer terminates TLS using the wildcard certificate that covers every preview at once, no per preview cert provisioning. Second, the Next.js middleware in src/proxy.ts extracts the subdomain, validates it against the regex /^[a-z0-9]{15,30}$/, and rewrites the request host to 3000-<vmId>.e2b.app. Third, E2B receives the inbound request, sees that the sandbox is paused, and resumes it because of the autoResume flag from the lifecycle config above.
That is the whole pipeline. There is no app server reading bytes off a volume, no edge worker keeping a hot copy of your build, no extra deploy step that has to succeed before the URL is alive. The dev server inside the sandbox answers, your friend sees the running app, and the demo is openable.
What happens when a stranger opens a paused demo
- 1
Hit the URL
Phone, laptop, anywhere. Plain HTTPS to <vmId>.mk0r.com.
- 2
Edge rewrite
src/proxy.ts validates the vmId and rewrites to the E2B host.
- 3
Sandbox resumes
autoResume wakes the paused VM. Disk image is intact.
- 4
Dev server answers
Vite plus React responds with the same artifact you built.
The lifecycle, side by side
Compare the two lifecycles a preview URL can have. The left tab is the typical pattern: the preview is tied to the build session, and when the session goes idle the URL goes dark. The right tab is the mk0r pattern: the preview is the dev server inside a paused sandbox, and any inbound request wakes it.
Idle to first stranger hit
1. user closes build tab
2. server marks build session idle
3. preview container scaled to zero
4. preview URL returns 503 or 404
5. friend taps the shared link
6. friend sees an error or a sign in
7. friend pings the user
8. user re-opens platform, hits rebuild
9. friend retries link, now it loadsA pass and fail grid for the five point test
Here is the rubric expressed as a grid against the typical AI app maker preview pattern. Mileage will vary by vendor. The bar I am scoring against is anonymous, cross device, time delayed, stable, no deploy.
| Feature | Typical AI app maker preview | mk0r preview URL |
|---|---|---|
| Anonymous viewer can open the link | Often gated behind a workspace or platform login | Yes, the wildcard proxy has no auth gate |
| Phone opens the link with no install | Often requires the platform's own preview app | Yes, plain HTTPS to <vmId>.mk0r.com |
| Time delayed open after build session ends | Frequently 404 or sign in once the session idles out | Yes, autoResume wakes the paused sandbox |
| Stable URL across reloads | Preview slot may be reused or rotated on rebuild | Yes, vmId is persisted in Firestore app_sessions |
| Same artifact, no redeploy in between | A deploy step often rebuilds for production | Yes, the build VM is the serve VM |
| TLS for every preview without per build setup | Some vendors provision a cert per preview slot | Wildcard cert appmaker-wildcard-cert covers them all |
The friend with a coffee, before and after
The whole reason this matters is that you eventually want a person who is not you to look at the thing. Here is what that moment looks like under the two lifecycles.
Tuesday morning, six hours after the build session
Your friend taps the shared link from a coffee shop. The platform shows a sign in wall, or a friendly error that says preview expired, please ask the creator to rebuild. Your friend types a thumbs down emoji and moves on with their morning. The conversation never happens.
- Sign in wall blocks anonymous viewers
- Preview expired error after idle timeout
- URL silently rotated on the next rebuild
- Native app required to view on phone
Why this is a lifecycle problem, not a URL problem
The thing I want to leave you with is that openability does not live in the URL string. Every AI app maker can produce a URL. The URL is trivial. Openability lives in the answer to the question: what does the platform do with the underlying compute when nobody is watching it. If the answer is destroy or hide behind a login, the URL is a decoration. If the answer is pause and resume on demand, the URL is genuinely portable.
That is also why the right test for any AI app maker is behavioral, not a feature checklist. Build something tiny. Copy the link. Close every tab. Walk away for an hour. Open the link from a private window on a phone you have never used the platform on. Whatever happens next is the truth, and no marketing copy can change it.
A worked example you can run on mk0r right now
- Open mk0r.com in a normal browser. Do not sign in.
- Type one sentence describing a tiny app. Wait for the preview pane to render.
- Look at the URL the chat stream sent over. It will be of the form
https://<vmId>.mk0r.com. Copy it. - Close every mk0r tab on every device you used. Wait long enough that the sandbox idle timeout fires.
- On a phone, in a private browsing window, paste the URL. The first request will pay the resume cost, then the running app loads.
- Reload. The URL is still the same. The artifact is still the same. You have an openable demo.
If any of those steps does not work, that is a real issue and we want to hear about it. The point of the five point test is that there is nowhere for a regression to hide. Either the friend sees the app or they do not.
Want to watch a stranger open the link mid call?
On a quick call we will build something live, share the URL, then open it from a second device while the original tab is still loading. The autoResume path is the fun part to see in real time.
Frequently asked questions
What does openable actually mean for an AI generated app demo?
Openable is a stricter test than shareable. Shareable means the platform produced a string that looks like a link. Openable means a person who is not you, on a device that is not yours, with no account on the platform, can paste that string into a browser tomorrow and see the running app. That bar excludes recorded videos, screenshot galleries, codesandbox embeds that need a fork before they run, preview URLs that expire when your build session times out, and links that redirect through a sign in wall before showing the app. The actual definition we use on this page is: anonymous, cross device, time delayed, no install. If your link fails any of those four, it is shareable but not openable.
Why does most ai-app-maker-openable-demos talk skip the lifecycle question?
Because the build session is the easy part. While you are sitting in the editor with the agent, the dev server is up, the link works, screenshots look great. The hard part is what happens in the gap: you close the tab, your laptop sleeps, your idle session times out on the platform, and then a friend taps the link from a coffee shop on Tuesday morning. Most platforms quietly garbage collect that preview, redirect to a marketing page, or surface a sign in screen. Lifecycle is invisible while you are building, which is why the marketing pages do not bring it up.
How does mk0r keep the link alive after I leave the build session?
The dev server runs inside an E2B sandbox, and the sandbox is created with the option `{ onTimeout: "pause", autoResume: true }` in src/core/e2b.ts. When the timeout fires the VM does not get destroyed, it gets paused, which freezes the disk image. The vmId is persisted into Firestore under app_sessions, so on a future request the system can find the right sandbox to talk to. When a stranger hits https://<vmId>.mk0r.com, the middleware in src/proxy.ts rewrites the request to 3000-<vmId>.e2b.app. E2B sees the inbound request to a paused sandbox and resumes it. The dev server comes back up and the response goes through. There is no deploy step in this path. The thing your friend opens is the same thing you built.
What about cold start latency on the first hit after a pause?
The first request after a pause has to wait for the sandbox to resume and for the in-VM startup script to bring up the dev server, the proxy on port 3000, and the Chromium CDP on 9222. The wake itself is fast at the E2B layer; the slower step is whatever your Vite dev server needs to recompile entry chunks. After the first request succeeds the sandbox stays warm for the duration of E2B_TIMEOUT_MS, so subsequent visitors get normal latency. If your demo has to feel snappy on the first hit no matter what, the right move is to ping the URL yourself a minute before you share it with a real person.
Does my friend need a mk0r account to open the demo?
No. The wildcard subdomain proxy in src/proxy.ts does not run any auth check. The URL pattern is /^[a-z0-9]{15,30}$/, the rewrite hops to E2B, and the dev server answers. The only place mk0r requires you to sign in is the dashboard where you manage projects and the publish flow that maps a custom domain at the VM. Reading a preview URL that someone else built has zero account requirement. That is what makes it openable in the strict sense.
What about phones? Does the link really work without a download?
Yes. The preview URL is a normal HTTPS URL terminating at the Google Cloud load balancer at 35.186.212.31, served under the wildcard certificate appmaker-wildcard-cert which covers *.mk0r.com. There is no native shell, no PWA registration step, no browser extension required. Mobile Safari on a four year old phone opens it the same way it opens any other website. The phone-frame preview inside mk0r itself is just an iframe of the same URL, so what you see while building is what your friend sees on their device.
Can the demo URL outlive the original creator session entirely?
Yes, with caveats. The vmId is stable and persisted, so as long as the sandbox is reachable the URL works. E2B sandboxes do eventually expire if untouched for long enough, at which point the link returns an error rather than waking the VM. If you need a demo that survives indefinitely without any future visit, the right path is to use the publish flow in src/app/api/publish/route.ts to point a custom domain at the VM. That is a different surface from the openable preview URL discussed here. The preview URL is built for cheap, instant sharing with a finite but useful lifetime. A published domain is the upgrade for when the demo graduates into something more permanent.
What is the simplest test I can run on any AI app maker right now?
Build a tiny app on the platform, copy whatever the platform calls a share link, then close every tab on every device you used to build. Walk away for an hour. Then on a phone you have never opened that platform on, in a private browsing window, paste the link. If the running app loads without you tapping anything else, the platform produces openable demos. If you see a sign in screen, a preview expired error, a marketing page, or a build please wait spinner, it does not. That is the only way to find out, because no marketing copy distinguishes the two cases.
Build a tiny app. Get a real link. Hand it to a stranger. That is the whole loop.
Build something openable