openwrt-passwall-build: prebuilt Passwall packages for OpenWrt routers

A package feed for a project that normally means building an image

The stated purpose of this repository is narrow and precise: it is a binary distribution of the Openwrt-Passwall project, built with the official OpenWrt SDK. That framing explains the entire design. OpenWrt itself is not a distribution you install onto a router; it is a firmware you compile per device, and the official SDK exists so third parties can build packages against a target without producing a full image. Most people who want Passwall on a router do not want to run a cross-compilation toolchain, so a project that produces signed binaries for common architectures removes that barrier entirely. The audience is a router owner who wants the LuCI application, not a firmware engineer. The package it delivers is luci-app-passwall, and the configuration surface you get afterwards belongs to the upstream Passwall project rather than to this repository.

Two install paths split along the OpenWrt package manager change

The installation instructions are organised by package manager, and the dividing line is a version of OpenWrt. Releases from 25.12 onward, along with snapshot builds, use apk, the newer package manager. OpenWrt 24.10 and older use opkg, the older one. This is not a stylistic choice by the project; it reflects a change in the firmware itself, and following the wrong set of instructions for your router will not work. The consequence for a reader is that identifying your OpenWrt release, and whether it is a stable release or a snapshot, decides which section of the documentation you need. Both paths follow the same three-step shape: add a key, add a repository feed, then install the package, and the feeds themselves are the same three names in both cases, being the LuCI app, the packages it depends on, and a passwall2 feed.

Adding the apk key and the three repository feeds

On an apk-based system the first step is to fetch the signing key and place it in the keys directory, and the second is to write feed entries into the custom feeds list. The feed URL is assembled from the release and architecture read out of the system's own release file, so the same snippet works across models rather than needing a hardcoded path. Each of the three feeds appends its own packages.adb line. A separate variant of the same snippet points at a snapshots directory instead of the releases directory, for people running a snapshot firmware build, where only the architecture is needed because there is no release number to derive.

    read release arch << EOF
    $(. /etc/openwrt_release ; echo ${DISTRIB_RELEASE%.*} $DISTRIB_ARCH)
    EOF
    for feed in passwall_luci passwall_packages passwall2; do
      echo "https://master.dl.sourceforge.net/project/openwrt-passwall-build/releases/packages-$release/$arch/$feed/packages.adb" >> /etc/apk/repositories.d/customfeeds.list
    done

The opkg path mirrors the apk path with a different key format

For opkg systems the structure is identical but the mechanics differ. The key is downloaded as ipk.pub into the current directory and added with the opkg-key tool, rather than being written straight into the apk keys directory. The repository entries are written to a customfeeds.conf file using the src/gz form, one line per feed, and the release and architecture are derived from the same release file with the same parameter expansion. Once the feed is registered, the install is a two-line operation. The shape of the two paths is close enough that moving between OpenWrt versions is mostly a matter of switching to the right snippet, but the key handling is not shared and you should not assume a key added for one package manager is meaningful to the other.

    read release arch << EOF
    $(. /etc/openwrt_release ; echo ${DISTRIB_RELEASE%.*} $DISTRIB_ARCH)
    EOF
    for feed in passwall_luci passwall_packages passwall2; do
      echo "src/gz $feed https://master.dl.sourceforge.net/project/openwrt-passwall-build/releases/packages-$release/$arch/$feed" >> /etc/opkg/customfeeds.conf
    done

Installing the package and the manual fallback

After the feed is registered the install is deliberately boring: refresh the package index, then add the package by name. There is also a manual route for people who do not want to add a repository at all. You download a prebuilt package file from the project page on SourceForge, upload it to the router, and install it with whichever package manager your firmware uses, pointing at the local file path. The glob patterns in the commands are there to catch the version suffix in the filename. This path suits a router with no outbound access to the package feed, and it is also the one to prefer if you want a specific version pinned rather than whatever the feed currently serves.

    apk update
    apk add luci-app-passwall

The manual route uses the same package manager against a local file:

  opkg install luci-app-passwall*.ipk

What the repository actually contains and where the upstream boundary sits

The top level tree is small, and that is the point. Alongside the workflow configuration, the gitignore and the documentation, there are four functional files: an apk public key, an ipk public key, a cur_ver.json file and an nvchecker.toml file. The key files hold the signing keys for the two package ecosystems, stored in the repository so that you can fetch them over HTTPS rather than having to obtain them out of band. The version-related files sit alongside a workflow badge for scanning the Openwrt-Passwall version, which is how a distribution of someone else's project keeps track of which upstream release it is packaging. The build workflow badge and the version scan badge in the documentation point at a differently named repository, which suggests the workflows were inherited from the original build project and later adapted. No compiled binaries are stored in the repository itself; the artefacts are served from SourceForge.

Where this distribution is the wrong answer

Two cases stand out. The first is a router whose architecture is not in the feed tree, or a firmware that is neither an apk release nor an opkg release in the versions described. The feed paths are derived from the release name and the architecture, so if your combination is missing you get a 404 in the feed rather than a friendly error, and the manual route then depends on someone having published a package for your target. The second case is customisation. If you want to change how Passwall itself behaves, or bundle it with other packages in a single firmware image, this repository is the wrong level of abstraction: it distributes binaries, and the documented workflow is entirely about adding a feed and installing a package. Building from the SDK yourself is the route for that, and this project does not document it.

Maintenance state, releases and the licence question

The repository is not archived, and the last push was on 2026-10-19, so the feeds and keys are being kept current. There are no GitHub releases, which is consistent with the design: the artefacts are versioned inside the package feeds and on the SourceForge file area, not as tags in the repository. The licence is MIT, and that covers this repository's own files, which are essentially the keys, the workflow configuration and the documentation. The upstream project whose binaries these are carries its own terms, and the acknowledgement in the documentation points out that this project is heavily inspired by kuoruan/openwrt-v2ray. A practical consequence for anyone running this on infrastructure: you are installing third-party binaries onto a device that typically holds your routing and DNS configuration, and signing keys plus an MIT licence on the packaging repository say nothing about the provenance of the packages themselves.

Editorial conclusion

Adopt openwrt-passwall-build if you run Passwall on OpenWrt and would rather add a signed package feed than compile the SDK image yourself. Do not treat it as a Passwall fork: the routing logic, the LuCI interface and the node configuration all come from the upstream Openwrt-Passwall project, and this repository only carries build artefacts. Before you install, check that your firmware version matches the package manager path, that your architecture appears in the feed directory you point at, and that the key you add is the one served from the same SourceForge project the packages come from, since the repository ships both an apk key and an ipk key at its root.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. moetayuko/openwrt-passwall-build on GitHub
4. README