What you are actually hosting

A static website is a set of files: HTML documents, CSS stylesheets, JavaScript bundles, images, fonts, and whatever else your build produced. The server does not execute application code to generate those pages on each request. It reads a file from disk and returns it. That is the whole contract, and it is enough for portfolios, documentation, marketing pages, and many JavaScript frontends that talk to APIs elsewhere.

StaticHost is built for that contract. You upload finished output—hand-written HTML or the dist/public/_site folder from a generator—and nginx serves it. There is no remote npm install, no Hugo binary on the host, and no Jekyll runtime. If your workflow still needs a build step, you run it on your laptop or in your own CI, then publish the result. That split keeps the hosting surface small and predictable: what you tested locally as a file tree is what visitors receive.

This guide walks through hosting that result end to end: prepare files, choose an upload method, verify HTTPS, attach a domain if you want one, and roll back when a deploy goes wrong. If you are still deciding whether static hosting fits at all, pair this with what static hosting is and when static hosting is the wrong choice.

Prepare a deployable tree

Before you touch the host, confirm the folder you will upload is a complete site root.

  • There must be an index.html at the top of the upload (or a clear entry document the browser can request at /).
  • Relative asset paths must resolve from that root. A broken ../css/site.css that worked from a nested preview path will fail once the site is served from /.
  • Do not upload a parent folder that contains only one subdirectory. If your zip extracts to mysite/index.html nested one level too deep, visitors hit an empty or confusing root. Zip the *contents* of the build folder, not the folder’s parent. See zip a static site without 404 if you have already made that mistake.
  • If you use a bundler, run the production build locally (npm run build, hugo --minify, and so on) and upload only the output directory. Source maps and node_modules do not belong in the public tree unless you intentionally want them public.

StaticHost does not rewrite unknown paths to index.html. The nginx layout is effectively try_files $uri $uri/ =404. Deep client-side routes without matching files return 404. Plan for hash routing or a file per route before you publish an SPA. That single constraint causes more surprise deploys than any DNS issue.

Treat the upload as a release artifact. Name the zip with a date or git SHA if you keep local archives. When something regresses, you want to know exactly which tree went live.

Create the site and deploy

  1. Sign up and start a site on a plan that matches how many projects you need. Starter covers one site and 2 GB for $9/mo; Pro is $30 for three sites, 10 GB, and staging; Scale is $65 for ten sites and 30 GB; Business is $130 for thirty sites, 100 GB, and teams. Full comparison: static website hosting pricing.
  2. Prefer zip upload when you want a one-shot publish from a local folder. Prefer GitHub when a branch that already contains built artifacts should redeploy on push. Either way, you are shipping files—not asking the platform to compile them. Details for Git-oriented flows: git deploy a static site.
  3. After upload, open the HTTPS preview URL immediately. TLS on the preview hostname is available without waiting on DNS. Use that URL to click every critical path: home, CSS/JS assets, images, forms that post to third parties, and any deep links you care about.
  4. If something is wrong, fix locally, rebuild if needed, and deploy again. Deploy history lets you roll back to a previous good upload instead of scrambling to recreate it by hand.

Keep the first deploys boring. A correct index.html and a stylesheet that loads beat wiring a custom domain on day one. Preview until the file tree is trustworthy.

Custom domains and certificates

When the preview looks right, point your domain at StaticHost using the DNS records shown in the dashboard. After DNS verifies, the platform issues the certificate for that hostname. Until verification succeeds, keep sharing the preview URL; do not assume HTTPS on the custom name is live.

Watch for mixed content once the custom hostname is on HTTPS: hard-coded http:// asset URLs will break or warn. Prefer HTTPS asset links or relative paths under your own origin. Expand on DNS and TLS in static hosting with a custom domain and static hosting with free SSL.

If you are moving from another host, lower TTLs a day ahead, deploy to StaticHost first on preview, then flip DNS. Rollback on the new host is cheap; DNS mistakes are slower to unwind.

What StaticHost deliberately does not do

Honesty saves time:

  • No cPanel, no mailbox, no forever-free tier. There is a short trial (about a day), then paid plans. See free vs paid static hosting for an honest comparison with forever-free options like GitHub Pages.
  • No built-in edge CDN product layered on every site. Fast responses still come from serving small static files well; read fast static site hosting for practical expectations.
  • No server-side PHP or WordPress. If you need a CMS that runs on the server, use a different kind of host—not a static file platform stretched into an application runtime.

Those boundaries are the product. You get deploy history, HTTPS previews, GitHub or zip ingest, and nginx that serves what you uploaded—nothing more dressed up as magic.

Operational checklist after go-live

  • Bookmark preview and production URLs; know which deploy is live.
  • Store the exact build command and toolchain versions in the repo so the next publish matches the last one.
  • For SPAs, hard-refresh a nested client route. A 404 is expected unless you generated real files or switched to hash routing.
  • Prefer small deploys plus rollback over large untested drops for pages that change weekly.
  • If you outgrow one site or need staging, move up a plan rather than stuffing unrelated builds into one project. Agencies often land on Pro, Scale, or Business for that reason—see static hosting for agencies.

Hosting a static site well is discipline about what you upload and how you verify it. The platform makes that upload reachable over HTTPS and reversible. You ship a coherent file tree.

FAQ

Do I need to know nginx to host here?

No. You upload files; the host serves them. You do need to understand that missing files 404, including SPA history-mode paths that never existed on disk.

Can StaticHost build my Vite or Hugo project for me?

No. Build locally or in CI, then upload the output. The server will not run npm or hugo for you.

Is the preview URL good enough for client review?

Yes for content and layout. Attach the custom domain when branding and final URLs matter, after DNS verifies and the certificate is issued.

What if I need email or WordPress later?

Email and server-side CMS hosting are outside this product. Keep the static site here and use a different host for mailboxes or PHP applications.

How do I undo a bad deploy?

Use deploy history and roll back to a previous upload. Fix the source tree locally before publishing again so you do not oscillate between two broken builds.