SubBoost's own manifest answers the questions its README leaves open

Two Node ranges and a root manifest marked private

The root package.json is where this project's real constraints live, and the first thing it says is `"private": true`. The package is not published to a registry, so there is no `npm install subboost` anywhere in the project's story. Installation arrives one of three ways: the hosted entry at subboost.org, an image pull for the one-click deployment path, or a source build for the advanced path.

The second thing it says is the engine range:

  "engines": {
    "node": ">=22.13.0 <23 || >=24.0.0"
  },

That range is written as two clauses, not one. Anything below 22.13.0 is out, the rest of the 22 line from 22.13.0 up is in, the entire 23 line is out, and the 24 line and later are in. Somebody typed a second clause specifically to say 23 is excluded, which means the omission is a decision rather than an oversight.

The private flag sits in an interesting spot next to the license section. The README asks anyone who modifies SubBoost and then serves it over a network to hand over the corresponding source, and it names SubBoost/subboost as the public source entry. A private root manifest is consistent with that, since the code ships as an application rather than a library, but it also means the only way to pick this code up is a clone or an image. The dependency list at the root, which mixes Postgres drivers, ten Radix UI packages, bcryptjs, and four `file:` references to internal workspaces, is a working manifest for that arrangement.

Almost every root script is a pass-through into the local workspace

The manifest declares two workspace globs, `"packages/*"` and `"local"`, then hands off nearly all the real work to the second one.

  "scripts": {
    "dev": "npm --workspace @subboost/local run dev",
    "build": "npm --workspace @subboost/local run build",
    "test:unit": "vitest run",
    "test:coverage": "vitest run --config vitest.coverage.ts --coverage",
    "test:core": "vitest run --config vitest.core.config.ts",
    "lint": "eslint local packages --max-warnings=0 && npm run check:ui-consistency",
    "check:ui-consistency": "node scripts/check-ui-consistency.cjs packages local",
    "check:local-app": "npm --prefix local run check",
    "local:db:generate": "npm --prefix local run db:generate",
    "local:lint": "npm --prefix local run lint",
    "local:typecheck": "npm --prefix local run typecheck",
    "local:build": "npm --prefix local run build"
  },

Two idioms reach the same workspace within seven lines of each other. `dev` and `build` go through the package name with `--workspace @subboost/local`. The `local:*` block goes through the directory with `--prefix local`. `check:local-app` is the `local:lint` idea with the subcommand swapped to check. A contributor reading the root manifest sees fifteen scripts and has to work out which three of them are the ones the README actually tells people to run.

`lint` is the odd one out, because it is two commands joined by `&&` rather than one. `eslint local packages --max-warnings=0` treats any warning as a failure, and only when that passes does `check:ui-consistency` run, walking both directories with a project script of its own. A checkout with no lint errors at all still fails lint if the consistency checker objects to something, which is a distinction the README does not draw.

Three vitest configs and a common-checks list that names one

Three vitest config files sit at the root: `vitest.config.ts`, `vitest.core.config.ts`, and `vitest.coverage.ts`. Each one has a matching script, `test:unit`, `test:core`, and `test:coverage`. The unit run passes no flag at all, so it picks up the default config by convention, while the other two name their config explicitly.

The README's common-checks block is short:

npm run lint
npm run test:unit
npm run check:local-app

Two of the three test entry points never appear in that list, and the config files are not named anywhere in the README either. A contributor who follows it runs the default suite with no way to learn that `test:core` and `test:coverage` exist. Nothing here is broken, but the published check list is narrower than the manifest, and a narrowing of that sort is exactly what makes a new contributor assume a test surface does not exist.

The three listed commands are not peers. `lint` is the two-stage chain described above. `test:unit` is one vitest invocation. `check:local-app` reaches into the workspace with `--prefix` and runs a script the root manifest never defines, so its contents live in `local/package.json`, one level below anything a reader of the root file can see. Same for `local:db:generate`, which is where the Prisma schema step has to be run from.

A .dockerignore at the root with no Dockerfile beside it

The top level of the repository holds `.dockerignore` and nothing that would build a container. There is no Dockerfile among the entries, which otherwise include `docs/`, `local/`, `packages/`, `scripts/`, `test/`, `eslint.config.mjs`, and the three vitest configs. A `.dockerignore` on its own describes a build that the root listing does not show.

That matters because the deployment options are split by cost and the cheaper one is the container path. The one-click page is described as pulling an image to build, faster with lower requirements. The advanced page is described as compiling from source, slower with higher requirements. Both descriptions live in `docs/`, whose contents the root listing does not enumerate, so a reader choosing between them from the repository itself has to take the first one's word that a build recipe exists somewhere in the project.

The same split reappears in the workspace layout. The application sits under `local/`, four internal packages are wired with `file:` references, and the root manifest is marked private, so nothing visible at the root says where an image gets assembled. The README also opens its interface section with an empty paragraph element and no image, and its star-history block is a pair of theme variants with no image tag of its own, so the two places meant to show the product are the two places with nothing in them.

DNS leak prevention is credited to a default nobody can read

The highlights credit leak prevention to a default, described as a basic and DNS configuration that helps prevent DNS leaks. That is the entire claim: a named default, the word helps, and no measurement. Nothing in the repository listing shows what the default contains. There is no sample YAML at the top level, no config directory, and no resolver address anywhere in the manifest.

This is worth separating from the rest of the feature list, because the rest of it is countable. Precise routing is described as more than 30 common proxy groups and over 2,000 remote rule sets. Automatic refresh runs on a schedule and matches nodes intelligently during the refresh. Node filtering builds filtered proxy groups out of selected nodes by source, region, and custom rules. Those are claims a reader can go and count.

DNS is different in kind. A subscription tool sits exactly where a leak can happen: it fetches a remote list, merges it, and hands the result to a client that does the resolving. Whatever default ships with the tool is the only thing between that merged list and the resolver the client would otherwise use, and the repository does not print it anywhere a reader can inspect it.

npm ci
npm run dev

Those two lines are the whole development setup. A local environment gets you the application to click through, which is a reasonable way to find out what the default actually resolves to before trusting it with a subscription of your own.

The configuration guide is hosted on someone else's forum

The usage section mixes four links with four different provenances. The hosted entry and the two deployment pages are the project's own, on subboost.org and docs.subboost.org. The fourth is not. The configuration guide points at ryanvan.com, carries a query parameter reading `u=ryan`, and is described with a joke about how simple the Clash configuration is. It sits in the same bullet list as the deployment docs, in the same voice, with nothing marking it as third-party.

The links section splits the project's own history in two as well. Release announcements live inside the repository, at `docs/release-notes.md`. The changelog lives on the web host, at `https://subboost.org/faq`, the same domain as the public service entry. So the record of what changed is kept in two places with different owners: one you can read in a pull request, one you can only fetch over HTTP.

Community feedback points at two forums, LINUX DO and IDC Flare, and neither is an issue tracker. Four open issues sit on the repository against 908 stars and 162 forks, which is a small number for a project this size, though an issue count of that shape reflects where a community gathers as much as how much work is open. The English README also ships beside a Chinese one, and the Chinese file is the only other prose document at the root.

A public service entry next to a disclaimer denying one

The first usage option reads: no deployment required, direct access to the public service, at subboost.org. It is the shortest path in the document and the only one that asks nothing of the reader but a browser.

The last section of the README says the opposite kind of thing. The project does not provide any proxy service, and it makes no guarantee about the availability or legality of third-party subscription content. Both sentences are about the code, and both are necessary, because the job of the tool is to import whatever subscription a user points it at and republish the merged result.

Read together, the two statements describe two products sharing one name and one domain. One is the open source converter, licensed AGPL-3.0-only, that people deploy themselves. The other is a hosted service doing the same work for people who would rather not deploy anything. The README does not draw a line between them, and the domain hosting the second is also where the changelog lives, so the boundary between project and service has to be inferred from context.

The release history adds a third uneven edge. `v2.8.0` and `v2.8.1` were both published on 2026-08-24, about two hours apart, while a rolling `dev` tag carries a June date, and the last push to the default branch came on 2026-10-01, after both tags.

Group names in code style with nothing defining them

Two terms in the highlights are written in code style, which usually means they are identifiers from somewhere in the system: `filtered proxy groups` and `relay proxy groups`. Neither is defined. A filtered proxy group is described as holding only the nodes you selected, by source, region, and custom rules. A relay proxy group is the output of the chained proxy feature, where one node's traffic leaves through another. Both descriptions are prose; neither name appears in the manifest, and no config file at the top level would show either one as a key.

The 2,000 remote rule sets sit in the same list and are the vaguest number in the document, since not one of them is named. A rule count with no examples tells you the size of a menu and nothing about what is in it. The rule management entry says only that rules can be reordered for deeper customization. Reordering relative to which provider's ordering, and with what behaviour when two sources disagree about the same domain, are questions the repository leaves open.

The rest of the surface is smaller and more concrete: rename, delete, or set listening ports for nodes in batches, and import subscription links, YAML files, node links, and other common formats. Node management is what a user reaches for in the first ten minutes with the tool, and it is also the part with the least written down.

Editorial conclusion

SubBoost is a working conversion layer with an unusually honest README and an unusually thin one at the same time. Everything about the deployment tradeoffs, the license obligations, and the disclaimer is stated plainly; almost nothing about the configuration it produces is. Before adopting it, read the root package.json rather than the highlights: the Node range excludes the 23 line, the root package is private, and the checks the README lists are a subset of the ones in the manifest. Anyone running their own instance also has to supply a Postgres server, since the data layer is @prisma/adapter-pg rather than an embedded store, and the cheapest path in the README hides that cost by pointing at the hosted entry. Decide first whether you want the tool or the service.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. SubBoost/subboost on GitHub