Publishing

Nothing you build is live until you publish it. That line is the whole safety model: building, editing, and previewing are free and private; publishing is the one deliberate act that puts something in front of the world.

#Drafts vs. live

Everything has two states:

• Draft: the version you're working on. Private, free to change, visible only to you and your team. You can preview it exactly as it would serve.
• Published: the version your visitors get. It changes only when you publish a new one.

Because the two are separate, you can edit a live page's draft all day without touching what visitors see, then publish once when it's ready. Nothing goes live by accident.

#Versions

Most pieces (workflows, endpoints, schedules, schemas) keep a history of versions. Each published version is frozen; to change a live one, a new version is created and published, and the old one keeps serving until that moment. This means you can always see what's live, and roll forward deliberately. Each studio has a version dropdown: you can select any earlier frozen version and publish it again, so undoing a bad publish is simply re-publishing the last good one.

Content records are simpler: they don't keep a version chain. You edit the draft and publish it. After you publish one, its editor shows the public URL it serves at, plus a small marker when your current draft differs from what's live: an at-a-glance "you have unpublished changes." (Publishing a content record also pushes a copy to a fast delivery network, for pages that load their data directly in the browser. Your agent handles that distinction.)

#When a change actually shows

Two things sit between "I published" and "a visitor sees it":

1. Propagation. Publishing rolls out across the network within a short window, usually seconds. A rename or takedown is the same.
2. Caching. If a page has a cache window, visitors keep getting the cached version until it expires, then the next visit picks up your change. A page with caching off updates immediately. This is a deliberate trade: caching makes a site fast and cheap at the cost of a little staleness.

One thing to know about data: when a page loads a published datafile directly in the browser (the "load the fast-changing bits separately" pattern), that data has its own short cache on the delivery network (about a minute) that a page's cache setting doesn't control. So even a page with caching off can show just-republished data up to roughly a minute late. It catches up on its own; there's nothing to do but wait out the minute.

So if you publish and don't see the change, it's almost always the cache: wait out the window, or your agent can shorten it on pages that must be fresh.

#Publishing won't ship something broken

When you publish a page, Tessryx first checks that everything it depends on actually resolves: the logic exists, the integrations are wired, the data is there. If something's missing, the publish is refused with a clear reason rather than putting a live error in front of visitors. Saving a draft is never blocked this way; you can build in any order and publish once it holds together.

#Taking something down

Unpublishing removes the live version and leaves your drafts intact: the page goes offline, nothing is deleted, and you can publish again later. Deleting is separate and permanent.

Publishing an app is not the same as publishing its pages. Publishing an app promotes the grouping; the pages, schedules, and endpoints inside it each go live on their own when you publish them.