litchralee

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”.

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.

< gets off soap box>

I suppose it’s worth mentioning that the 3224 datasheet suggests that it’s perfectly capable of running at 3.7 volts directly, since it has a wide voltage range from 1.8v to 5.5v absolute. But I imagine you have other ICs that need the 5v supply.

I’m not entirely familiar with what you mean by a “convertor”, but I presume it’s some sort DC to AC function. Given the output loading, 3 amps through that Toshiba MOSFET seems reasonable enough, with the power dissipation being something like 0.3-0.5 W max, depending on switching speed.

A push-pull BJT configuration seems like it could be appropriate, if your application will be unbothered by limiting the Vgs to a max of 5.5v (the 3224’s max supply voltage). The MOSFET in question seems to be good for Rds(on) below 20 mOhm at that voltage, so it seems fine for at least a handful of amps.

If you are doing higher frequency switching than a few kHz, then you probably want to use a driver IC. And especially so if you have a higher voltage bus than the 5v needed by the ATTiny.

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-founded 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, does 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.

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.

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 UI 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.

the original switch (as it looks good) which it turns out, does not really appreciate having to switch 230V instead of the 12V (or 24V?) it was designed for. I believe I can patch up the switch to work as designed, however I do want a better solution to switching the lamp on and off.

Please, please do not ever subject electric components to more than their rated voltage. Unless the switch has an overt label that says it is rated for: 1) 230 volts, and 2) AC, this is a recipe for tragedy.

I will briefly explain why, and then get to the suggestions. In a nutshell, components designed for 12 volts use closer spacing between conductors, premised on air’s natural insulating ability. Likewise, the insulation and plastic housings are designed to withstand that low voltage without becoming a hazard. But higher voltage means the spacing must be wider, the insulation thicker, and above 60 volts is when more strict regulation come into effect, because that’s the international threshold for where there is a serious risk of fatal electric shock.

As for DC vs AC switches, they are built differently to suppress arcs that form when opening the contacts. When a manufacturer gives the voltage rating for both DC and AC, it is often the case that one is substantially lower than the other, depending on which type of arcs they intended the switch to safely suppress. This is a worst-case rating, though, and a modern LED light bulb is unlikely to cause arcs (except when it’s dying).

To my knowledge, there are no common pre-built relays that provide their own low-voltage DC supply. Some relays do provide low-voltage AC (eg 24 VAC to control 240 VAC), but that doesn’t help you since that’s still putting AC into a DC switch.

However, a fairly safe approach would be to use a 230 VAC relay with the most common, safe power supply in the world: a USB phone charger. Provided that your relay can switch on 5 VDC, it should be easy enough to find a small USB charger that can be hidden inside the lamp, wired safely to 230 VAC, and that feeds 5 VDC to your existing tractor switch, which connects to the relay.

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

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: neowin.net/…/paintnet-can-finally-be-downloaded-f…

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.

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 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 agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic).

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.