Self-Hosted Software Directory

Self-hosted software is not just “open source software you can install.” In practice, it means you are responsible for where the application runs, how it is exposed, how its data is stored, how it is backed up, and how it is updated over time.

That operational ownership changes the evaluation model. With SaaS, you mostly compare features, price, and vendor reputation. With self-hosted software, you also have to reason about deployment shape, identity integration, storage model, recovery path, observability, and the long-term maintenance burden your team is willing to absorb.

A self-hosted tool is not only an app choice. It is an infrastructure choice.

The strongest advantage is control over data and operating boundaries. Teams use self-hosted tools when they do not want core source code, documents, logs, or internal workflows to live entirely inside a third-party vendor boundary they cannot inspect or tune.

The second advantage is cost structure. Self-hosting does not automatically mean cheaper, but it often replaces unpredictable per-seat or per-feature SaaS expansion with infrastructure costs that are easier to model. That matters when a team is scaling quickly or when usage-heavy systems become expensive in hosted plans.

The third advantage is architectural flexibility. You can place systems close to your network, identity provider, storage layer, and security tooling instead of adapting your internal workflow around an external product. The trade-off, of course, is that you inherit responsibility for patching, upgrades, incidents, and backups.

This directory is not meant to imply that every project here is equally mature, production-ready, or suitable for the same environment. Its purpose is to help you shortlist faster by grouping tools into real operational categories and linking directly to the project source or canonical destination.

We prioritize category clarity, practical descriptions, and faster discovery signals over vanity copy. Where the source text clearly exposes deployment cues such as Docker, Kubernetes, VPS, Raspberry Pi, or language/runtime hints, those are surfaced in the cards because they help you evaluate fit before you open the project docs.

The right way to use a page like this is to narrow to a category, identify the serious candidates, and then validate the project against your environment: auth model, persistence, backup path, upgrade discipline, resource profile, and maintenance health.

Most teams do not start with a giant homelab fantasy stack. They start by replacing one or two clear SaaS dependencies. Common first layers include personal cloud storage, password management, internal notes or wikis, reverse proxying, and basic identity or SSO integration.

The next layer is usually collaboration and delivery infrastructure: Git hosting, CI/CD, artifact storage, observability, dashboards, ticketing, and workflow automation. In media-focused or home-lab setups, that often expands into Jellyfin or Plex-style media platforms, photo libraries, download management, DNS filtering, backup systems, and personal dashboards.

In other words, the stack is rarely just “one app.” It usually becomes: reverse proxy, identity, storage, database, backup, observability, and then the product layer on top. The products in this directory are most useful when you think about them as part of that larger operating system rather than isolated installs.

Most people do not browse a self-hosted directory looking for one random app. They are usually trying to solve a specific class of problem. That is why the most useful way to think about this space is by software groups rather than by individual project names.

Each group usually maps to a different operating concern. Collaboration tools change how teams work together. Infrastructure tools shape ingress, security, and uptime. Media and personal productivity tools are more often chosen for ownership, privacy, or cost reasons. Backup and observability tools sit underneath everything else because they make the rest survivable.

In practice, the best way to use this directory is to start with the software group that matches your real need, shortlist two or three serious candidates, and only then compare install model, auth, storage, upgrade path, and maintenance signals. That approach is usually much more productive than scanning hundreds of unrelated project names.

• What does "self-hosted" actually mean?▼

  Self-hosting means the application runs on infrastructure you control, such as a VPS, dedicated server, homelab machine, or internal network. You own the deployment boundary, data path, backups, updates, and exposure model instead of handing those responsibilities entirely to a SaaS vendor.
• Is self-hosting actually cheaper than SaaS?▼

  Sometimes, but not automatically. Self-hosting often lowers recurring subscription cost, especially for storage-heavy or seat-based products, but it replaces vendor margin with infrastructure and operational work. The correct comparison is server cost plus maintenance time, upgrades, monitoring, backups, and incident handling versus hosted subscription spend.
• What skills should a beginner have before self-hosting tools?▼

  At minimum, a beginner should be comfortable with Linux basics, environment variables, DNS concepts, reverse proxies, volumes, and backups. Docker makes first deployments easier, but you still need to understand where data lives, how to restore it, and how to upgrade without breaking the service.
• What is a sensible first self-hosted stack for most people?▼

  A practical beginner stack is usually reverse proxy, DNS, automatic TLS, one database, persistent storage, and a backup routine. On top of that, people often start with a password manager, file sync platform, wiki, or media server. The winning move is not installing ten tools at once. It is choosing one useful product and giving it a reliable operating foundation.
• How do I choose between Docker, a VM, and Kubernetes for deployment?▼

  For most individuals and small teams, Docker Compose is the default starting point because it keeps deployment understandable and recovery simple. A VM is useful when a product expects a more traditional host environment. Kubernetes makes sense when you already operate cluster infrastructure and genuinely need scheduling, rollout control, and multi-service orchestration. Most self-hosted tools do not need Kubernetes on day one.
• Which categories are most commonly self-hosted first?▼

  The most common first categories are file storage and sync, password managers, notes and documentation, media servers, reverse proxies, DNS filtering, and Git hosting. These are the categories where privacy, cost, operational control, or household/team usage make the benefits obvious very quickly.
• How should I evaluate whether a self-hosted tool is production-ready for my environment?▼

  Look beyond the feature list. Check installation clarity, backup and restore guidance, auth options, upgrade discipline, storage model, project activity, issue quality, observability hooks, and whether the product fits your team’s actual tolerance for maintenance. A good self-hosted tool is not just feature-rich. It is survivable to operate.