Publishing your website
Say "publish" and Steve puts your site on a real public URL — <slug>.unyo.site, with an HTTPS certificate provisioned automatically. Choose your subdomain, republish after edits, take it offline for free.
Esta página aún no está disponible en tu idioma, mostramos la versión en inglés.
You built a site with Steve. It runs in the preview panel. Now put it on the internet.
Say "publish my site" and Steve deploys it to a real public URL — <slug>.unyo.site — with an HTTPS certificate provisioned automatically. No DNS records, no hosting account, no deploy pipeline, no CLI. One sentence.
Publishing is never automatic
Steve is instructed never to publish on his own initiative — it's a paid, public, outward-facing action, and he only takes it when you explicitly ask ("publish", "put it online").
What publishing gives you
- A real public URL.
your-slug.unyo.site, reachable by anyone, with a valid TLS certificate provisioned for you. - Your choice of subdomain. Ask for one, or let Steve derive it from your site's name.
- A stable address. Republishing after edits reuses the exact same URL — links you've shared keep working.
- A visible state. The builder panel tells you whether your live site matches what you're looking at.
- A free exit. Unpublishing costs nothing and takes the site offline immediately.
Publish your site
- Open your Steve conversation — the one that contains the site you want to publish.
- Make sure the site is what you want. Publishing deploys the current saved files, exactly as they are.
- Ask Steve to publish it, and name your subdomain if you have one in mind.
- Steve deploys, attaches the domain, and gives the certificate a moment to come up before handing you the link. This takes seconds, not hours — occasionally the URL needs one reload while the certificate finishes propagating.
- Click the URL in the panel header. That's your live site.
Choosing a subdomain
Your slug is the lauras-bakery in lauras-bakery.unyo.site. Rules:
| Rule | Detail |
|---|---|
| Length | 3 to 40 characters |
| Characters | Lowercase letters, numbers and hyphens |
| Hyphens | Not at the start, not at the end, never doubled (--) |
| Uniqueness | Global — first come, first served across all of Unyo |
| Reserved | A list of names is off-limits — www, api, mail, login, shop, checkout, brand names and similar |
If you don't pick one, Steve builds a slug from your site's name — accents stripped, spaces collapsed to hyphens, capped at 30 characters. If it's already taken, he appends a number (lauras-bakery-2) rather than failing.
Republishing after an edit
This is the part most people get wrong, so it's worth being blunt:
A published site is a snapshot, not a live mirror
Editing your site in the chat updates your project and your preview. It does not update the live site. The world keeps seeing the old version until you say "republish". There is no continuous deployment, and that's deliberate — you decide when the public sees a change.
The panel makes this impossible to miss: a green badge appears once your site is published, and an amber badge appears the moment you edit a site that's live. It's the panel saying: what you're looking at is not what the world sees.
Say "republish" and the amber badge clears. Same URL, new content.
Taking a site offline
Say "unpublish". The site comes down immediately and the subdomain starts returning a 404. It costs 0 credits.
Your project isn't touched — the code, the files and the preview all stay exactly where they were. Unpublishing removes the public deployment, not your work. You can publish it again later (that's a fresh publish, so it's charged as one).
The secret scan
Before anything is deployed, Steve scans your files for backend secrets. If one is found, the deploy is refused — the site does not go up, and you're told which file is the problem.
This is a fail-closed check, on purpose. A published site is a public directory: anything in it is readable by anyone who views source. A leaked server key is not a bug you can fix by deleting the page later.
What gets your deploy refused:
- Private keys (
-----BEGIN … PRIVATE KEY-----) - Service-role keys,
sk_live_-style secret API keys, provider tokens (shpat_,xoxb-,ghp_,AKIA…,ya29.…, and similar) - Platform tokens for the infrastructure Unyo itself runs on
What does not get refused: the public keys a front-end legitimately needs — a Maps or Firebase web key, a public anon key. Those are designed to be in the page. The scan targets unambiguous server-side secrets only.
Steve can't build a backend anyway
Steve builds static front-end sites — HTML, CSS and JavaScript. There's no server, no database and no server-side code, which means there's normally no reason for a server key to be in your project in the first place. If the scan fires, something got pasted in that shouldn't have been.
What each action costs
| Action | Credits | |
|---|---|---|
| Publish (first time) | 50 | Deploy + domain + certificate |
| Republish | 25 | Same URL, new content |
| Unpublish | 0 | Free, instant |
| Build a site | 25 | For reference |
| Edit a site | 15 | For reference |
| Read your own code | 0 | Free |
| Restart the preview | 0 | Free |
Every one of these actions is refundable on error: if a deploy fails, you are not charged for it.
See Credits and billing for how credits work, and Building a website with Steve for everything that happens before you publish.
Limits worth knowing before you publish
.unyo.sitesubdomains only. Custom domains aren't supported. You cannot pointlauras-bakery.comat a Steve site.- Static front-end only. HTML, CSS and JavaScript. No server, no database, no login, no API routes, no build step.
- Snapshots, not continuous deployment. Edits require an explicit republish.
- No version history. Only the current state of your project is stored — there's no rollback to a previous publish.
- One site per conversation. Asking for a second site in the same Steve conversation replaces the first. Start a new conversation for each site.
- Project caps: 40 files, 512 KB per text file, 12 MB per project.
If any of that is a dealbreaker, you can still export your site as a ZIP (10 credits) and host it yourself, anywhere you like. The code is yours.
Tips
- Publish early, republish often. A first publish is 50 credits; every update after that is 25. Getting the URL live early costs you nothing extra later.
- Pick your slug deliberately the first time. Changing the subdomain later means publishing to a new address — the old one won't redirect.
- Trust the amber badge, not your memory. If it's showing, the public version is stale.
- Check the live URL, not just the preview. The preview is your sandbox; the published site is the deployed snapshot. They're different things by design.
- Unpublish is free — if you're not sure the site is ready for the world, take it down and put it back up when it is.
Can I use my own domain name?
Not today. Published sites live on <slug>.unyo.site subdomains only — there's no way to attach yourbrand.com. If you need your own domain, export your site as a ZIP (10 credits) and host it wherever you like; the files are plain HTML, CSS and JavaScript and will run on any static host.
I edited my site — why is the live version still the old one?
Because publishing takes a snapshot. Editing updates your project and your preview, but the deployed site stays frozen at whatever you last published. The amber unpublished changes badge in the panel is telling you exactly this. Say "republish" and the live site catches up — same URL, 25 credits.
Will Steve ever publish my site without me asking?
No. Publishing only happens when you explicitly ask for it — "publish", "put it online". Steve is instructed never to publish on his own initiative, because putting something on the public internet is an outward action with a cost, and those are never taken on your behalf. The same goes for republishing.
What happens to my published site if I delete my Unyo account?
It comes down first. Account deletion reads every published site you own and takes each one offline before purging your data — so erasure covers what's on the public internet, not just what's in the database.
Does unpublishing delete my site?
No. Unpublishing removes the public deployment; your project, your files and your code stay exactly where they are in the conversation. You can keep editing, and publish again whenever you want (a new publish is charged at 50 credits, and your site goes back up at the same subdomain).
Someone already took the subdomain I wanted.
Slugs are globally unique across Unyo — first come, first served. Pick another, or let Steve derive one and add a suffix (lauras-bakery-2). Some names are also permanently reserved: infrastructure words like www, api or mail, commerce words like shop and checkout, and well-known brand names.
Troubleshooting
"The deploy was refused because of a secret." A file in your project contains something that looks like a server-side key. Ask Steve to show you the file, remove the key, and publish again. Public front-end keys (a Maps key, a public anon key) don't trigger this — if it fired, look for a genuine server secret.
"My slug was rejected." Check the rules above: 3–40 characters, lowercase letters/numbers/hyphens, no leading or trailing hyphen, no double hyphen. It may also be reserved or already taken. Ask Steve for a different one.
"The URL doesn't load right after publishing." Steve waits for the certificate to be usable before giving you the link, so this is rare. If it happens, give it a few seconds and reload — certificate propagation isn't instant on every network.
"The published site looks different from my preview." Almost always the snapshot gap: you've edited since publishing. Look for the amber unpublished changes badge and republish.
"My preview says it's restarting." That's unrelated to publishing and completely normal. Previews are temporary and get rebuilt from your saved files when you open the Preview tab — it's free and takes a few seconds. Your published site is unaffected; it stays up regardless of the preview.