Publishing means shipping the build artifact

A frontend website is usually HTML plus CSS plus JavaScript that the browser runs. Publishing it is not “connecting the repo so the host can invent a build.” On StaticHost, publishing means you already have the files visitors should receive, and you put those files on the platform. Zip upload or GitHub of the built tree—both are fine. Remote npm ci, Hugo, and Jekyll do not run here.

nginx serves with try_files $uri $uri/ =404. Deep history-mode routes without matching files return 404. There is no email product, no forever-free plan after the short trial, and no add-on CDN console as part of the SKU. Prices are $9 / $30 / $65 / $130 for Starter through Business.

Portfolio-shaped frontends and simpler HTML flows overlap; see where to host a static portfolio and easy hosting for an html website when you need decision framing instead of this procedure.

Numbered publish procedure

  1. Produce the production tree locally. For a bundler: npm run build (or your equivalent) on your machine. For plain HTML: the folder you already edit. Confirm index.html is at the root of what you will upload.
  1. Sanity-check paths. Open the built index.html and confirm script and link tags point at files that exist beside it. Prefer root-relative or same-folder relative paths that survive being served from /.
  1. Choose zip or GitHub. Zip for occasional publishes. GitHub when a branch holds the built files and you want push-to-refresh. Either way you ship files, not a build recipe for the host to interpret.
  1. Create the site on a plan that matches count and storage. One brochure frontend: Starter at $9 and 2 GB. Three properties or staging: Pro at $30. Ten or thirty sites: Scale ($65) or Business ($130).
  1. Deploy and open HTTPS preview immediately. Preview certificates do not depend on your DNS. This is your acceptance environment.
  1. Exercise the UI. Home, critical JS hydration, fonts, images, and any client router paths that must work. Missing files are 404s—fix locally and redeploy.
  1. Attach the domain after preview sign-off. Dashboard records → your DNS provider → wait for verification → wait for the custom-host certificate. Retest the padlock and mixed content.
  1. Declare published. Preview correct, optional custom hostname HTTPS, rollback available via deploy history.

Skip: uploading the repo root with src/ and node_modules instead of dist/. Skip expecting mailboxes. Skip flipping DNS during the first broken deploy.

Non-developers following a designer’s zip can stay on the same rails—static website hosting for non developers covers that audience without changing the file contract.

What to skip while publishing

Skip platform build plugins. Skip .htaccess PHP tricks. Skip “temporary” SPA fallback fantasies; this host will not add them. Skip forever-free comparisons that ignore commercial staging and site quotas. Skip announcing @you@yourdomain mail until a real mail host is configured—publishing the frontend does not create inboxes.

Worked example: weekend sale frontend page

Marketing wants a lightweight frontend for a weekend flash sale: animated countdown in vanilla JS, a sticky CTA bar, and a CSS theme matching the brand kit. No framework required, but the same steps apply if Vite emitted the folder.

Local output after you finish editing:

flash-frontend/
  index.html
  assets/countdown.js
  assets/theme.css
  assets/logo.svg

You publish by zipping flash-frontend/ contents and uploading. Preview shows the countdown ticking and the CTA scrolling into view. The form posts to an external ESP endpoint already used by the brand.

You do not ask StaticHost to send the “sale starts” email. You do not create sales@ on the web host. MX stays with the existing mail vendor. The frontend’s job is the page; mail is another product.

Friday cutover: DNS only after the preview matches the approved copy deck. Certificate issues after DNS verifies. If the countdown timezone is wrong, fix countdown.js locally, redeploy, keep the previous build in history until the new one is confirmed.

Failure: expecting email mailboxes from web hosting

Frontend publishers who came from shared cPanel hosts often scan the dashboard for “Email Accounts.” StaticHost does not offer them. The failure mode is subtle: DNS for the website is pointed correctly, the page is live, and someone creates an A record mindset for mail or deletes MX records “to clean things up,” or they assume contact forms need a local sendmail binary.

Symptoms: mail to hello@yourdomain bounces; form libraries that expected server-side PHP mail fail; support threads mix “site is up” with “inbox is dead.” None of that is a StaticHost outage. The host serves files. Outbound transactional email belongs with an ESP. Mailboxes belong with Google Workspace, Microsoft 365, Fastmail, or similar. Keep MX independent of the web host decision.

If your “frontend” is actually a PHP contact script that writes to a local mailbox, you chose the wrong host class. Static publishing assumes the browser and third-party APIs do the dynamic work.

What done looks like

  • Built files on the host match what you tested locally.
  • HTTPS preview loads JS and CSS without console 404 storms.
  • Client routes you care about either have files or use hashes.
  • Custom domain optional but, if used, verified with a certificate.
  • Nobody thought publishing the site created employee inboxes.

That is a published frontend website.

Questions people actually ask

Does StaticHost run my Vite or webpack build?

No. Run the build where you develop, then upload dist (or your configured outDir). GitHub deploys still expect the files to already be present in the connected tree.

Can I host a history-mode SPA?

Only if every route exists as a file or you switch to hash routing. There is no try_files fallback to index.html—unknown paths are 404.

Is there a free plan for side-project frontends?

There is a short trial (~1 day), then paid plans starting at $9/mo. There is no forever-free tier.

Where do contact form submissions go?

To whatever external endpoint you configured (form service, serverless API elsewhere). The static host will not process POST bodies into mailboxes.