Now, you would like to just be able to build this site once, and once you’re satisfied with it, put it somewhere and be done with the technical side of things forever. Any maintenance to the site should then be restricted to updating the actual contents of the site.

This is, as it stands, impossible: to be somewhat confident the site doesn’t get hacked, you need to run regular upgrades of the software the site was built on (Operating System, Database technology, Web Frameworks etc. etc.) Any of these upgrades may bring down the site, so they must to some degree be manual. At the very least you must always check whether the upgrade was successful, and if it wasn’t, you’ll need to manually figure out why it wasn’t and somehow fix it (again: manually).

The reason for this is that the upgraded software libraries will work in slightly different ways from their predecessors, breaking the expectations of your software. This can be mitigated, but only to a degree.

Firstly, the maintainers of the libraries may provide specific “security support” for specific older versions of their libraries. By restricting the upgrades of libraries to such security upgrades, which are smaller in both number and scope, you will certainly reduce the amount of required manual intervention. Unfortunately, even “security upgrades” are not guaranteed to be free from breakage, so manual intervention cannot be ruled out completely. Furthermore:

1. Security support for older versions is not eternal
2. The challenge of doing only minimal upgrades is made harder by the fact that the various libraries we build on may have dependencies amongst themselves
3. Our “package manager” may introduce further constraints on the available versions of libraries

In any case, once the security support stops, you’ll have to do the regular upgrades after all, and you’ll still be confronted with the full scope of the original problem.

A second way to mitigate the problem of running upgrades is to offload part of the work to other parties. You may, for example, rent a platform of up to date software; leaving the upgrading of the platform to an external party.¹ In some cases, such an approach will actually create further problems of its own, for example when your infrastructure provider decides to apply upgrades which are incompatible with your software, and does so while you’re sleeping. The more fundamental issue is that paying someone else to do part of the work is merely hiding the real problem, which is that the work exists in the first place.

In short: the state of the art of running a small website is “build once, manually maintain forever”. This burden of maintenance is largely caused by changes in other software, as opposed to changes in our own requirements.

The project on this website is to come up with (experimental) solutions for this problem and others. This is an ongoing project.