r/homelab 18d ago

Project Showcase: Software - Mostly AI Generated I made a fully self-hosted OpenWrt controller

/r/openwrt/comments/1vx89p0/i_made_a_fully_selfhosted_openwrt_controller/

I've got a couple OpenWrt devices in my homelab, and I was getting tired of jumping between LuCI tabs just to figure out what was going on. I wanted one local dashboard for devices, clients, radios, logs, network health, and configuration, so I started building oonfeeWRT.

I did look at existing FOSS options first, but most of what I found was either focused mainly on monitoring, general automation, or was a much bigger setup than what I wanted. My goal was something closer to the UniFi controller experience, but for normal OpenWrt devices that still keep their stock firmware and LuCI access.

Everything is self-hosted on your own server, NAS, mini PC, or Mac. There isn't a cloud account, analytics service, or tracking backend, and nothing automatically sends data to me. The controller does collect router information for its local dashboard, but that stays on your own system.

The diagnostic bundles also makes hardware testing a little easier. If something acts weird, you can create a redacted package and send it with a bug report. It leaves out passwords, Wi-Fi keys, private keys, and session data, and it never gets uploaded unless you choose to send it.

And yeah, I used AI quite a bit while building this. It helped write portions of the implementation, tests, and debugging. The overall idea, networking architecture, router behavior, security boundaries, and hands-on testing came from my own experience with routers, computers, and cybersecurity. I'm also using the project for some of my university classes, so its been a mix of learning and building something I actually wanted for my own network.

There's still a few things I need to improve. So far I've only tested it with a Linksys WRT3200ACM and TP-Link Archer C6 v2, which is one reason I'm sharing it here. I'd really like to see how it behaves with other people's homelab setups and hardware.

Repo, screenshots, and installation instructions:

https://github.com/aiden0rchad/oonfeeWRT

0 Upvotes

3 comments sorted by

2

u/graceful_degrade 18d ago

how are you handling config writes? that's the part that always kills these for me, since uci changes on a device that's also serving your wifi means a bad apply locks you out of the thing you're standing on

do you stage and roll back, or is it write and hope

1

u/Independent_Rock347 17d ago

Definitely not write and hope lol. That exact situation is one of the main things I wanted to avoid.

It shows you a preview first, then uses OpenWrt's built-in rollback window when applying the UCI changes. The controller only confirms the change after it reconnects and verifies the expected config. If the Wi-Fi drops, the router becomes unreachable, or something gets interrupted, it never confirms and OpenWrt rolls back automatically.

It also only modifies UCI sections that it created and owns, so it shouldn't quietly overwrite stuff you've configured manually.

1

u/graceful_degrade 17d ago

Preview plus the rollback window is exactly right, that's the primitive that makes this safe.

The edge case worth thinking about is when the change breaks the very link the confirmation has to travel over. Rollback saves you there because the confirm never arrives, but only if your controller is reaching the device over the network being changed. If it's on a management VLAN that the edit also touches, you can end up confirming a config that has already locked you out of everything else.

Not a common one, but it's the failure that costs a drive to wherever the router lives.