(a.k.a., "An example of what I do")

TL;DR: For my purposes... currently (April 2021)... it is Grav CMS using the Gantry5 Theme Framework. That's what is running this site. For others, as is the mantra in tech in general: "It depends."

Strap in. This is a long post.

So like me, you finally decided to start a blog/website. Now what?

Excellent question. Well, if you're most people, you go to a site like WordPress.com, Weebly, etc., create yourself a free account (or go whole hog and get a paid account), and off you go.

If, however, you are me, this is where you go off and do your research, which means you often go down a rather deep rabbit hole for a bit. And that's exactly where I ended up... in a deep, dark hole, wondering what the heck I was thinking.

It Begins...

So my first step in any new venture is to figure out what it is that I am after.

If you don't know where you are going, any road will get you there. Lewis Carroll

Then I read. A lot. And I did.

I Google for something. I read. Often this leads to other things catching my eye. This in turn gives me more insight, which often adjusts my thinking about what I'm after. Rinse. Repeat.

At some point I take what I've read and I begin applying it. Often this involves trying different things, as the only way for me to know whether something truly fits my needs is to actually use it. Reading is nice, but there is no true substitute for experience.

Good judgement is the result of experience and experience the result of bad judgement. Mark Twain

So then I create an account, setup a service, or spin up something and begin tinkering. If it fits my needs, great! I'm done. If not, more rinse. More repeat.

So this site is the culmination of where I landed. Now to the process.

Why

I am a big believer in "why before how". "Why" is what drives you. "How" is just how you get there. Without "why", "how" doesn't really matter so much.

So why? For awhile I have been considering setting up a site where I could write down things that are, frankly, of interest to me. This might be musings, instructions, tutorials, etc. Basically a place where--after I have spent time reading/doing something, let my brain chew on it a bit, and once it gels in my head--I write it down for future me... "Alzheimers me" if you will... as I'm more than likely to forget over time. And if anything I write helps someone else, all the better.

How

When I'm researching something new, I always strive to find that person who has coalesced and explained things in a clear and succinct manner. True SMEs (Subject Matter Experts) are few and far between. So finding one is both challenging and rewarding. (I believe in the 80/20 rule, which to me in this context means that in any given area/profession, 80% of the folks involved are average at best. Just 20% are really good. And frankly, I think the rule is generous.)

If you can't explain it simply, you don't understand it well enough. Albert Einstein

Often finding this SME requires reading a lot of poorly written information first. You have to sift the wheat from the chaff. But eventually I find that short, sweet, clear explanation that makes it all come together. When I do (find that "ah hah!" explanation), I've done a bit of "curation" of material and want to simply record what made it clear to me. This might also short-circuit the learning process for others so they do not have to go through all the chaff themselves. Failing that, due to sheer raw effort and persistence, eventually the information coalesces in my brain and I come up with what I hope is a clear and, ideally, succinct (not my strongest attribute) explanation.

What I'm attempting in my feeble way to do here is either

• be a curator and provide links/info to those resources I found most useful, or
• be that resource

to help others get up to speed quickly, short-circuiting the same process for "Memento me" or someone else.

I have said this many times: while we can always make more money, the one thing none of us can make is more time. The best we can do is save time. So if anything on this site saves someone even a minute of time, then I will have succeeded. (And once I figure out how to enable feedback/comments, I would love to hear if anything on here has, in fact, helped anyone.)

Starting with the end in mind

There are some great video clips of the late Steve Jobs, cofounder of Apple, that I watch every so often. He had such great observations/beliefs, including

• "You’ve got to start with the customer experience and work backwards to the technology."
• "Focusing is about saying no."

In this case I am the customer and it's about my experience. 😀 (Ok ok, I'm also thinking about those who visit here.) So what was my end goal? Here is what it came down to. I wanted a solution

• that was available on the Web, both for viewing and editing
• where I could write/document things as quickly/simply as possible
• where I would always have control/ownership over the content
• that was in a format I could, if need be, migrate elsewhere should the need arise

Things Specific to Me

Now the details of this are specific to me, and they are in no particular order:

• I am a technical person who has been using computers since I was 12.

  • I have a BS in CS (that's Bachelor of Science degree in Computer Science, though some would say I am full of BS 😀) along with all the coursework for a Masters in CS
  • My background runs the gamut. I am a generalist as opposed to a specialist. I am a "jack of all trades" vs. "a cog".
  • I love databases, networking, and operating systems.
  • I have an affinity for languages, both programming and human

  • This is not to say "Oh look at me, I'm so awesome." The point is that I am perfectly comfortable spinning up

    • databases (e.g., SQLite, MySQL/MariaDB, PostgreSQL, etc.)
    • OSes (e.g., Linux, macOS, Windows)
    • webservers (e.g., Apache, NGINX)
    • and using/integrating programming languages (e.g., PHP, Python, Perl, Lua), frameworks (e.g., Django), etc.

    I have no trouble bringing up a LEMP stack (Linux NGINX MariaDB PHP) to install/configure/run WordPress or anything else. This, in turn, gives me more options to choose from. YMMV.

• I am a big believer in open source and open standards. This informs my choices as I do not care for proprietary standards or "lock in".

  "I use macOS because I want to, Linux because I like to, and Windows because I have to." Me

• I use macOS for my desktop systems and Linux for just about everything else. If I can't have the former, I'll take the latter. I much prefer a POSIX-compliant *NIX OS. My background predates MS-DOS, but included MS-DOS and MS Windows from v2.1+. Only later did I get into Macs and then Linux (back when the kernel was at v0.96). This means I have actually known Windows longer than the other current desktop OSes. But MS Windows is the last OS I would use given the choice. But that's me.
• All the same, I am "OS agnostic." While I have my preferences and have no trouble expressing why, I would no more want to inflict them on others than I would want others to inflict their preferences on me. This means the solutions I look for should also, whenever possible, be OS-agnostic so that they help as many folks as possible. For applications this means I look for solutions that run on all the desktop OSes and/or mobile OSes where possible.
• I have an Ubuntu Linux VM "out there" that has 1 Intel vCore and 1GB RAM. Basically it's less than most of the Raspberry Pis I own. And my goal was, if I could not find a proper solution as a service (e.g., something run/managed in someone else's cloud), it had to be able to run in mine without costing me too much. And you cannot get much smaller than 1 vCore and 1GB RAM. I think most providers like Digital Ocean start with droplets no smaller than this, which go for $5 USD/mo. Can't go much lower than that.

This covers the basics. I cannot possibly describe all the things I have experience with, but suffice it to say that I am well versed in much of the technology involved. I have done databases since the days of Oracle when they didn't even have table level locking, let alone record/field locking, referential integrity constraints, cascading updates, etc. I bought my first PHP book back in 2000 when PHP v4 had just barely come out (and by then I had learned/used BASIC, FORTRAN77, PL/1, C, C++, shell scripting, SQL, DQL... and that's just off the top of my head). I used Perl for years before finally giving in to my (as it turns out unsubstantiated) concerns regarding Python's "indentation affects logic" design. And I've tinkered with Swift and Go, though lately my focus has mostly been on Python/Django. I have used/configured the Apache webserver since the late 90's, even running it on MS Windows for a few years. (This after getting fed up when a Code Red worm snuck past our IIS setup due to MS failing to alert folks that a certain hotfix was needed.) But for several years now, I have preferred using NGINX as my webserver. NGINX requires less resources and is wicked fast. (Yes, I also hate bloat, so I like running software that's well written and lean.)

The Search

NOTE: Before I start, let me be clear about a few things. First, when I write CMS, in this context I mean a Content Management System (e.g., WordPress) as opposed to a Course Management System (e.g., Moodle, Sakai, Canvas, Desire2Learn, Blackboard). There is a bit of gray there, as invariably folks have made course material with content systems and others have used course systems to post blog-like entries. But to be clear, we are not so much focused on a platform for building courses here. (I may cover that at another time.) This is more generic in nature, focused on building a website that can provide content, be it basic web pages or a series of blog posts, etc.

Second, some might argue that a wiki is a form of CMS. They tend to share similar technical requirements (e.g., MediaWiki uses PHP and a database like MySQL/MariaDB, PostgreSQL, or SQLite) and provide some similar features. I even considered this. However, I intentionally skipped this category of software. First, I already have my preferred wiki software, DokuWiki, for all my wiki needs. It's a flat-file based wiki (i.e., it does not require any database backend) which only requires a webserver and PHP. And while DokuWiki is fantastic as a wiki, in this instance I was looking for something different. I wanted a solution that let me build a website and/or have blog posts, etc. much like WordPress and others do.

At a previous job, where I worked for over 20 years, among many things I did, I helped coalesce our knowledgebase of information in the networking group. When I first started working there, no such thing existed. Each person kept notes on paper or at best in Notepad (text) or Word documents on their individual PCs. The first thing I did was setup a departmental server with a file share so we could at least share files. Eventually one folder on the file share held HTML files, which were updated by hand, that were then served by IIS (and later Apache).

Later I looked for something we could use that let us edit the pages online. This led to looking into wikis. My first attempt, PHPWiki, was an utter disaster. Even though I copied all the static content into PHPWiki, no one in the group used it. And in the end, that is what tells you whether you have the right solution. Eventually, I redid the site using DokuWiki, which has a very simple but nice editor that helps you with formatting, etc. And the group took to it with ease. (In fact I believe they are still using it there.)

One thing I loved about DokuWiki was the flat file nature of it. Each wiki page was stored in a plain text file. This meant that even if the webserver was down, you could get at the content by simply using grep or similar to search the wiki files themselves. Keep in mind this software was used to store any/all information about what we did to manage anything there, from the phone system to the Cisco ASA VPN concentrators to the network equipment, etc. And as we were an ISP/datacenter, one thing I was always cognizant of was if we had a catastrophic failure.

With most wikis and CMSs that rely on an RDBMS (Relational DataBase Management System) like MySQL/etc., you are vulnerable if the database crashes or otherwise has issues. And if your database is on one server and the webserver on another, a network issue could prevent you from accessing your content. With a flat-file wiki where each page is stored in a separate text file, odds are if there is corruption/etc., it will be limited to a single page. It's also far easier to zip/tar the files for backup/transfer, and to search them. So yes, this stayed with me in my CMS research.

Third, whatever solution I was going to find, it would involve some form of webserver. Now the obvious and more common ones in use today are Apache and NGINX. But there are some solutions which offer their own webserver. (In such cases, they often suggest you setup a reverse proxy in front of it; for example, if it is a Node.js-based or Python/Django solution.) And in general the solutions I found could just as easily be hosted on a Windows box running IIS or a FreeBSD system running Lighttpd. While I cannot do anything about the particular programming language(s) or database(s) used by any given solution, again I try my best to find solutions that do not force folks to use a specific platform where possible.

Ways of Building a Website

So when I decided I was ready to start blogging/etc., I began by looking up the current state of things. Mind you, the list of offerings I reference below is just a small sampling of what I ran across. But I had to make judicious use of time and so I narrowed things down, keeping in mind that I wanted something that was actively in use/supported and sufficiently popular that I should not have issues.

Now when you build a website, there are basically two classes of solutions:

1. There are those solutions where you build your website pages offline and then upload them in some form to a webserver, including

   • Writing raw HTML web pages by hand that you FTP/SCP/etc. to some folder hosted by a webserver (call this the "Hey the 1990's called and they want their GeoCities page back!")
   • Using a desktop app such as Adobe Dreamweaver, RapidWeaver, Sandvox, etc. to build the HTML pages in a more client-side GUI manner (but in the end you are still just making pages and uploading them to a server)
   • Using some form of static content generator (e.g., Hugo, Jekyll that takes pages written in various formats such as Markdown and generates HTML, JSON, etc. that you then upload to your webserver

   These solutions typically just require a webserver and nothing more. Of course, since there's no code running on the server (i.e., these are all just "static pages"), this also limits what can be done with the site.

2. There are those solutions where there's an actual host application written in some programming language (e.g., PHP, Python, Perl, Ruby, JavaScript/Node.js) that runs on a webserver.

   Often this involves (or it is recommended to use) a LAMP stack (Linux, Apache, MySQL/MariaDB, Perl/PHP/Python), though you'll also see variations like a LEMP stack (which substitutes NGINX for Apache... the 'E' apparently comes from the fact NGINX is pronounced "en-gine X") or using PostgreSQL instead of MySQL/MariaDB. (Yes yes, there are also solutions that would use Windows and IIS, though they typically are OS-specific such as those running .NET frameworks, etc. And I have already covered my view on OS-specific solutions. The LAMP/LEMP stack offerings can often be run just fine on Windows, though it requires someone who knows how to properly configure IIS/etc.)

Under this second class of solutions, there is a whole range of offerings in the CMS space.

This includes what most folks think of when they think CMSs, which are the traditional RDBMS-based CMSs like

• Django CMS - Python with Django (framework), which can use SQLite, MySQL/MariaDB, PostgreSQL
• Drupal - PHP, MySQL/MariaDB or PostgreSQL or SQLite or...
• Ghost - Node.js, MySQL/MariaDB
• Joomla - PHP, MySQL/MariaDB or PostgreSQL or MS SQL Server
• ProcessWire - PHP, MySQL/MariaDB
• WordPress - PHP, MySQL/MariaDB
• etc.

where the content is stored in tables in an RDBMS. How that content is stored in those tables varies.

Then there are the flat-file CMSs which (in most cases) do not rely on a database but rather store content in some form of flat file(s), such as

• Automad - content stored in simple text files that use a key:value sort of layout
• Batflat - content stored in a SQLite database file (the exception in this list)
• Grav - content stored in simple text files written in Markdown (.md); each page/blog post with its media content is in its own folder; uses Twig templating; config in YAML
• PicoCMS - content stored in simple text files written in Markdown; uses Twig templating; config in YAML
• Typesetter - content stored in PHP-formatted text files; directory structure is a bit odd with long string of characters in each directory name
• WonderCMS - content stored in a single text file in JSON format (so a kind of flat-file JSON database)

Most of these solutions only require a webserver and support for a programming language (e.g., NGINX/PHP), making them lighter-weight on resources and much easier to setup/manage. Many store one webpage per file. Some offer the ability to maintain/sync the content using git or other RCS.

Round 1

Having dug into this awhile and read up on the various options, I narrowed the field a bit. For starters, I eliminated those SaaS (Software as a Service) options which were solely paid plans, as there were enough alternatives. But then I am wired to keep costs down.

I also eliminated those projects that haven't been updated in years. The one exception was Typesetter (last update was v5.1 in April 2017), notably because it seemed to offer direct editing of pages as you viewed them, which had me curious. I also pushed WonderCMS to the bottom of my list of possibles, as a single JSON-formatted text file is as susceptible (if not more so) to catastrophic corruption as a relational database. I do not have this issue with SQLite, however, which stores the entire database in a single file, as it is designed to handle commits/etc. like any proper relational database. And SQLite files are easy to backup/copy. (SQLite is my "go to" RDBMS for quick work.)

Then I began testing. All tests were performed using my VM w/ 1vCore, 1GB RAM, and 50GB of SSD storage, running Ubuntu 20.04.x LTS and using NGINX for the webserver and PHP 7.4.x. I did also tinker with Django CMS locally, which is written in Python, but it never got to be loaded on the server as I decided against it by then.

Now performance of any solution depends on various things, including whether the hardware meets the system requirements. For example, MySQL/MariaDB recommends 512MB RAM minimum to run, whereas PostgreSQL recommends 1GB RAM. In our environment, this could make a big difference for any RDBMS-based CMS, so I focused on those solutions which let me use MySQL/MariaDB first, even though personally I prefer PostgreSQL (as it is more ACID compliant... but that is a database thing, so we will just leave it there for now).

Even better would be using SQLite, which doesn't require a separate daemon running/using RAM/CPU, etc. All you need is a programming language with SQLite support (which both PHP and Python have), and the overhead is next to nothing. The downside is that since SQLite stores the entire database in a single file, you will eventually run into contention issues vs. using a true, multi-user RDBMS when you reach a certain threshold of requests/second against your site. (Odds are my site will never hit that threshold, but it is something to consider in general.)

Regarding flat-file CMSs, you would think they would have the lowest overhead of all, since they do not involve any database table lookups, no index searches, etc. And you would be right... to a point. But once a flat-file CMS grows beyond a certain point, the number of files is so large that the time it takes the OS file system to find/get the file for a given page is slower than the time it would take an RDBMS to look up the same information (notably if it's able to leverage indexes and cache some of that information, ideally in RAM). One article I read talked about a Grav site with > 1K pages on it running slow. The article indicated that Grav was intended for smaller sites, and that yes, beyond a certain point, even the developers recommended using a database-backed solution.

Also, different languages carry different RAM footprints. Generally speaking, assuming well-written code, as for RAM usage, Python < PHP < Ruby. As for CPU execution speed, Python/PHP > Ruby.

Given my druthers, I would have loved to use a Python-based solution. Unfortunately, I didn't find a full-featured one I liked. I have been doing coding work in Python with the Django framework, yet I found that, for a ready-to-use CMS, Django CMS was lacking. Django CMS is fine if you are a Python/Django developer and want to build your solution--as in write/maintain Python code to stitch the various pieces together. But unlike WordPress, Grav, etc., Django CMS simply did not have things like a GUI with easy adding/changing of themes or plugins from a ready-made list, etc. Just about anything worth having was going to require editing Python files. I am fine with this when developing a custom app. I am not fine with it for something like this. Again, that is just me.

In the end, I settled on trying Grav first. Why? It seemed to tick all the boxes:

• I had full control over my content.
• It was simple to setup. Decompress .zip file to folder on your webserver, adjust webserver config, and as long as you have PHP support, you are good to go.
• Config data was stored in YAML-formatted text files.
• Content was stored, one page per file, in Markdown format, which was easy to work on and well supported.

At this point I will mention that Microsoft's Visual Studio Code is my preferred editor these days. Hands down it is the best editor/IDE around right now. And for those who know me and how I feel about Microsoft in other contexts, for me to say this is quite something. But simply put, they have done a fantastic job. The editor is a joy. The extensions make it unbelievably useful. And I love using the built-in debugger when working on Python code. It is very handy when doing concurrent coding.

I mention this because VSCode lets you edit AND view Markdown with ease. Even better, since Grav stores each page/blog post in its own folder that contains not only the Markdown text file but also any media files that you use on that page, if you point VSCode at such a folder, it will gladly show you the formatted version of your webpage, complete with images in-line! This means you can edit your pages either using a browser or directly with VSCode.

So once I had Grav up and running, I decided to test how fast it actually was. Now for this I used the Apache Benchmark tool, otherwise known as ab. The reason for this was simple. ab is already installed on macOS. 😀

For these tests I eventually settled on using the command

ab -n 500 -c 100 https://frank.seesink.com/

and letting it run. That's 500 requests using 100 concurrent requests at a time. Sometimes I'd run it with higher numbers, or I'd just run it multiple times.

Now on first run I got ~31 page requests/second with an average load time of ~600ms (going from memory here as I didn't record this that systemically).

That seemed... low to me. Yes yes, I know. 1 vCore and 1GB RAM, Frank. But still. We're talking a flat-file CMS, SSD storage, and small text files to load.

Round 2

So then I tried Typesetter. Another flat-file CMS, Typesetter was the only solution which allowed you to view your site, and when logged in, directly edit the page you were looking at. It was also wicked fast. ab results were ~150+ requests/second with an average load time of just under 100ms!!

Now Typesetter is by far the fastest of the solutions and easiest on resources that I tested. It handled ~4-5X the requests/second of the other solutions I tested. And the ability to login and directly edit a page was nice. But I found too many limitations for my own taste. The editor was a bit clunky. The ability to add media/etc. was not as intuitive as it could be. Typesetter lacked the kind of features you expect in a CMS like being able to add/change themes or plugins from some repository. And under the hood, the worst for me was how it stored the text files. Yes, I could do a grep if need be to get at that data. But I found the directory naming structure obtuse. They use some kind of hash or random string in the names. This means if I ever wanted to parse/migrate the content, I would be going, one directory at a time, figuring out what was in each first, and only then being able to migrate. Pass.

Finally, the fact Typesetter has not had an update in 4 years tells me it is pretty much a dead project. So eventually, that could really bite me in the butt. Either it stops working, or there is a security vulnerability (already found references to some), etc. So this ended Typesetter's run.

Round 3

Next I loaded up a clean instance of WordPress 5.7. For this I used typical sudo apt install commands to install MariaDB 10.3 from standard Ubuntu packages. I spun up a database for WordPress, created a user, gave the user permissions over the database, tweaked the WordPress config file ot match, and off we went.

With a clean install and not having done anything, I again ran ab. And this time I found I was getting ~50 requests/second! So wait... WordPress, which requires loading up a MariaDB (sucking up RAM/CPU), ran FASTER than Grav, a flat-file CMS, on the same box?? Huh?? (Keep in mind that to load each of these apps, what I would do was set up each one in their own directory. I would then simply tweak the NGINX config file by pointing it at the directory of a given app, do a quick sudo nginx -t to confirm the config was ok, then do a sudo service nginx restart to restart the webserver. And voila! I was on a different CMS. So all other things config-wise on NGINX and PHP were exactly the same for each app.)

At this point I thought, "Ok, fine. I give up. WordPress runs nearly 1/2 the sites on the Internet. And now here it is running faster on the same hardware vs. the flat-file CMS I thought maybe to use. Let me just go with the flow and use what everyone else is using."

And for the next few days, that is what I did. I started going through a WordPress tutorial, figuring out how to add plugins that let me do the things I wanted to do (since a lot of functionality comes from the plugins and is not in the core). And here is where you can see why WordPress is so popular. First, it is very easy to add/activate themes and plugins. And the ecosystem is enormous. If it is possible to think of it, odds are someone has made a theme or plugin to do it. The hardest part, frankly, is figuring out how to find something, as there is just so much out there.

And then I started using the WordPress Block Editor (from the Gutenberg project), which is the "latest and greatest" in WordPress technology, to start creating pages and posts. I figured, "Ok, this is their future. I am starting clean. Here goes."

And I tried. I really did try. I tried to like that editor. I tried to make it work. But in the end, it just pissed me off too much. I found the entire process a royal pain in the ass.

I have to guess that what the developers were going for was somehow trying to make an editor that was easier to do page layouts on. But they failed miserably in my opinion. First there is the menu that pops up just above each paragraph/block as you type, constantly getting in my way as I worked. That was what drove me over the edge mostly. But I also found that the block editor was anything but intuitive. This thing did not work like a word processor like so many other CMS tools which use online editors like the CKEditor or similar. And it did not work like any typical graphic design software (Adobe InDesign, or heck, Apple Pages) that let you drop things right where you wanted easily and with no fuss, no muss.

Whatever this editor was, it was not working for me.

It was also at this point that I ran another ab test, now that I had my WordPress site up, with the plugins that gave me the basic functionality I was after. And what did I find? Now I was getting only ~25 requests/second! It was now LESS than what Grav had given me!!

So back I went.

Final Round

+

Starting anew with Grav, I decided to go all in. I read up on their lingo. I figured out how to add/change/delete themes. I eventually landed on using Gantry5 as my theme framework (another goldmine), which gave me a good bit of control over layout/etc. I also dug into all the plugins, figuring out how to add some functionality I wanted. And in the end, this site was the result of that effort. To be clear, as I write this, I have done everything using the Admin panel, meaning I have not "gone under the hood" to do anything directly in the text files.

Now once I had this up and running again (and yes I do like how to edit things here FAR better than using the WordPress Block Editor), I once again ran ab against my site. Of course by now I had put it into production mode, it was fully pimped out with a theme and various plugins, etc. And what did I find? I am averaging ~34 requests/second with an average load time of ~500ms.

But that is not all. The more I worked with Grav, the more I fell in love with it. I am far from done working on this site. But I will tell you that it has been nothing but one joy after another. I built various test pages, complete with media files, using the browser editor. Then, when I first copied over my pages to my desktop and loaded them up in VSCode and found that it could show me not only the text but also the images/etc., I was in love. This meant this solution was at least as useful as DokuWiki in being able to get at content regardless of whether the webserver was up or not.

Even better, though, is that they have a Git Sync plugin which lets you configure Grav to tie into a repo such as one in your GitHub account. This in turn means that any time you update a page on your website using the online editor, it can automatically sync the changes to your repo. If you are working on another computer, you can clone the repo, edit some files, then push them back to GitHub. That in turn triggers a webhook that updates your actual Grav site! Win win win, baby! And all this with the usual Git version tracking/etc.

So my final solution:

• VM w/ 1 vCore, 1GB RAM, 50GB SSD running Ubuntu 20.04 LTS
• NGINX as the webserver
• PHP-FPM 7.4.x
• Grav as the CMS
• Gantry5 as the theme framework (fancy way of saying it lets you do cool layouts and leverage default "LEGO pieces" you can drop on pages in your site)
• various plugins (still sorting through this)
• I can edit my pages/blog entries like this one using nothing but a browser
• My website is automatically backed up to a private GitHub repo any time I change a page
• I can edit my pages/blog entries directly on any computer I have setup to clone that GitHub repo, and when I push, it updates the website
• The entire CMS is nothing but text files. And built-in Grav has a backup feature that ZIPs up the entire website, meaning I can take that .ZIP elsewhere and spin up another instance quickly

Now is this solution for everyone? Absolutely not. But is it for me? Heck yes. At least for now. My requirements may one day change. But for the time being, this is where I will be doing my writing.