How I Host Websites (plus musings about Web 2.0 and social media)

meta infrastructure web hosting containers static site generators rant

For years, I struggled to find the right solution for hosting a simple blog. Nothing quite felt like it fit my needs; it was either too opinionated, not featureful enough, or way too much infrastructure overhead for a simple blog.

Tim Berners-Lee created the Web in 1989. It hasn’t been strictly downhill from there, but we have lost something that feels crucial. This isn’t just nostalgia; there are tools that do an admirable job of meeting many use cases, but there are a few use cases that should be better served than they are. So I want to talk about the websites I manage, how I chose the tools that I use, and what I feel is missing in 2023.

The history

But first, some very broad history. In the early days of the web, everyone was writing HTML by hand. You could grab an account on Geocities, write up some nice static webpages, and go about your day. Early dynamic content was done via CGI, which allowed you to plug more-or-less arbitrary backend code in any programming language that could speak CGI.1 So at this point, even getting some static content2 online where other people could see it required a decent chunk of technical knowledge, and anything with dynamic content like user comments often required substantially more.

Eventually Content Management Systems, of which blogging platforms like Wordpress are a subset, came along. These made it much easier to get a website with dynamic content up and running, and more importantly made it easy for users to create pages without a great deal of technical knowledge. This meant that one “admin” could easily host a website that had dozens of non-technical contributors.

And eventually, these systems (especially Wordpress) became the standard way to host a website. Hosted blogs (such as Livejournal and, more recently and perhaps relevantly, Medium) came along, and then of course the rise of social media made blogs largely irrelevant, but Wordpress offered a lot more in the way of customizability and having a presence that wasn’t tied to a hosted platform. Wordpress is, in many ways, the last way to easily create an online space that feels like it belongs wholly to the author and not just content in a social media content mill. There are things like Squarespace, but they have premium price tags and are almost universally more geared toward small business, not individuals who just want a web presence.

The problem

Wordpress is genuinely a good tool. But Wordpress is a very heavy application. It requires a database, it supports comments and has hundreds of themes and plugins all installable from its convenient admin interface. This makes it both resource-intensive and increases its attack surface substantially. Wordpress is probably the number one target of malicious scripts on the Internet, because it comes with non-optional dynamic features.

For many sites, that’s a perfectly fine tradeoff. If comments or other features that make a database particularly useful are a crucial part of your site’s experience, or there are plugins that are indispensable for your particular needs, then Wordpress is great.

But the web is bloated. Loading a simple page with text and a few images doesn’t need to be a slow, multi-megabyte experience. Wordpress, CMSes, hosted blogging sites, and social media are often major overkill in terms of resource usage and page size. The ever-increasing availability of processing power and bandwidth (in the developed world, at least) has made programmers abandon efficiency and optimization in a lot of cases. We’ve learned to live with seemingly simple sites that take ages to load, and it really doesn’t have to be this way.

If your needs are simple, if all you want is a place that feels like your own to write long-form thoughts on one or more topics, or post some pictures or links to things you find interesting, then Wordpress is like using a sledgehammer to drive in a thumbtack. Which is where static site generators would like to help.

Static site generators are intended to fill exactly this use case. They take a convenient, “human-readable” directory of content and create a set of simple, static webpages that you can upload to a webserver of your choice. The result is a lightning-fast website that can handle a ton of traffic.

Unfortunately, these generators require a non-trivial level of technical knowledge to use. You need to know, at a minimum, how to use markdown, a command line, scp or ftp, and probably how to write a little code. Ideally you would also understand source control and a host of other conceptual tools. Static generators are great for the technically savvy, and as a result are frequently used for technically-leaning blogs and websites.

But the gap comes in between these two user bases. Don’t want to contribute to the bloat of the web or deal with the fragility of a database just to put your thoughts somewhere that Musk and Zuckerberg can’t touch them? Well, there’s Github pages, but that still requires writing your own HTML or using a static generator. (plus Github is best avoided) There’s Medium or Cohost, but they are still unnecessarily bloated for a lot of people3, plus lack the personal feeling of “here is a space on the web that is solely mine.”

My solutions

Of course, I have a decent level of technical ability, so some of my sites, including this one, are built with a static site generator. (Hugo is the one I prefer these days) You can see the source for this site on my git server. The built site does include some javascript, mostly for Google Analytics, but if I want to I could pare that down further even.

I could deploy these sites to a simple webserver over SSH or FTP, but instead I build the sites directly into nginx docker containers and deploy them into a docker environment running on Linode using docker-machine and the wonderful (jwilder/nginx-proxy)[https://hub.docker.com/r/jwilder/nginx-proxy] image. (I have to have some sort of overkill in my workflow or I feel unsatisfied. But this overkill doesn’t affect the end user experience!)

Using containerization gives me a lot of clean, reproducible configuration; just about everything is configured as code, with very little in the way of state on the webserver itself. I can redeploy these onto a new host with zero loss of content at any time, should the need arise.

Plus, my deploy script can just run an elaborate version of this:

docker build
docker push
docker-compose pull
docker-compose up -d

Which, for a personal blog, feels like just the right amount of infrastructure to deploy.

I also host several Wordpress instances, most notably Eruditorum Press. I use some of the same infrastructure tricks, but these sites are largely authored by non-technical users and have a strong need for comments, so the static site solutions above aren’t feasible. So Wordpress feels like the right solution there.

In Conclusion

Ok, so this was mostly just a rant about website bloat. And it’s possible I’m missing obvious solutions or am blowing the problem out of proportion. Maybe I’ve just gotten tired of websites being slow. But it really feels like we ought to have created something that’s both easy to use without technical expertise but also produces clean, fast websites for people with simple use cases.


  1. And if your favorite language didn’t have a library for CGI, you could write that support in yourself! ↩︎

  2. Like, say, your Revolutionary Girl Utena fanpage↩︎

  3. I loaded a random page on Cohost with no significant interactivity and got at least 400 kB of javascript. Cohost was somewhat worse. That may not seem like much, but remember that some people are still reading your blog on a 2G mobile connection. ↩︎