openwrt-daede: dae and daed behind one LuCI panel on OpenWrt

What openwrt-daede actually puts on the router

This is a packaging repository, not a new proxy. It assembles three things that upstream ships separately: the dae kernel, the daed distribution (described in the README as daed app plus dae-wing plus the dae core plus outbound plus quic-go plus an embedded web panel), and luci-app-daede, the LuCI front end. The stated purpose of the LuCI app is that one UCI configuration serves both backends, so switching between dae and daed does not require reinstalling anything.

The audience is narrow and specific. You need an OpenWrt router, version 24.10 or later with 25.x recommended, and you need to be comfortable installing packages from a third-party feed rather than from the official OpenWrt repositories. The README points at kenzok8/imagebuilder for firmware that already supports dae and daed, which tells you the author expects most users to either flash a prepared image or add BTF to an existing one.

The value proposition is not the proxy itself. dae and daed exist upstream. What this repository adds is a build chain that pins upstream commits, freezes source into self-hosted tarballs, and produces architecture-specific kernel packages including armv7, which the README says required porting a vmlinux-arm.h patch from sbwml/openwrt_helloworld to make trace eBPF compile.

The build chain: pins.env, frozen tarballs and PGO

The README is unusually explicit about how the binaries are produced, and this is the part worth reading before you trust the feed. Upstream commits are locked in ci/pins.env, described as the single source of truth. An assembly workflow freezes those fixed commits into self-hosted tarballs published in this repository under dae-src and daed-src, and writes PKG_HASH. The OpenWrt SDK then compiles only that frozen source. The claim is that an old commit stays reproducible even if upstream force-pushes or deletes a repository.

On top of the frozen source sit three optimizations. The dae core tracks daeuniverse/dae main, with olicesx's performance fork merged in as a baseline at assembly time. quic-go carries a self-maintained patch under ci/patches/quic-go/ that the README describes as a B-tree node pool optimization. And the build uses a vendored PGO profile at ci/default.pgo with -pgo=auto, plus Go 1.26 with GOEXPERIMENT=newinliner,simd, static linking and -trimpath.

The dependency table is honest about what is not closed. PGO is vendored and fully self-contained. quic-go is described as fully closed and in sync with upstream. The dae core follows official main with the performance fork as a frozen baseline. But outbound is marked half-closed: the README calls it a 130-commit divergence that still rides on the olicesx branch, mirrored under kenzok8 in case the original disappears. That is the weakest link in the chain, and the README says so rather than hiding it.

Installing openwrt-daede and starting the first backend

The README gives a one-line installer. It pipes a script from the repository's scripts directory into ash, which is the shell on OpenWrt.

wget -O - https://raw.githubusercontent.com/kenzok8/openwrt-daede/refs/heads/main/scripts/install.sh | ash

For networks where GitHub raw access is slow, the README offers a mirror through ghfast.top with certificate checking disabled. Note that the second command deliberately skips TLS verification, which is a trade-off you are accepting when you use it.

wget --no-check-certificate -O - https://ghfast.top/https://raw.githubusercontent.com/kenzok8/openwrt-daede/refs/heads/main/scripts/install.sh | ash

A second path is the release feed, run on the router itself. The setup script detects the SDK version (24.10 or 25.12) and the CPU architecture, checks whether a feed exists for that architecture across three index formats (Packages.gz, APKINDEX.tar.gz, packages.adb), falls back to all if not, downloads the matching public key, writes the feed into customfeeds.conf or /etc/apk/repositories without duplicating entries, and runs opkg update or apk update. If signature verification fails it retries with --allow-untrusted.

wget -qO- https://down.dllkids.xyz/openwrt-feed/openwrt-feed-setup.sh | sh

After that, the README shows the package install for the apk-based path.

apk update && apk add dae daed luci-app-daede

First real use is three steps in the README: open LuCI under Services, then daede; pick the backend, dae or daed; import a configuration file and start it. There is no command-line example for the config file itself. The README links a wiki page titled as a beginner's guide for the dae backend covering subscriptions, nodes, groups, routing and DNS, so that is where the actual configuration syntax lives.

The BTF requirement is the failure mode that stops most installs

dae and daed use CO-RE eBPF, and the README states plainly that the runtime needs kernel BTF at /sys/kernel/btf/vmlinux. Kernels built with CONFIG_DEBUG_INFO_BTF carry it, and the README names ImmortalWrt 25.12 as an example. Stock OpenWrt and online ImageBuilder images often do not enable it, and in that case daed fails to start.

This is not a warning you can ignore or work around with a config flag. The README offers two remedies. Install the matching kenzok8/vmlinux-btf package, which the one-click installer is said to detect and pull automatically for your kernel and architecture. Or flash a firmware built by kenzok8/imagebuilder, where the kernel already has BTF enabled.

The dependency list reinforces how deep the kernel coupling goes. kmod-sched-core, kmod-sched-bpf, kmod-veth, kmod-xdp-sockets-diag and kmod-nft-tproxy are all listed as requirements, alongside ca-bundle. That is five kernel modules for one proxy. If your router's kernel does not have the matching module set, or you are on a vendor firmware that will not accept them, this project is the wrong tool regardless of how good the datapath is.

The other limitation is structural. The outbound component still rides an upstream branch with a 130-commit divergence. The README frames the design philosophy as internalizing volatile intermediate layers over time, which is a reasonable plan, but it also means the current release depends on a fork that has not yet been absorbed.

How this differs from running upstream dae directly

The obvious alternative is daeuniverse/dae and daeuniverse/daed themselves, installed from their own releases or built from source. The difference in approach is the build pipeline, not the proxy behavior. Upstream gives you the reference binaries. openwrt-daede gives you binaries compiled from a frozen snapshot with a performance fork merged in as a baseline, a vendored PGO profile, a patched quic-go, and Go 1.26 with an experimental inliner and SIMD enabled.

Whether that produces a measurable speedup is something the README asserts but does not quantify. It says the result is faster than packaging upstream directly. No benchmark numbers appear, and there is no methodology section describing how the PGO profile was sampled beyond the file being self-sampled and vendored. Treat the performance claim as a design intent rather than a verified result.

The second difference is reproducibility. With upstream, a force-push or a deleted branch can break an old build. Here, pins.env plus the self-hosted tarballs plus PKG_HASH are meant to make historical builds survive upstream churn. If you maintain routers in the field and need to rebuild the exact same package months later, that property matters more than any percentage.

The third difference is the unified LuCI panel. Upstream daed has its own web UI. This repository adds a LuCI app that drives both dae and daed from one UCI config, and the README states the kernel can be switched without reinstalling. If you already prefer daed's own dashboard, the LuCI layer is extra surface you do not need.

Maintenance cost, release cadence and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-17. Three releases appear in the recent list: v2026.09.14, v2026.09.13 and v2026.09.07-r2. That cadence implies frequent rebuilds, which cuts both ways. You get upstream fixes quickly, and you also get a moving target if you pin versions in your own deployment.

The upgrade path is the same script as the install. The README's uninstall path is a separate script in the scripts directory, piped into ash the same way. There is no documented rollback procedure if an upgrade breaks the datapath. The README does not document rollback, and it does not describe how to pin a specific release version when installing through the feed. If you need deterministic upgrades, you are relying on the frozen tarballs and PKG_HASH in the build system rather than on anything the install script exposes.

The licence is AGPL-3.0 per the repository metadata, and the README defers to the LICENSE file in the repository. AGPL-3.0 is a strong copyleft licence with a network-use clause. If you redistribute a router image containing these packages, or expose modified code over a network, the obligations differ from permissive licences. That is a question for your own legal review, not something this article can settle.

One more cost: the README depends on external infrastructure. The feed lives at down.dllkids.xyz, and the one-click installer pulls from raw.githubusercontent.com or the ghfast.top mirror. Availability of any of those three affects whether a fresh install works.

Editorial conclusion

Adopt it if you already run OpenWrt 24.10 or 25.x on x86_64, aarch64 or armv7 hardware, you want dae's eBPF datapath rather than a userspace proxy, and you are willing to confirm /sys/kernel/btf/vmlinux exists before installing. Skip it if you are on stock OpenWrt without BTF and do not want to add a vmlinux-btf package or rebuild firmware, or if you want a proxy you can reason about entirely in userspace. Verify first: that the imagebuilder or vmlinux-btf route matches your exact kernel and architecture, and that you have read ci/pins.env, since that file is where every upstream commit is pinned.

Frequently asked questions

Official sources

1. Issues
2. kenzok8/openwrt-daede on GitHub
3. License: AGPL-3.0
4. README
5. Releases