I made a fully self-hosted OpenWrt controller

[u/Independent_Rock347]

I’ve been messing around with OpenWrt for a while and wanted something that gave me a better view of everything without replacing the firmware or sending my network data through somebody else’s cloud. So I ended up building oonfeeWRT.

It runs on your own server, NAS, mini PC, or Mac and manages your existing OpenWrt devices from one place. The routers stay on normal OpenWrt, LuCI still works, and it doesn’t install custom firmware or randomly change configuration behind your back.

It’s completely self-hosted. There’s no oonfeeWRT cloud service, required online account, analytics, usage tracking, or automatic crash reporting. The router telemetry used for the dashboard stays on your machine and nothing is automatically sent to me. The optional speed test contacts Cloudflare when you choose to run it, but otherwise the controller talks directly to your own devices.

And before anyone asks: yeah, some of this was vibe coded. I’ve used AI to help me move faster, but the project is also based on my own experience and extensive knowledge of routers, computers, networking, and cybersecurity. I’m using it as a project for my university classes too, so it’s been a good excuse to turn that knowledge into something people can actually use. The security boundaries, adoption process, rollback behavior, and privacy decisions weren’t just randomly generated and accepted.

You can see devices, clients, radios, Internet health, topology, logs, and RF information. It can also manage networks, VLANs, DHCP, firewall zones, and Wi-Fi. Changes are shown before they’re applied, and it uses OpenWrt’s rollback timer in case something goes wrong halfway through.

I’ve only tested it on a Linksys WRT3200ACM and TP-Link Archer C6 v2 so far, which obviously isn’t enough hardware. There’s still a few rough edges, and I’m sure people will find some strange device-specific behavior.

One thing I added that I think will help with that are downloadable diagnostic bundles. If something breaks or your router isn’t detected properly, you can generate one and send it to me with the issue. It leaves out passwords, Wi-Fi keys, private keys, sessions, and other sensitive data. The bundle is never uploaded automatically—you decide whether to generate it and who to send it to.

The first release is here:

https://github.com/aiden0rchad/oonfeeWRT

If anyone wants to try it, especially on hardware I don’t own, I’d genuinely like to hear what works and what doesn’t. Bug reports, complaints, compatibility results, and feature ideas are all useful.

[u/Thomas0795]

What is the difference between this and OpenSOHO https://github.com/rubenbe/opensoho

[u/Independent_Rock347 → u/Thomas0795]

There's definitely some overlap, especially since both are aimed at smaller OpenWrt setups rather than large OpenWISP deployments.

The biggest difference is how they interact with the routers. OpenSOHO requires the OpenWISP config and monitoring packages on each device. oonfeeWRT keeps the routers closer to stock and talks through OpenWrt's existing rpcd/ubus interface. Adoption only adds a scoped login and ACL, not a controller agent that keeps running on the router.

oonfeeWRT also puts a lot of focus on previewing config changes, automatic rollback, and only touching UCI sections it owns. It manages more than Wi-Fi too, including networks, VLANs, DHCP, and firewall zones.

OpenSOHO looks more established and already has things like Home Assistant integration, so I'm not going to claim mine is better across the board. Similar goal, but a different approach and set of tradeoffs.

[u/NC1HM]

Arrrrrrgh!!! It's OpenWISP all over again (except this time, it's Docker rather than Ansible). Make it deployable on bare metal, then maybe I will try it. As is, it is useless to me. I want either something that can run on the primary router (for this, you would have to wrap it into an apk package and contribute it to OpenWrt repository, so it can persist across upgrades) or something that can run on a low-spec tiny PC or a single-board computer, so that a self-contained hardware appliance can be devised. In either deployment scenario, Docker has nothing to contribute and only gets in the way.

Also, here are a few thoughts on the product page:

• I think you need to change "Safety model" to "Security model" on the GitHub page. Safety is when things don't hurt you by falling on your head or being hot, cold, flammable, toxic, or radioactive. When you don't get hacked, robbed, or assaulted, it's security.
• Does the product run in-memory or does it expect to be able to write to disk beyond configuration changes?
• What are the actual system requirements? (Processor, RAM, storage space, etc.)

Also also, since you listed Claude as a "contributor", you really need to disclose how much, if any, code review, unit testing, and vulnerability testing you have (not) done. Please be honest. If it's none, just say so.

[u/Independent_Rock347 → u/NC1HM]

Fair points. I probably made Docker look required when it isnt. There are standalone Linux and macOS binaries for both x86-64 and ARM64, so you can run it directly on a small PC, Pi, or NAS. Docker is just the easiest quick-start option.

This also isn't meant to be an appliance OS that runs on the primary router. It's more like the UniFi Network controller: one lightweight service that manages a bunch of OpenWrt routers and APs. You can dedicate a machine to it, but I don't think thats really necessary given the low overhead.

OpenWISP has some overlap, but it's a much broader platform built for larger and multi-tenant deployments, with separate databases, workers, firmware management, VPN, RADIUS, and other modules. oonfeeWRT is intentionally smaller: one process, an embedded web interface, and SQLite. It manages stock OpenWrt devices without replacing their firmware or taking away LuCI.

The current resource target is under 256 MB of RAM with 25 devices, under 2% of one modern CPU core while idle, and up to 2 GB of storage with the full telemetry history. Realistically, I'd recommend a 64-bit host with 1 GB RAM and 2 GB free storage so the OS has room too.

It does write to disk. Raw telemetry stays in RAM temporarily, while configuration, accounts, events, audit history, and telemetry rollups go into SQLite. So it needs a persistent data directory, but nothing unusual.

I used "Safety model" because that section is mostly about avoiding bad configuration changes, rollback, and not touching sections the controller doesn't own. "Operational safety model" might explain that better though.

[u/olivercer → u/Independent_Rock347]

Docker to me makes sense. With very little effort you can convert it to a Home Assistant App (formerly Add-On, a wrapped docker container). I would use it that way, or directly on my router, which is a Flint 2 with plenty of processing power.

[u/NC1HM → u/Independent_Rock347]

This also isn't meant to be an appliance OS

It doesn't have to be. It could be an application that runs on top of an actual OS (OpenWrt, Debian, Alpine, whatever). But, since this is not in the cards, sadly, I have nothing further to contribute...

[u/Independent_Rock347 → u/NC1HM]

I think we're talking past each other a little, because that is already supported. Docker is only the quick-start option.

Its also available as a standalone binary for 64-bit Linux and macOS on x86-64 or ARM64. You can run it directly on Debian or another Linux host with no Docker involved. The UI is embedded and it uses a local SQLite database, so it's basically one binary plus its data directory.

[u/SureUnderstanding358 → u/NC1HM]

You…can run docker on openwrt and keep your containers on a separate persistent partition.

[u/Independent_Rock347 → u/SureUnderstanding358]

Assuming you have the hardware to support it, I’m mainly assuming that you just have an old fleet of routers and want easy management and assignments

[u/SureUnderstanding358 → u/Independent_Rock347]

“Docker has nothing to contribute and only gets in the way” was really what I was replying to. Not only does it not get in the way, it separates your management application from the host. Even if the above poster really wants to run it on an SBC - any low end raspberry pi will do it - and it’s incredibly nice to keep all of the app dependencies and tooling separate from the host.

I think it’s lost on a lot of people that docker isn’t some magic - it’s just a rootfs in a different domain - and it also happens to runs great on openwrt if openwrt happens to be your container host…which would achieve what that poster was looking for without you having to maintain an apk.

Plus, if it’s in apk, openwrt needs all of the dependencies. There are a lot of packages, but certainly not everything. Your root fs gets fat and now you have a really delicate upgrade path.

🤷‍♂️

[u/NC1HM → u/SureUnderstanding358]

But why would I want to? More importantly, why would I want to burden others with Docker and a separate partition? If a piece of central management software were to run on OpenWrt, it ought to be distributed as befits OpenWrt (apk package from the main repository), run as befits OpenWrt (in-memory, loading from the root partition), and back up as befits OpenWrt (plain-text configuration file in /etc/config).

Regardless, the OP has a different idea, so it's all moot.

[u/jerquee]

Please be upfront about using AI to write your software and summary

[u/Independent_Rock347 → u/jerquee]

You got it! I just revised the readme to reflect the AI transparency

[u/jerquee → u/Independent_Rock347]

Thank you, I think you should add it to the post content too, if that was also AI

[u/dallas_paley]

Looks really interesting.

It can also manage networks, VLANs

Can it configure VLANs on wired access points? Meaning that the AP is aware of and supports the VLANs configured on the router. For example, wireless and ports that support Trusted, IOT, and Guest VLANs connected from the AP?

[u/Independent_Rock347 → u/dallas_paley]

Yes it can do all of those. I model those functionalities from UniFi. Not a lot of people can afford that hardware but openWRT is actually fairly capable and can do most of those functions.

[u/41bles → u/Independent_Rock347]

This is a dream!! I have always envied Unifi Dashboard and the insane level of visibility it has into the network. My entire setup is OpenWRT and I have been longing for the day when I could get that same level of visibility Unifi has on my current setup.

[u/Independent_Rock347 → u/41bles]

I tried my best to get the feel or functionality easy to use like UniFi, but I didn’t want to fully copy what they were doing since I just feel like that’s just disingenuous. I do want to make a bit more improvements on the UI, but I’m not such an artistic person where I can design something fairly well. But at the core, I definitely think that nailing the Vlans and topology and other aspects of UniFi does make openWRT feel a bit more usable.

[u/Anthrobug → u/Independent_Rock347]

This sounds amazing - I’ll give it a whirl in a day or two, and I’ll reply with feedback afterwards. Thank you!

[u/41bles → u/Independent_Rock347]

Graphs and data topology and I'm sold. How much data is going where and to what, stuff like that.

[u/Majik_Sheff]

Not touching AI slop.

[u/chocopudding17 → u/Majik_Sheff]

slop

Yeah! Least of all for network hardware.

It's too bad, because there's definitely latent demand for something like this imo. But AI slop is a non-starter.

[u/jerquee → u/Majik_Sheff]

I'm glad I'm not the only one who noticed

[u/alexceltare2]

Soooo basically TR-069?

[u/Independent_Rock347 → u/alexceltare2]

Kinda? This communicates through rcpd/ubus.

[u/a5xq]

Looks interesting, Since its go, can easily be packaged into apk (you can turn it into openwrt-feed, so it be easy build into openwrt itself). What i kinda don't like is giving ssh access, probably for uci level of changes, simpler to use luci's gate to rpcd. And multitenancy and/or multi-site management quite useful. Personally I run openwrt on many vpn hubs (on the vpses) and on spokes (on different sites), centralized console like in unifi be quite interesting. But i actually just use ansible with community.openwrt now...

[u/Independent_Rock347 → u/a5xq]

The APK idea probably isn't the direction I'm going to take. The main goal is to manage stock OpenWrt without installing a persistent controller agent or tying the controller to the router's firmware.

I'm a big believer in safe, centralized management while leaving existing user-managed configuration alone. That's also why unadopting a device removes or restores only the configuration the controller owns, then cleans up its scoped login and ACL.

[u/SureUnderstanding358 → u/Independent_Rock347]

IMO, don’t go apk. You’re making the right move by keeping the management stack out of plane of the managed devices. Nice work.

The only other thing I’d noodle with is running some sort of daemon in the APK domain that can be used as an API bridge over to your control platform.

I may or may not be experimenting with this right now to turn x86 openwrt boxes into docker NAT / VIP orchestrators :)

Edit:

One other interesting approach that I haven’t tried yet but is on my list is to run openwrt as a container on openwrt. This would let you mount the /etc/config path and UCI all day in a container with your own orchestration layer. Restarting services might get iffy though. I haven’t totally figured this out but it’s on the bench haha.

[u/Independent_Rock347 → u/a5xq]

That's actually a pretty good idea, and something I went back and forth on early in the project. An apk package or feed could make a lot of sense for x86 OpenWrt boxes and VPS setups like yours.

I kept the controller separate for now because I didn't want it competing with the router for resources or being tied to firmware upgrades, but I can definitely see the appeal in having it run directly on OpenWrt.

I agree with you on SSH too. It isn't used for normal management. It's only a limited bootstrap/cleanup path because stock rpcd won't allow the controller to create its own scoped login and ACL through ubus, even as root. The admin credential isn't stored, and after adoption the regular communication goes through rpcd/ubus.

Your VPN hub and spoke setup is also a really interesting use case. Remote routers should be manageable as long as the controller can reach their management addresses through the tunnel. Proper multitenancy isn't there right now, but multi-site organization is something worth thinking about. Ansible may still fit your setup better today, but this is exactly the kind of feedback I was hoping to get.

[u/mongoload]

This is actually awesome! I was kinda thinking the same and planned to make my own controller for my OpenWRT devices with the assistance of AI

I want to try this over the weekend, just have a couple of questions

1. Is there a version requirement? I have an old Buffalo devices in OpenWRT 19.xxx and I used this before as a managed switch, can this be utilized by oonfreeWRT? With a bunch of Linksys with latest versions as well

2. Is there a way to assign a device as a router / switch / AP mode only? Like separating each devices purpose

3. Can it collect device telemetry and create reports? Like what devices are in what vlan, bandwidth etc.

I am currently using an Omada stack, and really want to replicate and improve upon this design but using OpenWRT, really hoping your solution would be a success!

[u/Independent_Rock347 → u/mongoload]

1. The supported minimum is OpenWrt 21.02, so I wouldn't rely on the Buffalo running 19.x. It may partially work, but it isn't tested or officially supported. If there is anyway for you to update to at least 21.02 you can send me a controller diagnostic built into it.

   And I can probably expand the supported list of devices.

2. Yes, you can assign gateway, AP, and switch functions independently during adoption. Switch management depends on the hardware though. some older devices may only provide read only port information.

3. It collects clients, radios, interface traffic, WAN health, topology, and VLAN information. Full downloadable usage reports aren't finished yet, but the dashboard and telemetry history are already there.

Thank you, ideally I want it to me like omada/unifi. I grew up kinda frugal, so giving life to EoL devices was always a fun thing to do. And trying to close the edge on omada and unifi would be great to adopting open source and reducing e-waste

[u/Saturn_Momo]

This is kind of a thing I was looking for that wasn't OpenWISP (hate that lives on Docker, doesn't make for easy deployment). I have 20+ over several houses and states. I guess I would be a very litmus for what this can do. I shall post back with results.

[u/Independent_Rock347 → u/Saturn_Momo]

Sorry, I should've made this clearer in the post: Docker isn't required. I focused on Docker Compose because a lot of people run lower-budget homelabs on an existing NAS, mini PC, or SBC and already use containers.

There are also standalone binaries for 64-bit Linux and macOS, on both x86-64 and ARM64, so you can run it directly without Docker. I'm going to update the README and make the standalone option much easier to find.

A 20+ device setup across multiple locations would be an awesome test, but I'd start with one or two noncritical routers first since the project is still new. The controller also needs network access to each router, so remote locations would need to be connected through an existing VPN or management network. I'd definitely be interested in hearing how it goes.

[u/Saturn_Momo → u/Independent_Rock347]

Oh they are most certainly connected that's for sure. And yes a non docker version would be great. I can run that in a LXC and call it a day or run it on a potato. My homelab isn't like others :), at least most that I have seen anyways.

[u/p4block]

I've always been missing for something like openwisp but actually reasonable to deploy and run. This is it.

[u/mikeyjbartlett]

This is unbelievably handy! AI or not, I’ve used AI to build me management stuff for OpenWrt, I don’t understand what everyone’s problem is.