This looks amazing. That said, you may want to have a look at rules 7 and 8 for this community.

Contributors: Claude

Please kindly see Rule 8 of this community and its associated post.

In the space of mini PCs/NUCs, this does seem comparable. But bear in mind that the entire space of “home server” is a lot bigger than NUCs. After all, not everyone just wants to host an NVMe drive or two; they might want to fit some cheaper SATA SSDs or even spinning rust, as part of a cascade of stroage, with caching on SSDs and other nice things.

Likewise, the dual LAN ports with 802.3bz support is nice, but the reality is that most networks are only 1 Gbps with some devices supporting 2.5 Gbps. Quite frankly, for server use that actually needs one or both port’s bandwidth, the link would likely be better served with SFP+ slots, because of better compatibility with cheap enterprise switches available online, and because SFP+ transceivers run less hot than their twisted pair counterparts at 10 Gbps. Heck, you could even use a 40 Gbps QSFP+ NIC, which only requires a x8 or X4 PCIe slot (depending on PCIe generation of the NIC). On that note, a single PCIe slot is nice, but it does preclude the use of a double-wide GPU for transcoding use.

I would sum all this up as lacking expandability. Yes, it can be expanded somewhat. But for folks that want the capacity of an ATX-based build, this ain’t it. And for folks with abundant solar power, electricity consumption for older gen chips isn’t as much of a dealbreaker. It certainly checks off a lot of people’s boxes, yours included, but that doesn’t mean that people are “sleeping on” this, because at the end of the day, if it doesn’t serve their purposes, it’s not the right box for them. In terms of price, never underestimate the cost of $0.00 that is an old, unused laptop; they make remarkably decent servers for light loads.

Also, as of this writing, only the 32 GB RAM variant is available on the USA website.

Would cert-manager for Kubernetes be approximately what you’re looking for? In that particular case, it’s a service that runs in a K8s cluster, that can auto-request CSRs and send them to Lets Encrypt using one of the challenge types. It takes care of managing the returned certificates, such as renewing them before expiration and registering the private keys within the K8s key store.

I presume that you’re not already using K8s, so maybe that project will help you find the keywords to describe the sort of certificate manager that you want.

If you’re already using Debian on desktop, then Debian on a VPS makes sense from a maintenance perspective: you only have to track one set of security updates. When there’s suddenly a critical update for some vulnerability, you can update both at once because it’s the same upstream repos. Whereas with Ubuntu on your VPS, you’d have to be mindful to make sure to check back when the same vulnerability is patched there.

Do not underestimate the effort to upkeeping a server, and do try to unify your procedures so you’re spending less time doing the necessary things, and more time building up your self hosting stack.

I’ll offer a comparison not yet mentioned in the context of hosting software, but which should sound familiar in the social media context: moderation is hard at scale.

By every metric of scale, Codeberg is a competitor to the behemoth that is GitHub. And that means they have to contend with tough choices, such as who and what to host on their servers, no different than BlueSky, Facebook, and the individual instances of the Fediverse. And to be clear, Codeberg has always been limited to FOSS projects anyway, so nobody can genuinely argue that limits weren’t in the cards.

The distinction is that less alike Meta, and more alike with the Fediverse, Codeberg takes no hostages: people with obvious AI repos (or even marginal repos, given the possible ambiguity) are free to take their code and leave. Yes, they have to rebuild their CI pipelines, but that’s always required for any platform, including self hosting.

The fact is that Codeberg is a centralized entity that needs to (try to) make consistent policy. In this case, they have a concern about copyright and nothing anyone says can magically dematerialize that risk. If their new policy is not agreeable, then decentralized self hosting is probably the only way forward. But that was always an option with ForgeJo and federation.

And indeed, folks moving from GitHub or elsewhere are not exactly without fair warning that they might have to migrate again; we’ve not reached a utopia yet.

What is the absolute simplest way to accomplish this?

< gets on soap box>

The absolute simplest way is to use IPv6: on your Debian machine, assign multiple IPv6 addresses, one for each service you want to expose to your LAN. There’s no penalty with having a dozen v6 addresses.

Although you have those addresses, your machine generally uses just a single one for its own outbound and inbound traffic. For each service, you would edit their config so that they bind to a specific IPv6 address. Finally, you would configure an AAAA entry in DNS so that your chosen subdomain will point to the IPv6 address in question.

As an example, suppose you had three different web servers running Nginx, currently on port 80, 8081, and 42069. What you would change is the server config for each server instance, adidng the IPv6 address as part of the “listen” directive. Since each instance is now bound to a different IP address, nginx can now listen to the conventional port 80 and n’ary will the three collide. In other software, the configuration option you’re looking for is the “bind address”. By binding each app to its own IP, it will only respond if you send a request to that IP (or DNS name, which translates to an IP); this conveniently makes debugging really easy.

For a home network, you might have a single /64 IPv6 subnet. But that still means you literally have billions upon billions of addresses to use before you ever run out. And as you’ve recognized, using DNS names to identify services is a lot easier and intuitive than using port numbers. It also neatly avoids the need to memorize IPv6 addresses, because that’s never been necessary: we have DNS.

If your ISP won’t give you IPv6, you can still use locally-assigned private ranges, known as ULA, and this works because your services are contained to your LAN. Best practice is to randomly generate a subnet then use it.

< gets off soap box>

Is that something you’re looking for? As a practical matter, the effort to maintain multiple release branches and backports – compared to the norm of just maintaining a single main branch – is an outsized effort, available to only well-funded FOSS projects, usually by having an industry sponsor that makes it a priority.

I posit that the grand majority of selfhosted FOSS software, by project count, do not have back ported branches. And so production environments will want to set up an offline validation setup to evaluate update, prior to making the switch. Not convenient, sure, but not exactly insurmountable either.

At some point, some amount of responsibility for use of FOSS software must fall upon the users, or else the project is less about creating value by building up the commons for software, and more on the exploitation/abuse of the volunteers.

Downside: breaking changes are fairly common AFAIK.

By my extremely cursory reading, this stopped being a problem after the v2.0.0 release, when they adopted semantic versioning. According, breaking changes would only occur when the major version number is rolled. And version v3.0.0 was just released 5 days ago, whereas v2.0.0 was released in October 2025.

It may be down to taste, but I view 9 months as being acceptable, given the breadth of features offered and the folks willing to put effort into the project.

If a Nintendo Wii counts as retro, there’s at least one person hosting a website using one: https://infosec.exchange/@alexhaydock/114377262481451962

But that was (incredibly!) able to run a prebuilt version of NetBSD, which had drivers for the official Wii USB LAN adapter. If instead there’s a piece of hardware that can boot an OS but doesn’t have a network interface device, then SLIP could be useful. Here’s a vape hosting a website: https://bogdanthegeek.github.io/blog/projects/vapeserver/

And if still, said retro device has no concept of IP or networking, can it at least speak serial over a 300 baud modem?

IMO, abandonware means software that is a dead-end upon its very release, with no hopes or plans for anyone to every build upon it. Abandonware is generally not extensible, follows no good design philosophy that would let someone else build it up, and embodies essentially nothing.

Even a 100-line throwaway Python script has more utility to someone when it is published on PasteBin or whatever. But something like a binary executable released with no source code, with no support, and with no intent by the developer to ever make anything more of it, that’s abandonware.

Tbf, can’t the other party mess it up with signal too?

Yes, but this is where threat modeling comes into play. Grossly simplified, developing a threat model means to assess what sort of attackers you reasonably expect to make an attempt on you. For some people, their greatest concern is their conservative parents finding out that they’re on birth control. For others, they might be a journalist trying to maintain confidentiality of an informant from a rogue sheriff’s department in rural America. Yet others face the risk of a nation-state’s intelligence service trying to find their location while in exile.

For each of these users, they have different potential attackers. And Signal is well suited for the first two, and only alright against the third. After all, if the CIA or Mossad is following someone around IRL, there are other ways to crack their communications.

What Signal specifically offers is confidentiality in transit, meaning that all ISPs, WiFi networks, CDNs, VPNs, script skiddies with Wireshark, and network admins in the path of a Signal convo cannot see the contents of those messages.

Can the messages be captured at the endpoints? Yes! Someone could be standing right behind you, taking photos of your screen. Can the size or metadata of each message reveal the type of message (eg text, photo, video)? Yes, but that’s akin to feeling the shape of an envelope. Only through additional context can the contents be known (eg a parcel in the shape of a guitar case).

Signal also benefits from the network effect, because someone trying to get away from an abusive SO has plausible deniability if they download Signal on their phone (“all my friends are on Signal” or “the doctor said it’s more secure than email”). Or a whistleblower can send a message to a journalist that included their Signal username in a printed newspaper. The best place to hide a tree is in a forest. We protect us.

My main issue for signal is (mostly iPhone users) download it “just for protests” (ffs) and then delete it, but don’t relinquish their acct, so when I text them using signal it dies in limbo as they either deleted the app or never check it and don’t allow notifs

Alas, this is an issue with all messaging apps, if people delete the app without closing their account. I’m not sure if there’s anything Signal can do about this, but the base guarantees still hold: either the message is securely delivered to their app, or it never gets seen. But the confidentiality should always be maintained.

I’m glossing over a lot of cryptographic guarantees, but for one-to-one or small-group private messaging, Signal is the best mainstream app at the moment. For secure group messaging, like organizing hundreds of people for a protest, that is still up for grabs, because even if an app was 100% secure, any one of those persons can leak the message to an attacker. More participants means more potential for leaks.

When I see E2EE and XMPP mentioned, I think of this blog post by Soatok, outlining some very odd cryptographic choices in XMPP + OMEMO: https://soatok.blog/2024/08/04/against-xmppomemo/

I would very much like to see a richer playing field than just Signal for private messaging, but it’s a tough nut to crack. For exactly which aspect that turns me away from XMPP for E2EE, I think this nails it down:

you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).

When the competition is Signal, these sorts of details matter a lot.