Static website hosting without server management

The hidden job description of “just a VPS”

A static site on a virtual machine sounds cheap until you inventory the work: OS updates, nginx config, firewall rules, fail2ban or equivalent, certificate renewal, disk alerts, timezone drift on cron, and the 2 a.m. mystery when ufw blocked your own deploy IP. None of that improves the HTML. It only keeps the HTML reachable.

Static website hosting without server management means someone else owns that inventory. You own the files. StaticHost is one expression of that deal: upload a zip or connect GitHub, get HTTPS on a preview hostname immediately, attach a custom domain whose certificate appears after DNS verifies, and roll back through deploy history. You never SSH in to “fix nginx.”

What you give up on purpose

No root shell. No apt. No ability to install Redis beside the site “just for a minute.” No PHP-FPM. No mailbox stack. No cPanel. Those absences are the point. If you need them, you need a managed application host or a VPS—and you should budget the management time honestly.

You also give up remote builds. StaticHost does not run npm, Hugo, or Jekyll. Build on your laptop or in CI you control, then publish output. That keeps the host’s attack surface and failure modes small: disk, TLS, file serving.

What “managed” still leaves on your desk

Content correctness. Broken relative paths are yours. Nested zip folders are yours—zip carefully.

Routing model. try_files $uri $uri/ =404 means SPA history routes 404 without files. No ticket to support will invent a rewrite that the product does not offer. Plan hash routing or SSG files—SPA guide.

DNS. You still create records at the registrar. The platform verifies them and then issues certificates. Guide: custom domain.

Secrets in the browser. Static files cannot hide private keys. Architecture still matters.

Capacity planning. Pick a plan for site count and storage: Starter $9/mo (1×2 GB), Pro $30 (3×10 GB + staging), Scale $65 (10×30 GB), Business $130 (30×100 GB + teams). Short trial ~1 day; no forever-free.

A week in the life: VPS versus StaticHost

VPS week. Patch Tuesday residual updates. Certbot renewed but nginx failed to reload silently. Staging is a second VM you forgot to snapshot. Rollback is git reset plus rsync hope. Someone asks for email forwarding; you accidentally become a mail admin.

StaticHost week. Edit, build, deploy. Preview on HTTPS. Staging on Pro as a separate flow. Rollback from history. Email request gets answered with “different vendor.” The HTML still shipped.

That comparison is unfair to professional platform teams who automate VPS fleets well. It is extremely fair to solo developers and small agencies whose comparative advantage is design and frontend, not init systems. Related audience notes: agencies, designers.

Security without becoming a sysadmin

A static origin has no WordPress admin to spray, no SQL database to ransom on that box, and no SSH password to brute-force if SSH does not exist for you. You still must keep dependencies sound in your *build* environment, avoid publishing .env, and treat XSS in your own JS with respect. Hosting without server management is not hosting without security thinking; it is security thinking moved upward into the artifact and the third-party APIs you call.

When you should still manage a server

You co-locate APIs, workers, and the website on one machine by policy.
Compliance demands a specific network architecture you must control hop by hop.
Your “static” site is actually a PHP monolith in denial.

Otherwise, paying for file hosting is usually cheaper than paying for your own attention. Attention is the scarce resource; StaticHost prices sites and gigabytes, not surprise pages of nginx.

Getting started without ops theater

Produce a clean site root (index.html at top).
Deploy via zip or GitHub artifact branch.
Verify on HTTPS preview.
Add domain; wait for DNS verification and certificate.
Document the build command in README so humans, not servers, reproduce it.

Broader how-to: how to host a static website. Shopping context: where to host a static website.

A realistic week shipping static website hosting without server management

Monday starts with a broken relative CSS path that only appears once the files leave a designer’s laptop. You flatten the zip so index.html sits at the archive root, redeploy to StaticHost, and HTTPS preview finally matches local intent. Deploy history supports rollback when a publish goes wrong.

Wednesday adds a custom domain. DNS is created exactly as the dashboard specifies; verification lags an hour; the certificate appears afterward. Someone asks whether email is included—you point them at a mail vendor and keep MX untouched. WordPress/PHP needs a different kind of host.

Thursday an engineer enables history-mode routing for a “cleaner URL.” Refresh on a nested path 404s. You revert to hash routing for the week’s deadline and schedule prerender work properly instead of inventing an nginx rewrite StaticHost will not apply. StaticHost serves prebuilt files via zip or GitHub and does not run npm, Hugo, or Jekyll remotely.

Friday staging on Pro receives a build with staging API URLs baked via public env prefixes. Production stays on last week’s known-good deploy until Monday’s review. Rollback remains one click if marketing’s late copy drop breaks mobile layout. Plans: Starter $9 (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams).

nginx behaves like try_files $uri $uri/ =404 with no SPA index fallback.

That week is what static website hosting without server management looks like when the host stays boring and the team respects file truth.

Failure table (ops expectations vs file hosting)

Symptom	Likely cause	Fix
Want to `ssh` and edit nginx	Expected a VPS	Stay on file hosting or move to a VPS deliberately
SPA refresh 404	Assumed managed rewrite	Hash routes or SSG files; product will not invent fallback
Cert “not ready”	DNS not verified	Finish DNS; order is preview → DNS → cert
Mail admin emergencies	Edited MX during web cutover	Restore MX; use a mail vendor
Remote build missing	Assumed platform npm	Build in CI/laptop; upload output
PHP upload fails	Wrong product	Use a PHP host

Cutover procedure that skips ops theater

Produce clean index.html at the tree root.
Deploy zip or GitHub artifact branch to StaticHost.
Verify on HTTPS preview; roll back once to prove the control.
Add domain records exactly as the dashboard shows; do not touch MX.
Wait for verification and certificate.
Document the build command in README so humans reproduce it—servers here will not.

You still own content correctness, routing model, and browser secrets. You do not own apt, fail2ban, or certbot crons. Pricing: Starter $9 (1×2 GB), Pro $30 (3×10 GB + staging), Scale $65 (10×30 GB), Business $130 (30×100 GB + teams) after ~1 day trial—no forever-free, no cPanel, no email, no built-in CDN product. Companion shopping notes: where to host a static website.

FAQ

Is managed static hosting the same as managed WordPress?

No. Managed WordPress includes PHP, databases, and often plugin ops. Static hosting manages file serving and TLS for pre-built files.

Can I install a language runtime later on StaticHost?

No. If you need runtimes, migrate that workload to an application host.

Who renews TLS?

For preview hosts and for custom domains after DNS verification, certificate issuance and renewal are part of the managed surface—not a certbot cron you maintain.

What about uptime monitoring?

You may still run an external monitor against your URL. You do not need to monitor disk inode exhaustion on a VM you do not operate.

Is there a control panel?

Not cPanel. Expect a product UI for sites, domains, deploys, and billing—not a general-purpose server panel.