About this open-source self-hosted directory

The open-source self-hosted directory exists because self-hosting discovery has two useful traditions that rarely meet. One tradition is the awesome list: broad, community-maintained, easy to contribute to, and excellent for experienced operators who already know the category names. The other tradition is the app store: polished, searchable, tied to a runtime, and comfortable for beginners. This project tries to keep the openness of the first tradition while adding the editorial context of the second.

Methodology

Each app entry is authored in this repository rather than bulk-imported from a share-alike dataset. That keeps the v1 metadata license straightforward and forces every listing to pass a small editorial test: the app needs a homepage, source or source-adjacent reference, documentation, a license label, a category, a stack, deployment signals, and at least one credible hosted alternative. The goal is not to list everything; it is to make each listed item explainable.

What the guides are for

The category guides are written for readers who are deciding, not just browsing. A useful guide should say when the category is worth self-hosting, which two to five apps deserve the first comparison, what can go wrong operationally, and how to choose. That is why the site has separate pages for photos, passwords, files, media, RSS, and other workflows. The same software can be impressive in one context and inappropriate in another.

How this compares

Awesome-selfhosted remains the broad reference point, and selfh.st/apps is the closest UX competitor. Runtime-specific catalogs such as Umbrel, CasaOS, Runtipi, Cloudron, Cosmos, and Unraid Community Apps help people install software, but they answer a narrower question: what runs in this platform? OpenAlternative and LibHunt help with alternative discovery, but they are not organized around deployment responsibility. This open-source self-hosted directory is designed to sit between those surfaces.

What is included

The v1 seed favors practical categories that map to common hosted products: Google Photos, 1Password, Dropbox, Notion, Feedly, Raindrop, GitHub, SmartThings, NextDNS, Start.me, Pocket, Plex, and related tools. An app does not need to be perfect to be listed, but the page should name its tradeoff. Proprietary self-hostable tools may appear when readers genuinely compare them, but they should not be confused with free software.

What is not included

The directory does not provide hosted accounts, installation support, security audits, sponsorship rankings, or one-click deployment promises. It also does not claim that self-hosting always saves money. Running software means accepting maintenance, backups, updates, monitoring, and occasional breakage. The site should help readers avoid bad surprises, not romanticize servers.

Quality bar

The content bar is deliberately higher than a generated directory page. Long-form pages must be unique, readable, and specific to the workflow. App descriptions should explain what the app does and one honest limitation. Programmatic pages can be shorter, but they should still be useful by grouping real metadata. Automated linting checks word count, keyword use, duplicate paragraphs, repeated H1s, and cross-category phrase reuse.

Future direction

The next version can add comparison pages, more locales, app submission workflows, RSS updates, generated Open Graph images, and upstream sync tooling. Those features should not arrive before the editorial model works. A durable open-source self-hosted directory has to earn trust page by page, with content that respects both SEO and the reader’s time.

Editorial boundaries

The site should not pretend that a directory listing is a security audit. It should not imply that a one-click installer removes operational responsibility. It should not rank sponsored products above better choices. It should not hide proprietary licensing when a project is still useful to compare. Those boundaries matter because people use self-hosted directories to make decisions about private data, family workflows, and small-team infrastructure.

Review process

New content should answer four questions before it ships. What job does this software perform? What data does it hold? What does the operator have to maintain? What would make a reader choose something else? If a page cannot answer those questions, it is probably a stub. The same rule applies to app descriptions, category guides, and programmatic surfaces. Thin pages are easier to publish, but they do not help readers choose.

Open-source reuse

Forkability is part of the product. A local community, consultancy, school, or hobby group should be able to clone the repository, replace the seed metadata, change the domain, and publish a narrower directory. That means the code should stay boring, the content model should stay strict, and the deployment runbook should avoid secrets or local vendor login state. The open-source self-hosted directory is also a starter for other directories.

What success looks like

The project succeeds if a reader can arrive from a search query, understand the category, pick two or three serious apps, and know what to test before deployment. It also succeeds if maintainers can add a listing without guessing the schema. Traffic alone is not the goal. Useful discovery, honest tradeoffs, and maintainable pages are the goal.

Governance assumptions

The current repository assumes a small maintainer group. That means every new category should be reviewed for duplication, tone, and operational accuracy before it ships. A future submission workflow can collect suggestions, but it should not publish them automatically. Directories decay when every project becomes a listing and no one is responsible for saying no.

Content maintenance

Self-hosted software changes quickly. A page that was accurate during one release cycle can become misleading after a license change, a rewrite, a funding shift, or a security incident. The updated date in frontmatter should mean someone read the page, checked the links, and confirmed that the recommendation still makes sense. The open-source self-hosted directory should prefer fewer fresh pages over many stale ones.

Reader safety

Some categories carry more risk than others. Password managers, network tools, file sync, and home automation can affect security or daily household function. The about page names that risk because enthusiasm should not override caution. A good directory should make self-hosting more approachable while still reminding readers that private infrastructure is a responsibility.

Why the project is open

An open repository lets readers inspect the schema, fix errors, challenge recommendations, and fork the site for a different audience. That openness is also a constraint on quality: vague claims can be reviewed, app metadata can be corrected, and deployment instructions can be tested. The site should be useful even to someone who never deploys it, but the ability to deploy it keeps the promise concrete.

How corrections should work

Corrections should be specific. A useful correction names the app, the field, the current claim, the better source, and the date checked. That discipline keeps the open-source self-hosted directory from drifting into rumor. It also makes reviews faster because maintainers can confirm a concrete link or release note instead of debating broad preferences.

Why the first version is conservative

The first version avoids accounts, ads, voting, submissions, and newsletter capture. Those features may be useful later, but they would distract from the editorial proof. The immediate question is whether the open-source self-hosted directory can publish trustworthy pages that help readers choose and help maintainers keep the catalogue accurate.

Related terms

This about page also covers self-hosted software and directory methodology. The phrasing matters because many people discover the project while searching for ownership, alternatives, or practical self-hosted software rather than a brand name.