Directories & comparison

awesome-selfhosted

Curated list of self-hosted software. Fits open-source apps that people run themselves.

Cost
Free

Free to use. No paid tier is needed to list or post.

Verdict
slow burn

Slow burn: a strict list, and accepted projects get steady traffic.

Difficulty
Medium

Needs preparation, a review, or a steady habit before results.

Effort
Low

About 2 to 4 hours a month.

First result
2 to 6 weeks (pull request review)

A rough range for one person working on it part-time.

Payoff
Compounds

keeps growing while you keep at it.

Best for

Self-hostable open-source apps with a license the list accepts.

Not for

Hosted SaaS with no self-host option.

Pros

  • Self-hosting audience that installs software
  • Lasting listing

Cons

  • Strict acceptance rules
  • Only for self-hostable open source

The full guide

Last verified 2026-10-30

01What it is and who is there

awesome-selfhosted is a large, curated list of free software that people can run on their own servers. Readers are self-hosters, home-lab users and system administrators looking for apps to install. It has strict rules on what it accepts, so a listing is a sign of quality to that audience.

02Cost and what you actually pay for

It is free. The cost is meeting the list's requirements and keeping your project in good shape after it is listed.

03Is it right for you?

It fits open-source apps that people can install and run themselves, with a license the list accepts. It fits poorly for hosted SaaS with no self-host option, and for very new projects. Read the requirements before you build your hopes on it.

04Before you start

  • Read the list's contributing guidelines in full. They cover license, project maturity, and how entries are written.
  • Make sure the project has clear install docs, a license file and recent releases.
  • Prepare a short, factual description in the list's style.

05Step-by-step: how to distribute here

  1. Check that your project meets every requirement in the contributing guide.
  2. Find the right category in the list.
  3. Open a pull request following the exact entry format.
  4. Answer maintainer questions and make requested changes.
  5. Once merged, keep releases going. Inactive projects may be removed under the list's rules.

06What to post or submit

Entry, in the list's format:

- [Project](https://[project site]) - [What it does, briefly]. ([Demo](https://[demo]), [Source Code](https://[repo])) `[License]` `[Language or platform]`

Check the current format in the contributing guide, since it can change.

07Common mistakes and do-nots

  • Do not submit hosted-only products.
  • Do not submit a project with an unclear or unaccepted license.
  • Do not break the entry format.
  • Do not resubmit after a decline without fixing the reason.

08How to measure it

  • Track referrals from github.com to your repo and site.
  • Track stars and install docs visits after the merge.
  • A realistic test: compare traffic in the month before and after the merge.

09Time budget

  • Before: 2 to 4 hours to meet requirements and prepare the entry.
  • During: 30 minutes for the pull request.
  • After: ongoing release upkeep.

10Pair it with

11Sources

Sources