The Problem

Many users who self‑host services need a quick reference of available open‑source apps and a way to discover them by tag. Maintaining such a list manually in a static site can become cumbersome as the number of entries grows.

What This Does

The repository delivers a single‑page static web site that lists roughly 80 self‑hosted applications. The core assets are:

  • index.html – the main landing page rendered in the browser.
  • p/index.html – a secondary page (presumably a detail or tag‑search view).
  • styles.css – provides the visual styling for both HTML pages.
  • script.js – contains all client‑side logic, including the “tag search” feature mentioned in the README.
  • Image assets in files/ are used for the logo and a preview screenshot.

The README (README.md) explains the project purpose and points users to the live site (https://selfhostlist.org/). No server‑side code, build scripts, or package manifests are present.

How It Is Wired

  1. Browser loads index.html – The HTML file includes <link rel="stylesheet" href="styles.css"> and <script src="script.js" defer></script>.
  2. styles.css – Applies layout, colors, and responsive rules; it does not import any other resources.
  3. script.js – Executes once the DOM is ready. The file defines a set of functions (e.g., filterByTag(), renderAppList()) that read a hard‑coded JavaScript array of app objects, apply the selected tag filter, and update the DOM. No external modules are imported, and the import graph shows a single internal module with zero import edges.
  4. User interaction – Clicking a tag triggers filterByTag(), which iterates over the in‑memory list and re‑renders matching items. All operations stay in memory; there is no network request, database access, or file I/O beyond the initial static assets.
  5. Secondary page p/index.html – Mirrors the same wiring pattern (its own <link> and <script> tags) and likely serves a scoped view, but the static analysis does not expose additional JavaScript files.

Because the codebase consists of a single JavaScript module with no dependencies, the blast radius of a change is limited to that file. No circular imports or shared state exist.

How To Use It

  1. Clone the repository
   git clone https://github.com/moses-y/SelfHostList
   cd SelfHostList
  1. Open the site – Launch either index.html or p/index.html in a web browser. No build step, package manager, or environment variables are required.
   # Example on macOS
   open index.html

On other platforms, open the file with the preferred browser.

Real‑World Use

A small internal wiki could embed https://selfhostlist.org/ (or a self‑hosted copy) to give engineers a searchable catalog of approved self‑hosted services. When a new service is adopted, a developer adds an entry to the JavaScript array in script.js and redeploys the static files to the corporate web server.

Code Health & Issues

  • Medium – No tests – repository-wide; there are no test files.
  • Medium – No CI/CD pipeline – no .github/ workflows, Travis, CircleCI, etc.
  • Medium – No LICENSE file – usage and redistribution terms are undefined.
  • Medium – No Dockerfile or lockfile – the project cannot be reproducibly containerised or dependency‑locked (though it has none).

The static analysis confirms a single internal JavaScript module with zero import edges and no circular dependencies.

The Bottom Line

SelfHostList is a minimal, static HTML/JS site that fulfills a narrow niche: presenting a searchable list of self‑hosted apps. Its simplicity makes it easy to deploy, but the lack of tests, CI, and licensing limits confidence for production use or for contributors who need clear contribution guidelines. It is suitable for personal or low‑risk internal documentation, but organizations that require maintainable, auditable code should consider adding tests, a CI pipeline, and an explicit license before adopting it.