> StartWRT: Start9's fork of OpenWrt, including a modern GUI, that reimagines the router experience from first principles.
I wish them the best of luck with their hardware venture, but a custom fork of OpenWRT is not what I'd want for a router from a small startup.
I can't even begin to count how many startups have done crowdfunding projects for new hardware and tried to get too custom with the software stack before the company went under.
Others already covered the high price for the specs, but we really need to see some benchmarks for things that matter: Routing throughput, VPN throughput, and other real numbers. Faster ports aren't helpful if the CPU can't process packets fast enough.
I also wonder why they wouldn't work with upstream in improving the existing GUI (or upstreaming their improvements), instead of putting the burden of a fork upon themselves.
Working with upstream is most convenient for their users, for them, and for the ecosystem as a whole.
A basic Google search leads me to this article [0].
> On March 27, 2026, Start9 CEO Matt Hill hosted a private unveiling of StartOS 0.4.0, the next major version of the operating system that powers the Start9 Server One. During that same session, Hill also gave viewers a first look at StartWrt, the router’s dedicated operating system. StartWrt is Start9’s fork of OpenWrt with a modern GUI that reimagines the router experience from first principles. The interface is sleek, modern, and a clear departure from the technical admin panels that define most open source router software today.
> Where OpenWrt’s default LuCI interface is functional but technical, StartWrt presented a clean, modern interface designed for users who have never configured a VLAN or written a firewall rule.
When you consider the circumstances a fork is the only thing here that makes sense. You can't just open a pull request to OpenWRT where you are like "Here is our purpose built simplified GUI we designed for our router, please merge."
> When you consider the circumstances a fork is the only thing here that makes sense.
No, because a fork and an overlay are not the same thing. Getting your custom frontend has nothing to do with sharing the maintenance burden on all the grit behind it.
If they maintain only an overlay, what is the burden? Or you mean freeloading by pushing the burden of maintenance to openwrt project? They also don't suffer all the grit of pull request begging.
This really depends on what exactly they're using the word "fork" for here.
All I'm saying is that a full-on fork is not the right thing to do when all you're trying to do is have your own frontend, or modify a small number of packages.
It's not really a binary concept either. It's a scale from "immediate & transparent overlay" (not keeping anything from OpenWrt vendored and just piling on top) all the way to "hard fork" (one-time hard break from source) with lots of steps inbetween.
Also, wtf is "pull request begging"? If you can't get pull requests merged, that normally means the target project doesn't have enough maintainers. In turn, that means you should be going around reviewing pull requests on your own initiative. You don't need anyone's permission to make comments on other people's pull requests (at least not in general.) Just do it. I mean, yeah, some projects have very high or maybe even obnoxious requirements, but in my experience that's very rare and happens primarily with "enterprise" / "corporate" things. Unless proven otherwise, I'll assume most FOSS projects are at least trying to make things work collectively. OpenWrt certainly does.
> designed for users who have never configured a VLAN or written a firewall rule.
I always get the impression that when things are designed this way, you can't configure a VLAN or write a firewall rule, and so far I've never been proven wrong. :/
Honestly, I'm not buying this. This is an ultra niche market and they are trying to target customers outside the product niche with this fork.
If I'm looking for a consumer friendly router, I'll go with an option that is cheap and capable, I don't care about the OS being open source and if I cared about it being open source, I'd prefer it if they don't fork the software in a way that splits the community and where the fork is dependent on their commercial success to the point where I might be stuck with the hardware and no upstream support.
Their OpenWRT wiki page for installing on my router was a mess, but I got through it and took extensive notes about where the page was wrong or confusing. Then I asked for access to their wiki and was… ignored. After a week or so I forgot all the info and the notes started to look like gibberish.
The gui of openwrt is not great. It might be better if you already have lots of experience with linux networking and openwrt specific command line configuration. If not it seems like a mess, very vague and overlapping controls without much explanation. DDWRT and Tomato are much better although openwrt might be more powerful without resorting to straight firewall and routing rules through text.
> we really need to see some benchmarks for things that matter
Honestly, we don't. We know it won't be competitive with the plethora of high performance ARM network SOCs found in commercial routers. If you use this with advanced features enabled (traffic shaping, packet inspection, etc.) on a fast uplink you will be CPU bound, and the CPU isn't fast. This shouldn't be a surprise to anyone that knows why this platform has any appeal.
You don't buy this expecting to max out your 10 Gbps fiber. There are other, valid reasons, but not that, and I'm glad it exists: one day, there will be RISC-V network SOCs that dominate benchmarks.
More open-source forks of OpenWRT and open-schematic router board designs are exactly what we need. It would further raise the cost of planting backdoors in routers at meaningful scale. We're currently too dependent on the OpenWRT project for router firmware. It's a high-payoff target for XZ Utils [0] type of multiyear infiltration by malicious actors.
The StartWrt port supposely adds some nice features, of which VPN chaining looks especially useful. And a better UI will make it more accessible. There are plenty of people out there who are willing to switch out their routers and chain VPNs to escape gov/ISP/big tech surveillance but don't have the technical means to do so. These are welcome improvements to reduce friction if they manage to pull it off.
The specs are not too bad for the price considering this is a startup project. It has 8 cores with per-core performance similar to Cortex-A55 + 4GB LPDDR4 + 16GB eMMC, which is better than most off-the-shelf routers. I wish they released the WIP schematics and code though, because there seems to be nothing at the moment.
And at that point why not OPNSense? OpenWRT for me is what I would run on crappy BestBuy routers that can’t run a proper router OS. OPNSense is 100% amazing.
I don't know about that... I ended up getting a banana pi r3 (great discounts because they were pushing the r4)
I had to make a couple of tweaks for the fan controls (experimenting, i don't even remember if i wrote everything) and now i have a beast of a router with 8 cores, a 1TB NVME, 8GB RAM, and besides routing it hosts a media server and a bunch of containers. (gitea, home assistant, immick, ...)
> Built on a RISC-V processor with an open-source boot stack and operating system, it is the most open router on the market […]
No it's not [cont'd]
> with a fully open-source boot stack (OpenSBI, U-Boot), open-source Linux kernel, and published board schematics.
You can all get all that for both OpenWrt One and Turris. Possibly more, they go beyond schematics on HW design. And that CPU is no more "open" than the libre end of ARM chips elsewhere.
> And that CPU is no more "open" than the libre end of ARM chips elsewhere.
It is amazing how often people seem to forget this. The only thing RISC-V means is that the person designing the cores doesn't have to pay a license fee for the architecture. It doesn't say anything about the open-ness of the core IP itself, let alone the final SoC.
Nothing is stopping you from making a RISC-V chip locked down tighter than Apple's, and nothing is stopping you from making a completely open chip based on the x86 parts whose patents have expired.
Is Start9 a well known company? The page by itself seems indistinguishable from a scam, but maybe they have a reputation that justifies their asking for $250,000?
Are the banana pi boards able to run a mainline kernel or close to it? I have a memory of getting real close to buying one of those, and then reading a comment on HN about having to run their Frankenstein setup
This BananaPi RISC-V router board is officially supported in OpenWRT https://docs.banana-pi.org/en/BPI-RV2/BananaPi_BPI-RV2 and is very affordable. While not as powerful than the Spacemit K1 and having much less RAM, it works rather well and is very stable. Different metal cases available. POE option exist for the board as well.
Orange Pi RV2 is very similar in spec to this star9.com router.
Btw, I don't see anything about mainline in TFA, did I miss that?
FWIW there is also "OpenWrt mainline" and "Linux mainline"; OpenWrt carries a whole bunch of things on top of Linus' tree but I'd still call that "mainline".
Given the similarities in port layout (just missing a HDMI and USB3 header), and that the case is nearly identical, I would guess that this router probably is a custom run of the exact same BananaPi board without those headers. Both also use MiniPCIe in 2026, which is a bit of an odd decision.
A backup WAN can be connected over USB, if it's a backup for graceful degradation when the primary high-speed WAN goes down. USB3 gives you a very decent speed, so if your WAN is not very fast (a typical 300-500 mbps home Internet connection), it can just be adequate.
Turris Omnia NG is also "open source" and has 2x 10 Gbps SFP+ and 4x 2.5 Gbps ethernet ports. StartWRT and Turris OS are both forks of OpenWRT, which is kind of annoying. The Turris project has been around a long time and has an active community.
Quick glance of their page only mentions Turris OS being built on open source. If I can't blow away Turris OS and install whatever, then it's not open and uninteresting.
> there is no open-firmware option for modern WiFi from any manufacturer
I wonder if this could be changed, if enough people got together and had a WiFi chip fabbed, or paid a company to open their firmware? I'm guessing the bar is higher than that, because the WiFi trade assoc. probably mandates closed firmware. So you'd have to create a competing (but open) WiFi standard and probably have to lobby the FCC to let us use it.
RISC-V is quite wimpy this far, so it’s not even clear if it can saturate a gigabit with features turned on. The one benefit is that it doesn’t have Intel IME/AMT, AMD PSP or ARM TrustZone backdoors built-in, but I would be extremely surprised if the Chinese SpaceMiT CPU didn’t have Chinese backdoors of its own.
> it’s not even clear if it can saturate a gigabit
If that's the case then it's not the CPU's fault. I can't open the linked site but assuming it's really the same as a BPI-F3 i.e. a SpacemiT K1 chip, that can do 2.8 GB/sec on large RAM to RAM memcpy using a CPU core i.e. 44 Gbps total, 22 Gbps each read and write. Plus I assume it's got DMA so no need to involve the CPU anyway.
Here is a test I ran in April 2025 on a Sipeed LicheePi 3A same chip).
Although your benchmark is interesting, I don't think it's very relevant here. In my experience, you'll saturate the CPU through packet decoding, routing, and firewalling long before memory becomes a bottleneck.
That's why all network SoCs have hardware to accelerate such thing, otherwise in software alone they can barely handle simple routing at a few hundred mbps.
1 Gb/s is only ~100,000 packets/s at standard MTU. You literally get 10 us/packet which is a eternity. Normal fast-path router operation only really needs to consider the header of <100 bytes/packet, so you are getting ~100 ns of compute per byte of considered data and on even a 1 Ghz processor you are getting over 100 instructions per byte of considered data. Failure to achieve a measly 1 Gb/s really says more about those software implementations than it says anything about the impossibility or difficulty of the problem.
> The one benefit is that it doesn’t have Intel IME/AMT, AMD PSP or ARM TrustZone backdoors built-in, but I would be extremely surprised if the Chinese SpaceMiT CPU didn’t have Chinese backdoors of its own.
That seems worth paying for. How could china hurt me more than my own government?
Yes, you have to decide in your threat model which is worse. There are people who’ve built entire systems on RISC-V FPGA soft cores like Bunnie Huang’s Precursor, but none fast enough to serve as a router.
I helped a bit to develop this UI myself. Support for vlans was baked into it from day 1. The idea being good admin/guest/iot/hosted/etc separation without extra access points.
Rich countries suffer from a first-mover disadvantage: companies existed heavily in building internet infrastructure based on DSL and DOCSIS in the 2000s, so they are now trying to milk every cent of profit out of it while they can. Meanwhile in poor countries "the internet" was a 1Gbit LAN cable daisy-chained between houses, and the first large-scale commercial rollout is fiber - which is pretty much impossible to install these days at speeds below 1Gbps.
Going faster doesn't really cost that much extra. 10Gbps networking gear is 20(!) years old and considered obsolete by the rich countries, you can buy brand-new transceivers for literally $30. Go second-hand or Chinese and you can find them for $5. Basic 10G L3 switches? A bit over $10/port. Same with NICs. Heck, we're now at a point where homelabbers can get a 2x25G link between a pair of servers for less than $100!
It's 2026, and 1Gbps is obsolete. If faster gear is still expensive to you, it is only because you are getting ripped off by the western premium brands like Cisco.
Working in this field - yeah don't underestimate what's available in "poor" countries. Most do better than poorly governed "rich" countries. And don't use it as an excuse to aim lower. CPE class devices do have a pretty long lifetime.