How to Publish an HTML Website Without a Server

A static website is a folder. An index.html, some CSS, a few images, maybe a script. There is no database, nothing to execute and no state to keep.

For most of the web's history, putting that folder online still meant renting a machine, installing a web server and remembering to renew a certificate. That is no longer the shape of the problem, and a lot of advice has not caught up.

Cover for the digily.site guide on publishing HTML without a server
Publishing · Files in, address out · digily.site

What static actually means

Static means the server sends the file as it is. No PHP, no Node process, no database query. The same bytes go to everybody.

That is why static sites are fast, cheap and almost impossible to break. There is no code running at request time, so there is nothing to crash, nothing to inject into and nothing to keep patched.

It also sets the limit. Anything needing per visitor state, such as a login or a shopping basket, is not static. A contact form can work by posting to a third party service, and everything else on a small business site is static whether the owner realises it or not.

What you actually need

  • Somewhere to put the files that serves them over HTTP.
  • A TLS certificate, so the address is HTTPS and browsers do not warn.
  • An address people can reach and remember.
  • A way to replace the files when the site changes.

That is the entire list. Everything else, including the operating system, the web server configuration and the renewal reminders, is machinery in service of those four things.

How it works now

You upload a folder or a ZIP. The service stores the files, serves them over HTTPS from an address, and handles the certificate.

On Digily Link that means creating a static site, uploading an HTML file or a ZIP, and choosing the domain and the name after the slash. The site is live at that address once it is saved.

Updating it is the same operation again. Replace the files, keep the address. Nothing about the URL changes, so anything already sharing it keeps working.

What to check before you commit

The differences between static hosts are not about speed. They are about what happens later.

  1. How do you update the site? If it takes more than a couple of minutes, you will stop updating it.
  2. Can you use your own domain? If the address might need to outlive the host, this is the question that matters.
  3. Can you get your files back out? A folder of HTML should never be locked in anywhere.
  4. What happens when you stop paying? A site that disappears without warning takes every link to it with it.

Structuring the folder

Two rules cover nearly every upload problem.

First, index.html goes at the root of the archive, not inside a folder. A ZIP containing a single directory with the site inside it usually publishes as an empty page, because the server looks for index.html at the top and does not find one.

Second, every path inside the files is relative. css/style.css works anywhere. /css/style.css assumes the site sits at the root of a domain, and a site published under a path will silently lose its stylesheet.

Being honest about the limits

Static hosting is not the answer to everything and pretending otherwise wastes people's time.

You cannot run server side code, which rules out anything with accounts, carts or per user content. You cannot query a database. Forms need a third party endpoint to post to.

For a landing page, a portfolio, a CV, an event page, a menu or a brochure site, none of that comes up. For anything else, this is the wrong tool and it is better to know that on day one.

Start on Digily Link

Put your site on a digily.site address.

Open a free account, describe the site or upload your files, and it is live on HTTPS in minutes.