Build the Site Here,Put It on a Real Address

Preview builds the site and serves it exactly as a static host does, which is not what a dev server does. A dev server sends every unknown address to your home page and papers over a wrong base path. A real host does neither. So the preview will 404 on a link that the dev server renders happily, and that is the point: it is the same 404 your visitors would have got.

• A folder of HTML needs no build and no Node
• Astro, Vite, Next, Nuxt, SvelteKit, Remix and Gatsby are built for you
• Deep links behave the way they will once published
• Publishing builds the site first, so previewing is never a prerequisite
• The build output appears inline when a build fails
• The "site is live" message links the preview in Plexon's own browser, where edits show up right away
• Publishing a plain folder starts a git repository in it, so Source Control tracks the site from the first publish
• A site the assistant builds gets its own folder under whatever workspace you have open, so Desktop works as-is and one workspace can hold several sites, each listed in Source Control

One button puts the running preview on a public address. No account, no token, nothing to sign up for. Send it to a client, watch them click it, change something and they see it. The link is honest about itself: it stops working when you close Plexon, and the address is different next time.

• Works with no account of any kind
• The caveat is on screen, not buried in a help page
• Add an ngrok domain in Settings to keep one address
• Closing the preview closes the link with it

Plexon creates the repository, writes the deploy file, pushes, turns on GitHub Pages, and follows the build. You are asked the two questions that actually decide whether it works, before anything is built: which repository, and whether the files are private. A private repository needs GitHub Pro or Team, and it does not make a private website: only the source stays private.

• The deploy file is shown before it is pushed
• Edit it and Plexon leaves your version alone from then on
• The progress line names the job and step in flight
• Publishing twice does not publish twice
• Unpublish turns Pages off and keeps the repository; Remove turns Pages off, forgets the site, and leaves the repository yours

A green build is not proof a site works. When the deploy finishes, Plexon fetches the published address and requires a real response before it tells you the site is live. If the build fails instead, the message names the job and the step, so you get "the deploy failed at build, npm run build" rather than "the workflow failed".

• Success is measured at the address, not in the build log
• A deploy waiting on a person says so, instead of spinning
• Failures name the step, not the workflow
• The run log is never copied into your chat
• An in-app browser showing the site refreshes itself when a publish lands

Three ways a static site breaks while every status stays green. An asset folder starting with an underscore that the host skips, so the page loads with no styles at all. A site built for the wrong base path, so the HTML arrives and every asset 404s. A browser-routed app with no fallback page, so every link except the home page is dead. Plexon checks for all three before it pushes.

• The underscore-folder trap that leaves a page unstyled
• A base path that does not match where the site will live
• Deep links that would 404 once published
• A credential file about to become public

When your company provides hosting, none of the above is your problem. You type a name and press Publish. There is no account to create, no token to paste, no repository to choose and no DNS to set. The repository is created in a GitHub organization your company owns, which they control and can disconnect at any time, and the address is assigned to you.

• A name is the only thing you are asked for
• The repository belongs to your company, not to Plexon
• Your company can disconnect Plexon from their own GitHub settings
• Keep the project source in the same repository, if you want it there
• The published site is public, the same as any GitHub Pages site
• Each repository names its site and links the live address, so the organization reads as a site directory
• Unpublish takes the site offline and keeps everything; Publish brings it back
• Remove deletes the site and its repository, so the name is yours to use again
• Taking your site down is yours to do, from the app, from chat, or from your account page

Add a domain and Plexon shows the exact records to create, with the right shape for the kind of name: one record for a subdomain, eight for a bare domain, because a shortcut that works for one is invalid for the other. Then it checks, and it names the two failures that look like nothing is wrong. If your project already carries a CNAME file, Plexon publishes to that domain. On its own that file does nothing, which is the kind of surprise that costs an afternoon.

• A subdomain points at your account, never at the repository
• A bare domain needs all eight address records
• A CNAME file your project already has is used, not ignored
• A proxy in front of the domain blocks the certificate
• A certificate still being issued is not a broken one