RuntimeAuthor to live. Nothing in between.
When you build an app on The Cloud, it materializes, renders, and serves on our own runtime. Make it public and every edit is live the moment you save it. No branch, no build queue, no preview deploy, no promote step. The apps you build ride the runtime directly.
Three moves, no pipeline
The whole path from writing an app to serving it: the parts that are usually a git push, a CI run, and a deploy elsewhere.
01
Materialize
You (or an AI over MCP) write the app's files straight onto The Cloud. No repo to clone, no scaffolding to boot. The working files are the app.
02
Render
The app renders on our runtime. Headless checks load every route and screenshot it at phone and desktop widths, so a broken route is caught before anyone clicks it. All without a deploy.
03
Serve
A public app is live at its own URL. Editing it is editing the live site: the next visitor gets the change. There is no build queue and no promote step to wait on.
What “live on write” really means
A public app serves its current files on every request, so an edit shows up on the next load. There is no separate published copy to catch up. When you want a beat before shipping, you keep the app private and work on it in the open — then publish when it’s ready.
The undo is the version history: the runtime checkpoints your work, and you can roll back to any point. So shipping fast is safe because recovering is instant, not because a gate slowed you down first.
Safe to ship fast
Skipping the pipeline works because of two things: a small blast radius and a fast way back.
One app can't reach another
Every served app runs under its own locked-down security policy, with its own data and only the permissions its viewer was granted. A mistake stays inside the app that made it.
Every risky change is recoverable
The runtime checkpoints your app as you work and keeps a version history you can roll back to. A restore is itself undoable, so recovering is never a one-way door.
Checks that guide, gates that matter
Route-health and screenshot checks are there to inform you, not to block you. The few checks that do gate, the ones that keep a header from drifting or a page from rendering broken on a phone, only hold back an app you're about to put in front of people.
What makes it a real site
Insta-shipping isn’t a licence to ship a toy. A site built on the runtime is held to the same bar a hand-deployed one would be:
Real routes: the URL changes, back and forward work, deep links open the right view, and a reload keeps you where you were.
It renders cleanly on a phone and a laptop — no drifting header, no black status bar, no overflow.
Every route loads without a thrown error.
If it's client-facing, it's been rendered and eyeballed at both widths before it goes live.
Building here as an AI?
Connect over MCP, write the app’s files, and check your work with the headless render and route-health tools. For a public app, your write is live. Keep it private while it’s rough, publish when it’s ready, and lean on version restore as your undo. This runtime is why your work ships the instant it’s correct.