Mobile app maker online, booted before you arrive

What most online mobile app makers actually mean by online

Open the homepage of a typical online mobile app maker and you land on a sign-up wall. Pick a template. Pick a plan. Watch a spinner while a generic shared web canvas warms up. The drag and drop editor is online, sure, and the published mobile site is served from their CDN. But the iteration loop, the moment to moment build experience, leans heavily on a single shared backend or your local browser to do the work.

The thing every page about this topic glosses over is the architecture under the editor. Where does the dev server run? Where does the test browser run? Where does the agent run? On most platforms the answer is somewhere fuzzy and shared. On mk0r the answer is concrete: each session gets a dedicated cloud sandbox running Vite, headless Chromium, Playwright MCP, and the agent bridge, and that sandbox was already booting while the landing page was still rendering in your tab.

The pre-warm: a sandbox is online before you are

When you open mk0r.com, the home component fires a fetch on mount. The body is empty, the response does not matter, the point is the side effect on the server.

That POST hits a route that calls topupPool(), which in turn calls prewarmSession() until the pool reaches VM_POOL_TARGET_SIZE. Each pre-warmed session is a real E2B sandbox booted from a specific template, with the proxy, Vite, Chromium, MCP, and ACP bridge all up and listening. The sandbox identity and reachable URLs land in a Firestore document so the next user can claim it.

The first request your tab sends after submit is a session claim. A Firestore transaction reads one ready row, deletes it, and returns the sandbox metadata. Re-initialize ACP, create a fresh session, and the preview URL is yours. The wait you experience is two round trips, not a cold E2B boot.

What is actually running, online, while you read this

Inside every active sandbox there are five long-running services and one reverse proxy that fronts them all on port 3000. SSH into a live sandbox and the listening sockets look like this:

The reverse proxy is the trick that makes this all addressable from one URL. /acp/* lands on the agent bridge. /mcp/* and /sse land on Playwright MCP. /screencast and /input WebSockets relay CDP traffic for the in-VM Chromium. /vnc relays websockify. Every other path falls through to Vite on 5173, including the HMR WebSocket. So the iframe you see in your tab and the screencast of the cloud Chromium and the agent that is editing the project all share one host and one port.

The reverse proxy, in twenty lines of code

The whole multiplexer is a small Node script written into the sandbox at boot. The interesting part is how it routes everything through one HTTP server and one WebSocket server.

Because everything is on one host, the public preview URL works on a phone the same way it works in the desktop iframe. Vite HMR still flows. Screencast still flows. The session is one online place, not a stack of services you have to wire together.

What this online architecture lets you skip

When the dev server, the test browser, and the agent all live in a cloud sandbox, a long list of typical online builder requirements quietly disappears. Side by side:

What you can build in this online environment

Anything that fits a 390 by 844 mobile web app fits the cloud sandbox. Quick mode is right when one HTML file does the job. VM mode is right when you want a real Vite project you can keep editing. A few things that work well end to end:

Specifics about the online sandbox

Each chip there is a real listening port or a real piece of infrastructure inside the sandbox. None of it is on your laptop. The pool target size is configurable per environment viaVM_POOL_TARGET_SIZEand stale pool entries (older than 45 minutes, or with a mismatched specHash from a redeploy) are cleaned up automatically so claimers always get a fresh, correct sandbox.

Why the wait between submit and first paint feels close to zero

On a cold path, the agent path adds up to roughly five seconds: E2B sandbox cold boot, ACP initialize, session/new, getOrCreateSession bookkeeping, then the first agent turn. On the warm path, four of those five steps already happened in the background while the landing page was rendering. What is left is a Firestore transaction (single round trip), an ACP re-initialize (the bridge respawns the agent subprocess only if your API key fingerprint differs from the warmed one), and a session/new call. That is the entire visible delay, and it is the reason the preview iframe usually starts loading before you have finished reading your own prompt back.

The phone, on your phone, while you build on a desktop

The cloud sandbox publishes the reverse proxy on a public URL. That URL is the one the in-tab iframe loads from, and it is also the one you can paste into the phone browser sitting next to your laptop. Vite HMR runs over WebSockets through the same proxy, so a file change in the agent triggers a repaint on the desktop frame and on the physical phone at the same time. It removes the loop where you build, deploy, install, debug, build, redeploy. The phone is just another viewport pointed at the same online sandbox.