Publishing a Web App

Give your app a real web address anyone can open — and manage it from Profile → My sites.

From project to website — Build first, then Publish

A Web App project does not have to stay inside VyroAI: it can get a web address anyone with the link can open, with no server of your own and nothing to configure.

The main button in the Code Studio header — between Save and the ⚙ gear — does not start as Publish, though. It starts as Build, and there is a gate in front of publishing:

Build — press it and it becomes Building… while your project is checked.
If the check finds problems the button turns red with the number of errors on it, and there is nothing to publish until they are fixed.
Only a clean pass turns it into Publish.

And any new edit resets it to Build — which is the point of the gate: publishing sends the build that just passed, not a live feed of your edits, so nothing goes out untested.

Picking the address

The dialog asks one thing: a Site address. It starts as your project name tidied into lowercase-with-dashes, and the rules are simple: 3 to 40 characters, letters, numbers and dashes only, and a handful of names (www, admin, api and the like) are reserved. As you type, the dialog checks whether the name is free — Available, or Taken — try another name — before you can press Publish site.

Who can open it is fixed for now: Anyone with the link — the site is not listed anywhere; it is shared by you. (A Password option is drawn in the dialog but switched off — it needs the hosting server and does not work yet.)

Updating it, and taking it offline

Once you have a site, that same button becomes the whole story — it changes its own label to whatever the site needs next:

Update site — you have edited the project since you published; press it and visitors get the new version
Visit site — the live site already matches your project; there is nothing to push, so it just opens it
Bring online — the site is switched off

Editing your project does not change the live site: visitors keep the version you published until you press Update site. That is deliberate — a half-finished edit can never break the site people are using.

Everything else lives under that same button's small arrow: Copy address, Open site, Address & visibility…, Security check…, Take offline (or Put it back online) — and the two downloads, Download project (.zip) and Download app (single .html). A coloured dot on the button tells you the state at a glance — green for Online, amber for Changes not published, grey for Taken offline.

Security check

In that same menu is Security check…. It reads the page your project builds and looks for the things that get a small site into trouble — a key or password written into the page, a form posting somewhere it should not, and the like — and lists what it found, each row with the line it sits on and a masked piece of the evidence.

Every row carries one of two pills. Must fix is a secret that anyone with the link could read: a service key, a private key, an API token, a live Stripe secret, a password written into the code. While one of those is there, publishing is refused — the panel opens in place of the usual confirmation, headed Publishing stopped, and nothing is uploaded. Worth a look is riskier code rather than a leak — eval, HTML built out of a variable, a plain http:// request, a link that opens a new tab without rel=noopener — and it never blocks you: the button simply reads Publish anyway.

Each row has Ask the AI to fix this, which closes the panel and hands the finding to the project chat, and Check again re-reads the page once you have fixed something. There is no button to dismiss a finding, on purpose. It costs no credits, and it is a safety net rather than a guarantee: it reads one built file against a fixed list of patterns and shows at most three examples of each.

It publishes nothing: on a live site it runs without touching the live copy. The menu entry only appears once your site exists, so before your first publish you cannot open it yourself — it opens on its own when a publish is refused, as explained below. If it finds something serious, the count appears next to the menu entry so you cannot miss it. Worth one run before you give the address to anyone.

Reading what it found

The result is a panel you can sit and read, not a message that vanishes. Every finding is one box, and each box carries:

A tag saying must fix or worth a look — the two never look alike, because only one of them stops you.
What it is, in plain words, and the line of the built page it is on.
The evidence, masked. You see enough to recognise the line, never the key or the password itself — the screen that shows you a secret in full is worse than no screen.
Ask the AI to fix this. Press it and the panel closes, the finding is written into your chat as a request, and the AI answers where you were already reading. It sends the masked version, so nothing secret ends up in your chat history.

At the bottom are Check again, which re-runs the scan against the build on screen, and — when everything found is only worth a look — Publish anyway.

One sentence sits on the panel in every state, including the all-clear one: this is a safety net, not a guarantee. It catches the common ways a secret ends up in a public page; it cannot promise your app is secure.

A must-fix finding stops the publish — and nothing was uploaded

The check is not only advice. A must-fix finding switches Publish off, and the panel says in words why the button is grey — Publish unlocks when the 1 must-fix item is gone.

You do not have to go looking for it either: if a publish is refused, this panel opens by itself, whether it was your first publish or an Update site on a live one. The first line it shows is the answer to the only question that matters at that moment — nothing was uploaded. Your live site, if you had one, is untouched and still serving the version it had.

Fix the finding — the Ask the AI to fix this link is the quickest route — and press Publish again. Things marked worth a look never block anything; you can publish past those whenever you like.

Renaming breaks the old link

Address & visibility… can change the address, and the dialog warns you what that means: the old link stops working the moment you save, so anything you have already sent to someone breaks. Pick the name you want early, and rename only when you must.

"Publishing is not switched on yet"

If Profile → My sites shows that sentence instead of your sites, publishing is not available on this VyroAI server at the moment — the part of the system that hosts sites has not been switched on yet.

It is not your account, and there is nothing to buy or enable. It also is not the same thing as an empty list: a working server with no sites simply says you have none. Nothing you built is lost; try again later, or ask on Discord whether it is expected.

Profile → My sites

Every site you have published is listed under Profile → My sites: the address, whether it is Online or Taken offline, when it was published, and Copy and Visit buttons on each row.

A site that is offline can be deleted from that list — the address then becomes free for anyone to take, while your project and its files are untouched. Taking a live site offline is done in the project itself, from the site menu described above.

Where to next

Next in Code Studio (IDE): Site & SEO
Nothing built yet: Web App Studio — Building the app you are about to publish.
A small fix first: The Visual Editor — Polishing the page by hand before it goes out.
Managing a live address: Settings — Where the My sites row lives in your profile.
If it will not publish: Build Errors & Preview Warnings — The other thing that keeps the button on Build.

11 of 37 in Code Studio (IDE) · Last checked 11 September 2026 · Previous: Giving an App a Backend