Deploy a Website Without a Server: Static Hosting Explained

hdply · 2026-08-15

A surprising number of people rent a VPS, install nginx, and fight with TLS certificates in order to serve one HTML page. If your site doesn't run code on the server, none of that is necessary — and the machine you just rented is now your responsibility to patch. Here's what static hosting actually is, where its edges are, and how to deploy without owning infrastructure.

Static vs. dynamic — the only distinction that matters

A dynamic site computes each response. It runs code per request, queries a database, renders content that differs per user. A forum, a dashboard, a webmail client. It needs a server process that stays running.

A static site is files: HTML, CSS, JavaScript, images. The server's entire job is to hand them over unchanged. Portfolios, landing pages, documentation, blogs, demos, event pages.

The confusion is that static does not mean unmoving. Your JavaScript still runs — it just runs in the visitor's browser instead of on a server. A static page can animate, validate a form, fetch live data from an API, run a game, or render a chart. What it can't do is keep a secret: anything in the file is visible to anyone who views source.

What "no server" really means

Obviously a computer somewhere serves your files. The point is that it isn't yours. Nothing to rent, patch, monitor, back up or firewall. Static hosts solve serving once, properly, for everyone — with CDN caching, HTTPS and compression — and hand you an upload box.

Concretely, what you stop doing:

OS patching — there is no operating system in your care, so no unattended-upgrades to configure and no kernel CVE to read about on a Friday.
TLS certificates — HTTPS comes with the platform, including renewal. Nobody's site expires at 3am because a cron job silently stopped.
Web server config — no nginx blocks, no MIME type surprises, no trailing-slash rewrite rules.
Capacity planning — a static file survives a traffic spike that would flatten a small VPS, because it's served from cache at the edge.
Most of the cost — serving files is cheap enough that free tiers are normal rather than promotional.

The security argument, which is the strongest one

A static site has almost no attack surface. There's no database to inject into, no admin login to brute-force, no PHP version to keep current, no plugin that turns out to have a remote code execution bug. The worst case for a compromised static host is that someone replaces your files — bad, but recoverable in the time it takes to re-upload, and every serious host keeps deploy history.

Compare that to a WordPress install on a VPS, where staying safe is an ongoing subscription to attention. If your page is a page, the static version isn't just easier, it's meaningfully safer.

Deploying with zero infrastructure

The minimal path, with hdply as the example:

Sign up free with an email and a verification code.
Choose a subdomain — you get your-name.hdply.com.
Paste your HTML into the editor, or drop the .html file in.
Save. It's live, with HTTPS, immediately.

Because there's no build, there's also no build failure, no cache purge, and no five-minute wait to see whether your change worked. The file you saved is the file being served.

One structural constraint to plan around: hdply serves exactly one file per site. Inline your CSS and JavaScript, and reference images by URL or embed them as data URIs. If your project genuinely has an assets folder, use a Git-based host instead — that's covered in the free hosting comparison.

When you actually do need a server

Be honest about this, because building around a limitation is worse than accepting it. You need server-side code when you have:

Secrets. An API key that must not be public. Anything in your HTML is public.
User accounts and sessions that you're implementing yourself.
Payments beyond a hosted checkout link.
A database you write to — comments, bookings, submitted records.
Content personalised per visitor before the page reaches them.

Here's the shape that catches most people out. This is a static page doing something that feels dynamic — and it's fine:

<div id="rates">Loading…</div>
<script>
  fetch('https://api.example.com/rates')
    .then(function (r) { return r.json(); })
    .then(function (data) {
      document.getElementById('rates').textContent = 'EUR/USD ' + data.eurusd;
    })
    .catch(function () {
      document.getElementById('rates').textContent = 'Rates unavailable';
    });
</script>

No server of yours is involved; the visitor's browser calls the API directly. What would not be fine is putting a secret API key in that JavaScript — anyone can read it. That single line is the boundary: if calling the service requires a credential you can't publish, you need something server-side in between.

Even then, the usual modern shape is a static front end talking to an API — so the hosting question doesn't change, only where the API lives. And several things that sound dynamic are solved without a server at all: contact forms via a form service, comments via an embed, search via a client-side index, analytics via a script. Start static. Add a backend when a specific feature demands it, not in anticipation.

Common questions

Is static hosting slower? The opposite. There's no application to execute, so the response is a cached file from a nearby edge — typically the fastest thing you can serve.

Can a static site handle a spike? Better than a small VPS can. Serving identical bytes to many people is exactly what CDNs are built for.

Can I use a database? Not directly — but your page's JavaScript can call a hosted API (Supabase, Firebase and similar) from the browser, using keys scoped to be public and rules enforced on their side.