Deploy means replace the live file tree on purpose

“Deploy” is a sharper word than “upload.” Uploading is moving bytes. Deploying is making a new tree the one visitors receive—and keeping the previous tree available so you can undo the decision. On StaticHost, that is the product loop: publish HTML (and its CSS, JS, and media), preview on HTTPS, promote a custom domain when ready, roll back from deploy history if needed.

This guide focuses on the deploy act itself: what to send, how to send it, how to verify, and how to recover. For a broader hosting overview see how to host a static website. For absolute beginners assembling files, use how to put an HTML website online.

Know the artifact

Your deploy artifact is a directory that already works as a static site root.

Hand-written sites: the folder with index.html. Generator sites: only the output (dist, build, public, _site), never the source plus node_modules unless you intentionally publish them. StaticHost will not run npm run build, bundle exec jekyll build, or hugo on the server. If the HTML is not on disk before you deploy, it will not appear after.

SPAs deserve a special preflight. nginx here is try_files $uri $uri/ =404 with no SPA fallback. A React Router or Vue Router history-mode URL like /app/settings returns 404 unless that path exists as a file. Hash routing or SSG file emission is required. Do not invent a rewrite in your head; the server will not grow one for you.

Two ingest paths

Zip deploy. Build or save locally, compress the site root contents, upload in the dashboard. Best when deploys are occasional or when the producer of the HTML is a designer export, not a CI pipeline. Failure mode to avoid: nesting—see zip a static site without 404.

GitHub deploy. Connect a repository and deploy from a branch that already contains the files to serve. If your repo is source-only, either commit build output to a gh-pages-style branch, or run the build in *your* CI and push artifacts to the branch StaticHost reads. The platform does not run npm ci remotely. Procedure notes: git deploy a static site.

Pick one path per site and stick to it for a while. Oscillating between a manual zip and an old Git commit is how teams lose track of what is live.

A deploy runbook

  1. Freeze the change. Know the commit SHA or local folder timestamp you intend to publish.
  2. Produce the tree. Run the production build if any. Confirm index.html at the root of what you will send.
  3. Ingest. Upload the zip or push/reconnect so GitHub deploy picks up the artifact branch.
  4. Preview on HTTPS. Open the preview hostname immediately—TLS is available without your custom DNS. Click primary user journeys.
  5. Asset audit. In DevTools Network, confirm CSS/JS return 200 from your origin, not 404.
  6. Route audit. For multi-page HTML, hit each linked document. For SPAs, hit a nested client route; expect 404 unless you planned for it.
  7. Record. Note the deploy in your changelog or ticket. Deploy history on the host is the safety net; your note is the human context.
  8. Domain (when applicable). Only after preview is good should you care about custom domain cutover. Certificates issue after DNS verifies.

If step 4 or 5 fails, do not “fix forward” blindly on production DNS. Roll back, fix the artifact, deploy again.

Rollback is part of deploy

A deploy process without rollback is a hope process. StaticHost keeps deploy history so you can restore a previous upload when the new tree is wrong—broken paths, accidental draft content, oversized assets that somehow replaced optimized ones.

Practice rollback once on a throwaway change so you know where the control is before an incident. Agencies and freelancers should treat that drill as onboarding; see static hosting for agencies for multi-site habits that pair with staging on Pro and above.

Environment and secrets reality check

Anything in a static deploy is potentially public. API keys embedded in frontend bundles are visible to anyone who downloads the JS. Deploy does not encrypt away bad secrets management. Use publishable keys only, restrict them at the provider, and keep private secrets in server-side services that are not StaticHost.

Likewise, .env files must not ride along in the zip. Build tools bake VITE_ or REACT_APP_ prefixed values into the bundle at build time on your machine; the host only serves the result.

Frequency and plans

Deploy as often as the content demands. Storage and site counts are plan-bound: Starter $9/mo (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams). Short trial ~1 day; no forever-free. No email, no cPanel, no built-in CDN product—deploy is about files, not a control panel suite.

Worked example: hotfix a typo without DNS drama

You notice Acme Copration on the live marketing page. DNS and certificates are already fine—this is not a domain problem.

  1. Pull or open the same folder that produced the last good deploy.
  2. Fix the typo in index.html (or the generator source, then rebuild).
  3. Zip only the site root contents; confirm unzip -l shows index.html at the top level.
  4. Deploy; open HTTPS preview; search-in-page for both the typo and the correction.
  5. If preview is wrong, roll back immediately and repeat. If preview is right, you are done—custom domain traffic already points at the site and will serve the new tree after the deploy completes.
  6. Do not “touch DNS to force refresh.” DNS will not fix HTML typos and can break mail if you edit MX by mistake.

That loop is the entire value of file-oriented hosting: small blast radius, reversible publishes, no server SSH for a one-word change. Pair with static hosting with free SSL only when the problem is mixed content, not copy.

If you need PHP or WordPress runtime deploys, that is a different host category entirely.

After the first good deploy

Automate only what you already do carefully by hand. A GitHub Action that builds and pushes artifacts is valuable once the local build is correct. A script that zips the wrong directory faster is not an improvement.

Keep one canonical build command in the README. Pin Node or Ruby versions. Re-read how to publish HTML CSS JavaScript files when onboarding someone who thinks “deploy” means editing on the server.

FAQ

Is a deploy the same as saving a file over FTP?

Conceptually similar (replace remote files), operationally cleaner: atomic-ish site publishes, HTTPS preview, and history/rollback instead of partial FTP overwrites.

Can I deploy only one changed HTML file?

You publish a site tree. In practice you re-upload the full artifact. That avoids drift between partial uploads and what you tested locally.

Why did my deploy succeed but the page look old?

Browser cache, a CDN in front you added yourself, or you deployed a different folder than you edited. Hard-refresh and confirm the preview URL matches the site you think you updated.

Does deploy run database migrations?

No. There is no application database on StaticHost. Static files only.

What if GitHub deploy picks source instead of build output?

Point the integration at a branch that contains the built HTML, or change your CI to emit that branch. The host will not compile source for you.