How to host a frontend website

Frontend hosting is asset hosting plus honesty about the server

A “frontend website” in modern usage usually means a browser UI: components, a router, maybe a design system, talking to APIs that live somewhere else. Hosting that UI is still static file hosting when you ship compiled HTML, JS, and CSS. The sophistication is in the build, not in the origin.

StaticHost is for that origin role. You bring production output from Vite, webpack, Parcel, or a static generator. You do not get a Node process, SSR runtime, or remote npm install. You do get HTTPS previews immediately, custom-domain certificates after DNS verifies, zip or GitHub ingest, and deploy history with rollback. nginx answers with try_files $uri $uri/ =404—no SPA soft-fallback.

If your frontend *requires* server rendering on each request, stop early and read when static hosting is the wrong choice. If you can ship a static export or a CSR bundle with sane routing, continue.

Choose an output shape

Multi-page or SSG output. Each route is a real HTML file (or directory index). This maps cleanly onto strict static hosting. Astro static builds, Next.js output: 'export', Hugo, Eleventy, and plain HTML all fit.

Client-rendered SPA with hash routing. One index.html, router uses #/…. Deep links work because the path the server sees remains /. Acceptable for many internal tools and simple apps.

Client-rendered SPA with history mode. Server path equals client route. On StaticHost those paths 404 unless files exist. Do not assume a Netlify-style _redirects or nginx try_files … /index.html. Prefer changing to hash routing or pre-rendering routes as files. Framework-specific notes: React, Vue, SPA guide.

Hybrid frameworks with adapters. Next without static export, SvelteKit without adapter-static, Astro with an SSR adapter—these need application hosting, not this product.

Local production build as the source of truth

Run the same command CI would run:

npm ci
npm run build

Inspect the output directory. Confirm index.html and hashed assets. Set base/homepage/publicPath so asset URLs match hosting at the domain root (typical base: '/' for Vite). Wrong base produces a beautiful blank page with 404 assets—common, fixable, and entirely on the build config.

Environment variables that start with your toolchain’s public prefix (VITE_, REACT_APP_, etc.) must be present at build time. StaticHost will not inject them later.

Ship the folder

Zip the contents of dist/build/out (not the parent). Nested zip mistake → guide.
GitHub from a branch that contains that output, or from CI that pushes artifacts. No remote npm on the host: git deploy.

Open the HTTPS preview. Test login redirects to external IdPs, API calls to staging backends, and one hard-refreshed deep link. Fix, rebuild, redeploy. Roll back from history if needed.

Frontend concerns that are still your job

API CORS. Your API must allow the preview origin and the production hostname. Updating CORS when you attach a custom domain is a frequent miss.

404 page. You can upload a custom 404.html if the platform serves it for missing files—verify behavior on preview. Do not confuse a custom 404 document with SPA fallback; they are different features. StaticHost does not turn unknown routes into your app shell.

Performance. Code-split, compress images, fingerprint assets. There is no built-in CDN product on StaticHost; see fast static site hosting and lightweight high-performance static hosting.

Auth. Token storage in the browser, PKCE against an IdP, or third-party auth widgets—all fine. Server sessions on this host are not a thing.

Plans for frontend teams

Starter ($9/mo): one site, 2 GB—enough for many marketing frontends. Pro ($30): three sites, 10 GB, staging—useful when “staging frontend” should not share production’s deploy history noise. Scale ($65) and Business ($130) raise site counts (10 and 30), storage (30 GB and 100 GB), and Business adds teams. Short trial ~1 day; no forever-free; no email; no cPanel.

Agencies shipping many microsites should skim static hosting for agencies. Solo UI engineers might start with host a dist folder online.

A sane definition of done

The frontend is hosted when:

Production build output is what the preview serves.
Asset URLs resolve on the preview hostname over HTTPS.
Deep links behave as designed (files or hashes), not as accidental 404s.
Rollback is tested once.
Custom domain certificate is issued only after DNS verification, without mixed content.

Everything else—component libraries, state management, design tokens—is application architecture, not hosting. Keep the boundary clear and the deploys stay boring, which is what you want from a file host.

Worked example: Vite React app with hash routes and staging API

npm create vite@latest shop-ui -- --template react-ts
cd shop-ui
npm ci

Set Vite base: '/'. Prefer hash-based routing for screens that are not prerendered. Bake the API origin at build time:

VITE_API_URL=https://api.staging.example.com npm run build
cd dist && zip -r ../shop-ui-staging.zip .

Deploy to a Pro staging target ($30/mo, 3 sites, 10 GB, staging). Open HTTPS preview. Confirm:

/assets/… JS/CSS return 200
Login redirect hits the external IdP with the preview origin allowed in CORS/redirect allowlists
Hard-refresh on /#/orders works
Hard-refresh on /orders 404s unless a file exists—expected under try_files $uri $uri/ =404

Promote by rebuilding with production VITE_API_URL and deploying production—not by rewriting strings inside minified JS on the server. Attach the custom domain only after preview sign-off; certificate follows DNS verification.

Failure table (frontend origins)

Symptom	Likely cause	Fix
Blank shell, JS 404	Wrong `base` / nested zip	Fix Vite `base`; zip `dist` contents
API works locally only	CORS missing preview/prod origins	Allowlist both hostnames on the API
Deep link 404	History router without files	Hash router or prerender routes
Staging data in prod	Wrong env bake	Rebuild with production public env
Users stuck on old UI	Service worker cache	Version SW; test on preview HTTPS
“Deploy” is only `src/`	Never ran production build	`npm run build`; upload output

StaticHost will not run Express middleware, SSR adapters, or remote npm. Starter $9 (1×2 GB) suits many marketing frontends; Scale $65 and Business $130 raise caps and teams. Trial ~1 day; no forever-free, email, cPanel, or built-in CDN product. Related: static hosting for JavaScript apps, host a dist folder online.

FAQ

Can I host a frontend that calls a GraphQL API?

Yes. The API stays elsewhere; the browser calls it. Configure CORS for your StaticHost preview and custom domains.

Will StaticHost run my Express middleware?

No. Only static files. Middleware belongs on an application server you operate separately.

Is staging a separate site?

On Pro and above you get staging capabilities suited to treating a non-production frontend as its own deploy target. Use it for QA builds with staging API URLs baked in.

Do I need Docker to host a frontend here?

No. Build on your machine or CI, upload output.

What about service workers?

You can publish a service worker file. Scope and caching strategies are yours to get right; a misconfigured worker can pin old deploys in browsers—plan versioning and update hooks carefully.