# RunFilesBuilder: daily self-extracting installers for OpenWrt packages > RunFilesBuilder is a workflow that fetches the newest compiled ipk packages from other people's OpenWrt projects and repackages them as self-extracting run archives for iStoreOS and ImmortalWrt, using makeself. The result is a single file that a router user can install with one command, and a trust question that goes with it. **wukongdaily/RunFilesBuilder** — 这是一个工作流。同步各位大佬项目里最新编译的ipk文件 生成适用于iStoreOS/ImmortalWrt用的run自解压包 - Repository: https://github.com/wukongdaily/RunFilesBuilder - Website: https://tvhelper.cpolar.cn - Stars: 1,139 · Forks: 1,418 - Language: Shell - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/wukongdaily-runfilesbuilder ## A packaging workflow rather than a piece of software RunFilesBuilder is best understood as a workflow with one job: it synchronises the newest compiled ipk files from other people's projects and turns them into self-extracting run packages that suit iStoreOS and ImmortalWrt. The repository description says so directly, and the README repeats it. The mechanism underneath is makeself. The README states the essence: it uses makeself to pack the ipk and shell files into a self-extracting program. That is the whole technical approach, and it is why the project is written in shell rather than in a compiled language. The repository layout supports that reading. The root holds a `shell/` directory with the scripts, a set of Markdown files at the top level, `common.md`, `info.md`, `info1.md` and `momo.md`, and an `info/` directory, plus the `README.md` and an English version, `README_en.md`. The Markdown files are per-package documentation, and the `info/` directory holds the extra descriptive content that ends up inside the generated packages. The output is a file with a `.run` extension, and the README shows two ways to install one. The iStore route installs from the iStore app store manually on iStoreOS. On ImmortalWrt or other OpenWrt builds, you download it and run it with the shell: ```bash wget -O xxx.run sh xxx.run ``` The daily build is published separately, and the README points at a releases page for the built artefacts, with a discussions thread for the build. The project is MIT licensed, and the last push was on 2026-04-10, with no GitHub releases of its own. ## The extract-only flag is the honest way to look inside One line in the README deserves more attention than the rest of the install section: ```bash sh xxx.run --target dir --noexec ``` That extracts the archive into the `dir` directory without executing the installation. It is the makeself interface, and it is the reason the tool is usable at all by someone who wants to see what they are about to install. The distinction matters more here than for an ordinary self-extracting archive. A run file contains an ipk package and a shell script that performs the installation on the router, and the ipk inside it was built by somebody else and downloaded from a release page. Being able to unpack it and look at the contents before running it is the only inspection step the documentation offers. It is also worth being clear about what the flag does not give you. Extracting the archive shows you the ipk and the shell scripts, not the contents of the binaries inside the ipk. Verifying that the binary is the one the upstream project published would require comparing checksums against the upstream release, and nothing in the visible documentation describes that being done. So the practical sequence for a cautious user is to extract first, look at the scripts, and check the ipk against the upstream project's own release if the origin matters to you. ## The package set, and who actually built the binaries The badges at the top of the README are the inventory. There are fourteen of them, and the list is the clearest statement of the project's scope: Passwall, Passwall2, OpenClash, SSRP, nikki, momo, MOSDNS, homeproxy, dae, AdGuardHome, the iStore store, the ARGON theme, the DUFS file server and OpenList2. The credits section at the bottom names where each one comes from, and it is worth reading in full because the distinction between packaged and referenced is exactly the interesting part of this project. The entry for the packaging is makeself, from megastep. Everything else is marked as referenced, and the references are the upstream projects: AdGuardHome from the AdguardTeam releases page, the OpenWrt package feeds at dl.openwrt.ai and downloads.immortalwrt.org, OpenWrt-nikki and OpenWrt-momo from nikkinikki-org, luci-app-mosdns and luci-app-openlist2 from sbwml, openwrt-passwall and openwrt-passwall2 from Openwrt-Passwall, and OpenClash from vernesong. So the run files this project produces are not software it wrote. They are repackaged upstream releases, fetched at build time and wrapped in an installer. That is also what makes the daily build worth having. The upstream projects publish new ipk files as they release them, and someone has to notice, download the right architecture's package, and produce something a router user can install without a package manager workflow. The badges show the result: a single place where the current build of each of these is available as one file. ## Getting the iStore layer onto a non-iStore router iStoreOS ships with the iStore app store, so on that platform installing from the store is the ordinary path and the README shows it as a screenshot rather than a command. For ImmortalWrt or other OpenWrt builds there is no iStore by default, and the README gives a single command to add it: ```bash wget -qO imm.sh https://cafe.cpolar.top/wkdaily/zero3/raw/branch/main/zero3/imm.sh && chmod +x imm.sh && ./imm.sh ``` The script is fetched over HTTPS from a cpolar-hosted URL, made executable and run. That is a remote script installation, and it is a separate trust decision from the one you make about the run files themselves, because this one is about a script that has just been downloaded and executed, with no checksum in the command. The README also links two pieces of documentation: a YouTube walkthrough of the operating steps, and an article on the principles, at a second cpolar-hosted site. Both are behind the same hosting arrangement, which is worth knowing if you are evaluating how much of the chain you can verify. The project homepage recorded in the repository metadata points at a third cpolar address, so the documentation, the helper script and the site are all served from the same tunnel. That is a common arrangement for a project run by one person, and it is a fact about the deployment rather than a criticism of the packaging work. ## Where this workflow is the wrong tool The first wrong case is a router where package provenance matters. The daily build fetches binaries from upstream release pages and wraps them, and the documentation describes no signature verification, no checksum pinning and no way to pin a specific build of a specific upstream release. A device that has to be auditable, or a network where the router's firmware is a matter of policy, needs packages from the upstream feed with the upstream's own verification, not a repackaged copy. The second is a network where the traffic has to be inspected. The scripts are fetched over a public tunnel and the documentation is hosted the same way, so a deployment in an environment with an egress proxy or a strict allowlist has to permit those hosts, and if it does not, the convenience disappears. The third is a fleet. A daily build means the artefact under your router changes without a version number changing, and there is no way to tell two routers apart except by comparing the files. For a handful of home routers that is fine, and for anything managed it is not. The fourth is a platform that is not OpenWrt. The output is an ipk plus a shell installer, so the audience is iStoreOS, ImmortalWrt and OpenWrt-derived systems. The README does not describe a build for other targets, and the ipk format is specific to that ecosystem. The last is a workflow you need to run yourself. What is published here is the build output and the shell directory, and the daily build is driven by a workflow whose configuration is not described in the visible README, so a fork that wants to change the package set, the naming or the version pins is starting from the scripts rather than from documentation. ## Conclusion Adopt RunFilesBuilder if you run iStoreOS or ImmortalWrt on consumer routers and want current builds of these packages without tracking several upstream release pages, and if you are comfortable with a daily build that fetches binaries from third parties. Do not adopt it for a router where you need a pinned, verifiable package version, because the daily build model is the opposite of reproducible, and do not treat the run archive as a security boundary, since it installs upstream binaries without a signature check described anywhere in the documentation. Before you install, check the upstream project list in the README so you know whose binaries you are taking, and use the extract-only form to inspect the contents first. ## FAQ ### What does RunFilesBuilder actually produce? It is a workflow that syncs the newest compiled ipk files from other people's projects and packs them with shell files into self-extracting run archives for iStoreOS and OpenWrt, using the makeself tool. ### How do I install a run file on ImmortalWrt? Download it and run it with the shell, for example `wget -O xxx.run ` followed by `sh xxx.run`. On iStoreOS the README shows installing from the iStore app store instead. ### Can I extract a run file without installing it? Yes. The README gives `sh xxx.run --target dir --noexec`, which extracts the archive into the dir directory without executing the installation. ### Where do the packaged ipk files come from? From upstream projects, which the README lists as referenced: AdGuardHome, OpenWrt-nikki, OpenWrt-momo, luci-app-mosdns, luci-app-openlist2, openwrt-passwall, openwrt-passwall2 and OpenClash, along with the OpenWrt and ImmortalWrt download feeds. The packaging itself is done with makeself. ## Sources - [Issues](https://github.com/wukongdaily/RunFilesBuilder/issues) - [License: MIT](https://github.com/wukongdaily/RunFilesBuilder/blob/master/LICENSE) - [Project website](https://tvhelper.cpolar.cn) - [README](https://github.com/wukongdaily/RunFilesBuilder/blob/master/README.md) - [wukongdaily/RunFilesBuilder on GitHub](https://github.com/wukongdaily/RunFilesBuilder) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wukongdaily-runfilesbuilder