Own the software
running your life.

Why this self-hosted software directory exists

The self-hosted software directory is built for readers who know they want more control but do not want another giant spreadsheet of projects. Existing lists are valuable, yet a newcomer still has to decide which category fits the problem, which license creates obligations, which stack they can maintain, and which app is a realistic replacement for a hosted product. This site turns those questions into crawlable pages and plain-language guides.

What counts as self-hosted

Self-hosted software should let an operator run the core service on infrastructure they control. That can mean a small server at home, a virtual machine, a NAS, or a managed container host. It does not require every client app to be open source, and it does not mean every product is free of commercial features. The directory labels licenses, source availability, deployment targets, and hosted alternatives so readers can see the shape of control before they install anything.

How the directory is organized

The self-hosted software directory starts with workflows instead of brands. Media servers, photos, passwords, files, notes, RSS, bookmarks, code hosting, home automation, network utilities, dashboards, and read-it-later tools each get a guide. App pages then connect those workflows to license pages, stack pages, and alternative-to pages. That structure helps people search for open-source self-hosted apps from multiple directions: a category, a language, a license, or a SaaS product they already use.

How to choose responsibly

The best self-host alternative to SaaS is rarely the app with the most screenshots. A better shortlist starts with data export, backup restore, authentication, mobile access, update cadence, and community health. For some categories, such as password managers and file sync, restore testing is mandatory before real use. For lower-risk categories, such as RSS and dashboards, a small weekend deployment can teach enough to decide whether the workflow is worth keeping.

Deployment targets

Docker is the common baseline because most projects document it and most home-server platforms can run it. Umbrel, CasaOS, Runtipi, Cloudron, Unraid, and Cosmos can make discovery and installation easier, but the directory stays neutral. A catalog entry inside an appliance store is useful evidence; it is not the same as a product comparison. The operator still owns backups, secrets, storage, updates, and domain exposure.

Editorial approach

Every guide in this self-hosted software directory should explain why a category matters, name the realistic options, describe deployment cost, and close with a choice rule. The site avoids ranking by star count alone because popularity does not equal maintainability. It also avoids importing share-alike datasets into v1 so the original app metadata can remain simple to license and easy to fork.

Search and reuse

The site is open source so another team can fork it for a narrower niche, such as education, media labs, local government, or privacy-focused households. The current v1 seed is intentionally compact. The point is to prove that a self-hosted software directory can combine open-source self-hosted apps, editorial category guides, schema markup, and simple deployment without turning the reader into a crawler operator.

What readers can do first

Start with a low-risk category. RSS, dashboards, bookmarks, and read-it-later apps are good first deployments because the data is easy to export and the household impact is low. Passwords, files, photos, and home automation deserve more planning because a bad restore or misconfigured account can affect other people. The directory tries to make that difference visible before the reader copies a compose file.

How category guides should be read

Every category guide is opinionated, but it is not a final verdict. The guide gives a shortlist and a way to think. The reader still needs to check upstream documentation, project activity, hardware needs, and current release notes. If an app has a great feature list but unclear backups, it should not be the first choice for irreplaceable data. If a smaller app has clean exports and clear logs, it may be the better operational fit.

Why alternatives are included

People rarely search from a license name first. They search for a Google Photos replacement, a 1Password alternative, a GitHub alternative, or a private Pocket replacement. Alternative pages connect that familiar language to open-source self-hosted apps without claiming that every feature maps perfectly. The comparison is about the job a product does, not about copying a cloud product detail by detail.

Why license and stack pages exist

License pages help readers understand redistribution, contribution, and commercial-use implications. Stack pages help operators match projects with skills they already have. A Python household may be comfortable debugging Home Assistant, while a Go-heavy team may prefer Miniflux, Forgejo, or Syncthing. The self-hosted software directory keeps those surfaces crawlable because search engines and human operators both benefit from direct paths.

What the site does not automate

The directory does not know the reader’s network, budget, hardware, tolerance for downtime, or family support burden. It cannot tell whether a NAS has reliable disks or whether a reverse proxy is configured safely. That is why the guides emphasize restore tests, exports, and maintenance notes. Discovery is only the beginning; operating the selected app is the real ownership decision.

Why the seed is compact

The v1 catalogue chooses depth over breadth. A huge list can look impressive while leaving beginners with no idea where to start. A compact seed lets the self-hosted software directory explain the common workflows well and create enough metadata to prove the programmatic pages. More apps can be added later when the editorial pattern is stable and the maintenance burden is clear.

How maintainers should add apps

A new app should enter through the same questions a reader asks. What hosted product does it replace? What category owns the primary workflow? Which license and stack should be indexed? Does the documentation explain deployment and backup? What honest tradeoff belongs on the detail page? If those answers are missing, the app may be interesting, but the listing is not ready.

Why search is static

Static search keeps the site easy to deploy and fork. Pagefind can index generated HTML without a database, account system, or hosted search vendor. That keeps the project aligned with its own argument: simple infrastructure is easier to understand and easier to leave. If future traffic requires hosted search, the site should document that tradeoff clearly rather than hiding it behind convenience.

How readers should verify a listing

Every reader should treat a listing as a starting point. Open the upstream documentation, check the latest release notes, read the backup instructions, and search recent issues for upgrade or data-loss reports. Then install with sample data before importing anything valuable. The self-hosted software directory can shorten discovery, but it should never replace the operator’s own verification.

Why plain pages matter

The site is intentionally plain because the reader is here to compare software, not admire a launch page. Fast pages, readable typography, crawlable URLs, and direct links to upstream projects are part of the product. If the directory becomes harder to scan than the tools it describes, it has failed its purpose.

Related terms

This page also covers open-source self-hosted apps and self-host alternative to SaaS. Those terms describe how people actually search: sometimes by category, sometimes by SaaS replacement, and sometimes by the promise of owning the service end to end.