A directory with an editorial process
FMHY Edit is the working repository behind FMHY, a large community wiki for free online resources. Its Markdown pages cover software, streaming, games, learning, privacy, mobile tools, and other categories. The website adds search and navigation around that material. The repository also contains the VitePress theme, a Nitro API, scripts that produce a single-page edition, and publishing workflows. Readers use the finished directory; contributors use this repository to change it.
That division matters because FMHY does not host the files found through its links. The README says this plainly and points to backups plus a JSON API. A listing is an editorial recommendation or index entry, not a copy of the underlying software or media. Anyone using the directory still crosses into third-party services with their own ownership, policies, and risks.
The catalog is opinionated. Starred entries are community recommendations, third-party indexes get a separate marker, and section links help readers move through long pages. The contribution guide says sections are generally ordered from best to worst. This is more useful than an alphabetical link dump, though it also means acceptance depends on the maintainers' criteria and testing process.
Contributing is easy until the change gets large
A small correction can happen entirely in GitHub's editor. The guide walks through editing a file, proposing the commit, and opening a pull request. Contributors can also fork the repository and use github.dev. That route suits broken URLs, wording fixes, and narrowly scoped additions without requiring the website to run locally.
New listings face more scrutiny. Contributors must search the generated single-page index for duplicates, avoid batches of untested links, and explain removal or recommendation changes. Every addition goes through testing on Discord. Bigger restructures and page-wide cleanup must be discussed there before a pull request is opened, and the guide notes that the server opens every Friday. This gives the directory a human filter, but it is a poor fit for someone expecting asynchronous pull requests to be the whole process.
The rejection rules are unusually specific. Paid and trial-only entries are generally excluded, as are coding libraries, Linux distributions, mining or betting sites, and multiplayer cheats. Non-English software sites face a reputation threshold. These choices keep the directory within its chosen scope. They also give competent contributors a quick reason to walk away when their proposed category does not belong.
What happened when we ran it
We cloned commit f23fd6e into a fresh Debian container with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and an unprivileged user. The checkout contained 352 files, about 45,399 lines of source, and occupied 13.4 MB. Installation failed with exit code 1 after 18 seconds. Because installation did not finish, we did not reach a build or test command.
The pnpm log was direct about the immediate failure: neverBuiltDependencies and onlyBuiltDependencies could not both be configured. It repeated that error and warned that dangerouslyAllowAllBuilds was true, allowing dependencies named in neverBuiltDependencies to run scripts. The log does not establish where the conflicting values came from, so we cannot responsibly assign a cause beyond the configuration conflict it reported.
The repository does show investment in delivery machinery. It has three CI workflow files, a Dockerfile, and a workspace configuration. There is no tests directory. Those signals do not change the result of our run: the documented pnpm i path was not usable in this clean environment at the measured commit.
The application is more than Markdown
Local development requires Node ^22.13.0 || >=24 and pnpm. The main scripts run the docs site, build the API, generate removed-link and single-page outputs, lint code, and format contributions. The docs frontend uses VitePress and Vue, with local search provided by MiniSearch. The API uses Nitro routes for feedback and single-page output, then deploys through Wrangler.
A multi-stage Dockerfile builds the docs and serves the static output from Nginx. Compose maps that container to port 4173. This is a reasonable production shape for the publication side, but it does not remove the package installation step that failed in our sandbox. There is also no root technical guide explaining the configuration conflict or a known workaround.
Licensing needs a closer read than the repository card suggests. GitHub returns no detected license for the repository. The API README says that component uses Apache 2.0 and points to a license file inside the docs configuration. A company planning to reuse the theme, generated content, or whole stack should establish which terms apply to each part before copying it.
Health is visible in the edit queue
The repository was pushed on August 25, 2026, the same day as this review. Issues and pull requests were also being opened and updated that day, including link proposals, documentation fixes, and a dependency security update merged on August 24. GitHub's open count was 16 and combines issues with pull requests. This is active maintenance, not a queue that has been sitting untouched.
There is no latest GitHub release to evaluate. For a continuously published wiki, the commit and moderation flow tells us more than a release tag would. It does mean downstream users lack a named release point, changelog, and packaged artifact for deploying a known edition. Pinning a commit is the practical option.
FMHY is worth bookmarking if its category choices match what you seek. Its value comes from ongoing selection and correction, while its weak spot is reproducible local setup at the commit we tested. Use the web directory for discovery, contribute focused evidence through the established channels, and do not mistake a starred link for a substitute for checking the destination yourself.