HAproxy is good at what it does but it’s only good at proxying and simple rules.

It’s possible to write very complex rules/ACLs with HAproxy… stick-tables, ACLs with regexes on whatever HTTP header, source or destination ACLs, map files, geoblocking, lua scripting, load-balancing from round-robin to host header load balancing, dynamic backend servers provisionning through DNS… Not that you can’t do it with Nginx (it started as a reverse-proxy before becoming a jack of all trades), nor that nginx isn’t a great tool (it is!), but HAProxy can do very complex things too. It also follows the good ol’ UNIX philosophy of “one program to do one thing and do it well” and thus doesn’t try to be a webserver, hence why you need a webserver behind it to serve anything from static files to PHP/Python/whatever.

You’re welcome! scratch and distroless are indeed basically the same thing, scratch being the ‘official’ docker minimal image while distroless is from google - as I’m more a Kubernetes user (at home and at work) than a Docker user, I tend to think about distroless first :) - my apologies if my comment was a bit confusing on this matter.

By the way, have fun experimenting with docker (or podman), it’s interesting, widely used both in selfhosting and professional environments, and it’s a great learning experience - and a good way to pass time during these long winter evenings :)

A bit late but you might want to have a look at docker multi-stage build documentation which does exactly what you did (start from a base image then copying stuff from it to your own image), something like that:

FROM someimage:sometag AS build
[do stuff]
FROM minimalimage:someothertag
COPY --from=build /some/file /some/other/file
[and so on]
USER somebody
CMD ["/path/somecommand"]

Which will simplify building new images against newer “build” image newer tags easier.

btw, you were quite creative on this one! You also might want to have a look at the distroless image, the goal being to only have the bare minimum to run your application in the image: your executable and its runtime dependencies.

good old x201 here (i5-720m iirc), 8GB ram, sata ssd. Debian stable. No DE, just stumpWM. Not watching 4k youtube videos but runs fairly well for a 13 years old machine.

1Gbps down/700Mbps up here, 35€/month (another french provider), no data caps - for 5 bucks/month more I could have 5Gbps down/1Gbps up, but… well, my home network is still using 1Gbps switches - but all the cabling was built with 10Gbps in mind.

Data caps are pure robbery. We run a non-profit ISP/hosting platform and a non-profit IXP with friends in West France, the only thing you pay (and the only thing end users should have to pay) is goddamn bandwidth.

Kudos for mentionning powerDNS, it’s an amazing software :)

One thing I love with powerDNS is the various backends available, notably the postgreSQL and mariaDB/mysql ones. Only the primary powerdns instance modifies the database records, the secondary instances just read from database (master or replicas). Thus, no real need for AXFR: as soon as you added/modified a record on the primary, the secondary pdns servers will see it in the database.

The pdnsutil CLI tool is also really convenient, and the powerDNS API is a godsend when you need to automatise stuff for thousands of domains and hundred of thousands of records. There’s also a nice third-party webUI (powerdns-admin, docker image: pdnsadmin/pda-legacy). Bonus, Terraform does have a powerdns provider.

At work we use dnsdist (from powerDNS too) to load-balance between our powerdns instances (with caching!), and to filter out/rate-limit/temporary ban bad actors (dns laundering, records enumeration and such for example).

Physical machines get stars names: Vega, Arcturus, Polaris, Fomalhaut, Deneb, Antares, Procyon, Algol, Aldebaran… and so on.

Virtual machines naming scheme is more reasonable: [os]-[role][number if needed]. Examples:

• alp-proxy
• talos-controlplane-3, talos-worker-1, talos-worker-6
• deb-storage