Live preview

Every project runs on a private dev server you start from the center panel. It reloads itself after each AI run, so you can watch the app change as you prompt — before anything is published.

The preview is separate from your public URL: it changes on every run, and it disappears when the preview stops. Its address is a temporary, unguessable hostname — unlisted rather than locked, so you can send it to someone to look at, and anyone holding that link can open it while the preview is up.

Starting the preview

1. Open the Preview tab in the center panel.
2. Click Start preview.
3. The badge moves Idle → Starting… → Ready, and your app appears.

The first start takes 30 to 60 seconds: dependencies are installed and the dev server boots. Later starts are much quicker, because that work is already done.

While a prompt is running, the panel reads AI is writing code… and the badge shows Working…. Starting is held back until the run finishes — the AI is still changing files, so there is nothing stable to serve yet. A preview that is already running is left alone and keeps serving.

The preview toolbar

Above the app:

• Refresh reloads the frame by hand.
• The pick-element button arms the mode described as "Pick an element in the preview to use as AI context". Click any element in your app and a small composer opens with that element attached, so you can say "make this wider" without describing where it is. Press Esc to leave the mode.
• The address pill shows the host your preview is served from, or no preview yet before you start.
• Desktop, Tablet and Mobile change the width the app is drawn at — 680px for tablet, 380px for mobile. They resize the frame only; nothing about the app itself changes.
• Pop out opens the preview in a browser tab of its own, and keeps that tab in step with the panel.
• View full log shows the recent runtime output, with buttons to copy all of it — or the last 200 lines — for pasting into the chat.
• Resolve with AI hands the current error and log to the AI as a new run.

The panel header also carries a Fullscreen button; press Esc to come back.

Auto-reload after a run

When a run finishes, a ready preview refreshes itself a moment later, so the change you asked for is on screen without a click. Several runs finishing close together collapse into a single refresh.

Nothing reloads while the preview is stopped or still starting. Start it and you get the current state of the code.

When it crashes

If the dev server exits, the badge turns Crashed and the panel reads Dev server crashed with the error output underneath it. Four ways out sit below that:

• Resolve with AI — send the error to the AI as a new run.
• Copy error — take the text somewhere else.
• View full log — read more than the tail.
• Restart — bring the server back up once the cause is fixed.

A crash is usually your app's code rather than the platform: a syntax error, a bad import, a missing environment variable. Compile errors behave differently — the server stays Ready and the framework draws its error over your app inside the frame. Resolve with AI covers both.

When your network blocks it

Previews are served from a different domain than the platform itself, and some networks — office Wi-Fi, campus networks, ISP-level filters — block domains that were registered recently. A preview address is exactly that. When it happens the badge still reads Ready, and it is telling the truth: your app really is running. The request never left your network, so the platform never saw it fail.

The panel checks for this and covers the frame with Your network is blocking this preview, along with the hostname it could not reach. Two ways out:

• Switch networks. A phone hotspot is enough to tell you whether that is what you are looking at.
• Hand that hostname to whoever runs the network and ask for it to be allowed.

There is nothing to fix in your project. The same address opens normally from an unfiltered connection.

Signing in to your app

Your app's own sign-in — the email and password form the AI wrote — works inside the preview panel. The preview hands the browser a partition tag with your app's cookies, which gives them a private jar tied to this page, so they are stored and sent back even though your app is embedded here.

Sign-in through Google or GitHub does not, and cannot. Those providers refuse to render their login page inside a frame at all, on any site, and no cookie setting changes that. Use Pop out in the preview toolbar to open the preview in its own tab and sign in there.

If email and password sign-in still bounces you back to the login page, the browser is the reason:

Safari 18.5 through 26.1 is the awkward case. Those versions reject partitioned cookies outright rather than ignoring them, so sign-in fails in the popped-out tab as well. Test on your published URL instead, or use another browser.

Your published app is untouched by any of this — its cookies are served exactly as your code sets them.

Preview vs your live URL

They are different things, and one detail catches people out.

The catch: the preview and a default deploy talk to the same project database. Test rows you create while prompting are the rows your published app will serve. Setting DATABASE_URL (or MYSQL_URL) yourself moves production only — the preview always stays on the platform-provisioned database.

Limits & notes

• The badge stops updating by itself if the server is still starting after 3 minutes. That is a polling deadline, not a failure — a slow first build may still come up. Send a prompt or reload the page and tracking resumes.
• Your build environment stops after about 10 minutes without activity, and after 4 hours in every case. The preview goes with it, and its address stops working. Start it again whenever you need it; nothing is lost — you just get a new address.
• The preview address is not indexed and not listed anywhere, but it is not protected by a login either. Treat a link you share the way you would treat a share link: it works for whoever holds it, until the preview stops.
• There is no stop button for the web preview. Leave it and it winds down on its own.
• This is a development server, not a deployment. Use publish for an address you can share.
• The preview covers the web app only. To see a mobile app, use preview on your phone.
• Limits may change during alpha.

Related

• The workspace — the panels around the preview and how they resize.
• Understanding AI runs — statuses, activity timelines, and what triggers the reload.
• Publish & deploy — taking the same app to a public URL.
• Your project database — the database preview and production share.