Deploy a Website Without a Server: Static Hosting Explained

hdply · 2026-07-04

A surprising number of people rent a VPS, install nginx, and wrestle with TLS certificates — to serve one HTML page. If your site doesn't run code on the server, none of that is necessary. Here's why, and what to do instead.

Static vs. dynamic — the only distinction that matters

A dynamic site computes each response: it runs code, queries a database, renders per-user content. It needs a server you manage.

A static site is files: HTML, CSS, JavaScript, images. The server's only job is to hand them over. Portfolios, landing pages, documentation, blogs, demos — the majority of pages on the internet are static, even interactive ones: your JavaScript runs in the visitor's browser, not on a server.

What "no server" actually means

Of course a computer somewhere serves your files. The point is it isn't yours: no machine to rent, patch, monitor or firewall. Static hosts solve serving once, properly — with CDNs, HTTPS and caching — and let you upload files.

What you stop worrying about:

Security patches — there is no OS for you to update.
TLS certificates — HTTPS comes with the platform.
Scaling — a static file survives traffic spikes that would flatten a small VPS.
Cost — serving files is so cheap it's usually free.

Deploying with zero infrastructure

The minimal path with hdply:

Sign up free with your email.
Upload index.html (or paste your code into the editor).
Live that second — you get your own hdply.com address, HTTPS included.

No YAML, no CLI, no Git, no build. Edits happen in the browser and deploy on save.

When you actually do need a server

User accounts, payments, databases, server-rendered content — that's dynamic territory. But even then, the common pattern is a static front end calling an API. Start static; add a backend only when a feature genuinely demands it.