Static web hosting

← Back to root

Thanks for the spark you provided, DC.

There are many ways to create a presence for yourself on the Internet. Static web hosting provides lots of power and freedom with potentially low setup complexity.

A website is "static" if the pages it delivers to visitors are unaltered, existing files from the server's filesystem.

These are my notes on hosting a static website:

Assumed knowledge

These notes are written like a guide. The target reader knows about:

  • Working with files on computers.
  • Running programs on computers.
  • The basics of how computers communicate over the Internet.
  • SSH. This is the biggest one.

If something is unclear after accounting for those assumptions, tell me. I'll improve these notes.

What is involved?

First time setup includes these considerations:

  • Getting hardware with an IP address
  • Getting a domain name
  • Choosing a web server
  • Enabling HTTPS
  • Translating content files to HTML
  • Copying HTML files to the server

The following top-level sections exactly mirror that list.

After first time setup, a static website needs little maintenance. Really: I'm pleasantly surprised by how easily I completely forget that I keep this site up and running.

Ongoing maintenance tasks

Include:

  • Keeping the hardware running
  • Renewing your domain name
  • Renewing your TLS certificate

Getting hardware with an IP address

You need a computer that's the Internet can see. There are two basic methods to gain control of one.

Method 1: Your computer

Linux is a great operating system for repurposing an old computer into a web server.

I could be wrong about the following paragraph. I've never done it.

Set up the Linux machine normally. Make it visible to the outside world (with caution) by forwarding the port your web server will communicate on. This is a function of your router and Internet service provider. Your computer will be visible to other computers at your router's IP address.

Method 2: Someone else's computer

That's all the cloud is, after all.

I rent a Virtual Private Server (VPS) for a monthly rate through Linode, which was acquired or something by Akamai. Choose an operating system you're (willing to become) familiar with, and interface with it as you would any SSH-accessible computer.

Your cloud provider, the company you rent the server from, will tell you what the server's "(Public) IP Address" is. This is the address you want your domain name to point to.

Getting a domain name

This is an easy task but a hard choice. Either come up with a domain name you like and find a "registrar" that will lease its control to you, or pick a registrar and see if they're offering anything you like.

I can't quite remember, but I think I chose tykozic.net first and it was available one of the first places I looked.

Linode has great documentation and support for connecting a domain name to an IP address. You'll have to do that.

Choosing a web server

Your website's pages will be served to visitors by a program on the server. We call a few different things "web servers", including these programs.

I can't wisely advise on picking a web server. I picked and committed to Nginx early, and its served me quite well. It's popular enough to have great support for LetsEncrypt and many different use cases and extensions, if you start needing more features. For basic static usage, I find it relatively (major emphasis on "relatively") easy to configure.

With many different web servers, the basic tasks will be:

  • Point the server to your content files
  • Enable HTTPS
  • Start the program

Enabling HTTPS

See the Wikipedia page for HTTPS.

This isn't strictly necessary, but if you care about appearing in search results and being treated as friendly by modern web browsers, do it. You need to get a TLS certificate and configure your web server to use it.

If you're using a reasonably popular pair of operating system and web server, the certbot tool from the noble LetsEncrypt makes it easy, automatically renewable, and free of cost.

Translating content files to HTML

Intertwined with the previous. Most SSGs lock you into markdown and might have extra filetree restraints.

The easiest way to do this is with a "static site generator". I had success with Zola a long time ago. Hugo and Jekyll are other names I've heard floating around. There are dozens of these generators, and most of them probably work just fine.

They'll mostly intake Markdown (Wikipedia) files, with options to generate Atom feeds, sitemaps, etc. Essentially:

  1. Create a tree of markup files that say what you need to say
  2. Run the static site generator on that tree

Plug: My static site generator

My interests include markup languages, so I didn't want to be locked into Markdown. Converters are easy enough to find; all I needed was a small-ish program to traverse a tree of input files and use various converters, chosen by me for each input, to generate output files.

I wrote Dirmake to do this and I like it.

Copying HTML files to the server

Do this however you like.

Method: SCP

SCP is short for "secure copy". That "secure" should remind you of "secure shell", SSH. SCP uses SSH. Simply copy your directory of files from one place to the other.

Method: Rsync

Rsync is like SCP, but transfers only as much information as necessary. Files that haven't changed won't be sent a second time. As your site grows, Rsync will grow faster than SCP.

Method: Git

If I'm using Git for version control, why not use it for file transfer, too? Use git pulls and pushes for robust, low-fear transfers.

Caveat

I keep only input files under version control. My server doesn't have the tools to convert them to output files, so I don't use Git to sync.

If you want to use this method, make sure to install the tools you need on the server.