Each guide is a single shell script, shown in full with an explanation beside every step. You run it from your workstation against a fresh Linux server you have root ssh access to, and a few minutes later the server is serving over a real certificate, ready for apps.
The three scripts share most of their length. All of them build wotaskd and JavaMonitor locally with Maven, install a JDK on the server if one is missing, lay out /opt/webobjects, create an unprivileged webobjects user that everything runs as, install systemd units and log rotation, and start the stack. Every one of them ends the same way: wotaskd launching and watching instances, JavaMonitor as the place you add apps, certificates from Let's Encrypt.
Where they differ is the edge: what listens on ports 80 and 443, and how a request finds its way from there to an application instance. That choice is the whole difference between the three, and it's what each guide is named after.
modulo alone on ports 80 and 443: TLS from Let's Encrypt via native ACME, virtual hosts, static files and routing to instances, from one TOML file. No Apache, no certbot, no compiled module. The field-tested path, and the one we run ourselves.
Apache keeps the edge — certbot certificates, vhosts, static files — and modulo stands behind it as the WO-aware reverse proxy, replacing mod_WebObjects without compiling anything. For an Apache estate you can't, or won't, retire.
Deployment as it has been done since the last century: Apache with a compiled mod_WebObjects module, certbot, and a C toolchain on the production server to build it. Published for comparison, so you can see what the other two leave out.