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.

some ominous comments stating that it is practically unmaintained (which is not true)

Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn’t need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

But let’s suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is “important” enough. That’s a choice, sure, but let’s see if that holds water. Here is the project’s response to an issue opened in January, with the response being in February that confirms a logic bug and schedules it for the next release.

That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that’s understandable for FOSS project developers, for whom the project is not their day job.

But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is “rock solid”. And that’s even before looking at the code.

TL;DR: the premise of the question is wrong. Conduit is not maintained.

Given that your original problem was related to WAN upload performance, why did your investigation lead you to Ethernet flow-control? An ISP connection generally deals in packets at Layer 3 (“network”, eg IP) of the OSI model, whereas Ethernet is a Layer 2 (“data-link”) layer technology.

If there is a bottleneck at your WAN modem, then that will cause congestion at layer 3, but Ethernet flow-control can only deal with congestion that exists at layer 2. What has likely happened is that you have configured your gateway so that congestion at layer 3 is mirrored onto your layer 2 LAN. And if flow-control is enabled, then that would result in back-pressure propagating back to your VMs. Your VMs will then slow down their layer 2 rate, which conveniently forces the layer 3 traffic to also slow down.

This is an incredibly round-about and inefficient way to do traffic shaping. You should not configure a network so that L3 and L2 issues bleed into each other. A major consequence of using flow-control in this way is that it reduces the capacity of your LAN, even for traffic that isn’t going out to the WAN.

The customary approach for keeping L2 and L3 separate is to perform traffic shaping solely at the threshold where your LAN meets the bottleneck. This would be OpenWRT, since after OpenWRT would be the WAN (50 Mbps upload). OpenWRT would be configured with some sort of QoS feature so that certain L3 packets are selectively dropped.

You cannot do effective L3 traffic shaping without dropping packets. In fact, all competent L3 protocols expect dropped packets in order to slow down their data rate: SCTP and TCP have their own exponential congestion control mechanism, UDP simply accepts that some packets won’t make it through, and QUIC has its own mechanism as well. Simply put, all L3 protocols only understand one signal that tells them to slow down, and it is to drop a few packets. They will adjust accordingly, finding the stable equilibrium where traffic flows at the very cusp of congestion.

The Main reason for this problem seems to be the down-stepping of 10Gbit traffic to 1Gbit devices

This is a red-herring, for the reasons I’ve outlined above. With 1+ Gbps connections on your LAN, your L2 network is an order of magnitude faster than your WAN upload. It cannot be the case that a fast LAN makes a slow WAN slower. This is not RF impedance where step-transitions cause reflections; we are dealing in packet-switched networks, where queuing theory controls.

TL;DR: please try OpenWRT QoS instead

The latter part of Rule 3 is the issue:

If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

There is exactly one sentence in the post which relates to self hosting, buried in the middle of a paragraph, and one which could be plausibly understood in two ways: 1) we (Anonymous) are recruiting the working-class people who maintain the infrastructure that keeps the world running, or 2) we (Anonymous) are seeking people that know how to build self-sufficient infrastructure. Only the latter might be vaguely self-hosting. And in no circumstance would I say the sentence is “obvious”.

I won’t rules-lawyer the other points, but I repeat the old adage: when you hear hooves, think horses, not zebras. If a post is skirting multiple community rules, and the community is downvoting it into oblivion, then all signs point to a post that shouldn’t be here.

This is not a good idea: having to search means an implicit reliance on a search engine. Even with a trustworthy web search – and those are becoming fewer and fewer – why add this complication? The URL doesn’t even have to be large; it just has to be readable.

Even worse is when there’s an adversary: what would stop someone from buying getcontinuwuity.org but have it be pro-Big Tech propaganda, with tracking cookies galore, and then pay Google or Bing to put it at the top of the web search results?

Whereas in 2026, a URL is not confusing at all to include. People know what http:// or https:// mean. Even big brands might not own their own product name’s domain. This exact problem came up just six days ago: https://www.neowin.net/news/paintnet-can-finally-be-downloaded-from-the-right-place/

The whole point of marketing is to reduce the barriers for people to find something useful or valuable. Adding an accessibility barrier is antithetical to that objective.

I think this is a Rule 5 violation for this community, and maybe even Rules 3, 4, and 7.

This is the homeserver written in Rust, right?

A suggestion: wherever a QR code is included, the human-readable content should be included next to it. Not everyone has a QR code reader handy, or their reader has the bad habit of immediately opening links or apps. In this case, I see that it just goes to https://continuwuity.org/ and is benign, but others may be apprehensive at naked QR codes.

(there’s obviously an exception for QR codes that are intended to convey machine info, like TOTP codes)

I’d like to draw a comparison: a cozy wood fire versus central heating. In the right time and place (eg camping in the woods), a wood fire is both very practical and very useful. Meanwhile, most homes built in the past 70+ years in the USA have central heating (or are somewhere that doesn’t need heating at all) and the benefits are quite obvious: automatic temperature regulation, supplied by a utility, and low or no local emissions. And yet, there will still be rural homes that are heated exclusively by a wood stove, located in the middle of the living room, whose iron construction stores and radiates heat well after the fire has gone out.

Do I bemoan individual homes that use a wood fire? No, not really. The reality is that a grand, overwhelming majority of people don’t have wood fires anymore. Even when air quality is poor, prohibiting wood fires in a few rural homes isn’t exactly what would clear up the air.

Now, it would be a vastly different story if city-dwellers all had wood fires. When every home in a neighborhood is building and burning a wood fire, the results are disastrous: horrific PM2.5 in the air, soot coating everything, substantially reduced energy efficiency, and mass logging just to keep the wood supply. A mole-hill quickly becomes a mountain of problems when it’s at scale.

So to that end, I would very much like to see commercial-scale AI reigned in, as the external costs have already gotten out of hand. What they have built is more correctly called a wildfire, not a wood fire. But where does that leave small-scale AI/LLM users? They can weigh the cost/benefits for themselves, provided that they don’t harm other people or resources in the process.

But that brings us back to a cozy wood fire versus central heating: at small scale, a wood fire struggles to heat an entire modern American home (ie 2500 sq ft; or 232 sq m). Yet central heating does it with ease. Who then will be interested in this endeavor? Probably only those with a love for the camping aesthetic, and other enthusiasts.

At this point, it has become more clear what the utility of small LLM models is, and they do pale in comparison to larger LLM models. If small LLMs are what sensibly survives into the future, then that’s essentially a cap on their capabilities, given a want to avoid burning the planet to run anything larger. The only way out would be for substantial developments in the energy efficiency of small LLM models, but that’s not where the interest is.

No one is seeking to build a more efficient wood fire.

There are subscription costs for homelabbing?

I’ve even seen people vibe code ethernet drivers for freeBSD.

Please make sure to read what considerations that developer had before undertaking that effort using an LLM: https://github.com/Aquantia/aqtion-freebsd/issues/32#issuecomment-3997341698

Specifically, they (the human) were kept in the loop for the entire process, which included referencing the working Linux driver to do a clean-room reimplementation. This already means they have some experience with software engineering to spot any issues in the specifications that the LLM might generate.

Also, Aquantia (before the merger) already had a published FreeBSD driver but it hasn’t been updated. So this port wouldn’t have to start from zero, but would be a matter of addition support for new NICs that have been released since, but Aquatia hadn’t updated the driver.

This is very much not an example of an Ethernet NIC driver being “vibe coded” from scratch, but a seasoned engineer porting Linux support over to FreeBSD, a kernel that already has a lot of support for easily adding new drivers in a fairly safe manner, and then undertaking a test plan to make sure the changes wouldn’t be abject slop. That’s someone using their tools with reasonable care. In the industry, this is called engineering.

Admiration for what people can do with the right tools must always be put into the right context. Even with the finest tools, it’s likely that neither you nor I could build a cathedral.

The approach isn’t invalid, but seeing as you already have the framework set up to deny all and log for IPv4, the same could be done with IPv6.

That is to say, your router advertises an IPv6 gateway to the global internet, but you then reject it because your VPN doesn’t support v6 (sadly). I specifically say reject, rather than drop, because you want that ICMP Unreachable (administratively prohibited) message to get returned to any app trying to use v6. That way, Happy Eyeballs will gracefully and quickly fall back to v6. Unless your containers have some exceptionally weird routing rules, v6 connections will only be attempted once, and will always use the route advertised. So if your router denies this attempt, your containers won’t try again in a way that could leak. v6 leaks are more likely when there isn’t even a route advertised.

This makes your apps able to use v6, for that day when your VPN supports it, and so it’s just a question of when the network itself can be upgraded. IMO, apps should always try for v6 first and the network (if it can’t support it) will affirmatively reply that it can’t, and then apps will gracefully fall back.

This also benefits you by logging all attempted v6 traffic, to know how much of your stuff is actually v6-capable. And more data is always nice to have.

Very interesting! Im no longer pursuing Meshtastic – I’m changing over my hardware to run MeshCore now – but this is quite a neat thing you’ve done here.

As an aside, if you later want to have full networking connectivity (Layer 2) using the same style of encoding the data as messages, PPP is what could do that. If transported over Meshtastic, PPP could give you a standard IP network, and on top of that, you could use SSH to securely access your remote machine.

It would probably be very slow, but PPP was also used for dial-up so it’s very accommodating. The limiting factor would be whether the Meshtastic local mesh would be jammed up from so many messages.