What is Self-hosting?
Self-hosting means running the software on hardware you control instead of renting it, and what it really moves is responsibility: the security patches, the process that has to stay up, the backup that is only real once it has been restored, and the certificate. That is the trade, and the projects here are best read as a spectrum of how much of it one person can reasonably own.
What you actually take on
A self-hosted deployment is the same application with four jobs that a vendor was doing for you. Someone patches the operating system. Someone restarts the process when it dies and notices when it does not come back. Someone takes a backup and has tested it by restoring it. Someone terminates TLS and keeps the network surface small.
None of that is glamorous and all of it is the product. This is why self-hosting is a decision about the data boundary first and about money second. The boundary is regulatory or contractual sometimes, and a preference other times: the fact that a customer's file never leaves a machine you administer is a property you can state, while the same property from a hosted service is a promise you have to accept. Control over versions is the second reason, since a self-hosted deployment is upgraded when you decide rather than when a vendor decides. The third is capability, because hardware, models and protocols that a hosted service does not offer are only reachable this way. rustdesk/rustdesk is the clearest case in this list, because a remote desktop you host is a different architectural proposition from a remote desktop you rent, and the reason is the rendezvous and relay servers you point it at.
Self-hosted is not one thing, and the phrase covers a wide range. A single binary on a machine in your office. A Compose file with six services. A cluster with an operator. And a managed cloud instance you administer yourself, which is still self-hosted in the sense that matters, because you are the one holding the pager, and for a one-person team that is usually the right answer.
The spectrum of effort
The projects on this page fall into tiers, and the tier predicts what kind of work you have signed up for.
One binary or one container. usememos/memos is the cleanest example: our analysis describes it as a single-binary or Docker note-taking app aimed at fast capture rather than long-form writing, MIT licensed, storing notes in SQLite, MySQL or PostgreSQL and exposing REST and gRPC APIs. go-gitea/gitea is the same shape for a much bigger job, and our analysis describes an MIT-licensed Go forge you can run from a single binary or a container, with Git hosting, review and CI. At this tier your responsibilities are the disk filling up, the backup, and the version you are on.
One container plus its database. nocodb/nocodb turns an existing SQL database into a spreadsheet-style interface with views, forms and a REST API, and installs with one Docker command according to our analysis. The job now includes schema migrations on upgrade, because the application owns your tables.
A stack of services. langgenius/dify bundles a visual workflow builder, a RAG pipeline, agent tools and model management behind one Docker Compose deployment. Our analysis of Dify says it fits teams that want to ship LLM applications without writing orchestration code, and that it costs you a multi-service deployment to run. At this tier you are maintaining a set of components that have to agree with each other, and an upgrade touches several of them at once.
A platform for everything else. coollabsio/coolify manages servers, applications and databases over SSH, and our analysis calls it the right fit for teams that want cloud convenience on hardware they control and the wrong tool if you want a fully managed platform. Here you are running a small private cloud, which means backups for other people's data and access control as well as for your own.
When it is the right call, and when it is a hobby
Self-hosting earns its cost in a few specific situations.
A data boundary you can state. Regulated data, a contract with a customer, or a plain preference not to upload. This is the strongest reason and the one that does not go away when the bill gets compared.
Something a vendor will not run. A GPU you already own, a model with a licence that forbids hosted use, a protocol whose control plane is the point. Self-hosting is sometimes the only way to have the thing at all.
A durable cost advantage at volume. When the traffic is steady and the hardware is bought once, the arithmetic eventually favours owning. It does not favour owning for a small team with variable load, because an idle machine and a used one cost the same.
A product you need to change. Modifying and serving your own deployment is the normal reason copyleft licences are acceptable, and it is also the moment to read the licence.
It is the wrong call when nobody will own the pager. Not you, not a rota, nobody. A self-hosted system without an owner is a future incident with a delay.
It is the wrong call when the tool is a commodity. Notes, a read-only blog, a status page: the hosted version is free, and the operational hours are worth more than the money saved.
And it is the wrong call when the hardware commitment dwarfs the software. A single model on a machine with a large amount of memory is a different category of decision from a notes app, and the reason people get this wrong is that both are described by the same two words.
Where it goes wrong
Six, and most of them are the same mistake in different clothes.
The backup that has never been restored. A copy is not a backup until someone has restored it onto a machine and confirmed the data is there. immich-app/immich is blunt about this: our analysis of Immich describes an AGPL-3.0 TypeScript monorepo that runs a photo and video library on your own hardware with mobile apps that back up automatically, and it records that the README says plainly to keep a 3-2-1 backup anyway. Automatically backed up by the phone is not the same as recoverable.
The install that is four commands and the operations that follow. odysseus-dev/odysseus is the honest example in this list: our analysis describes an install of four commands, a default branch of dev, and an AGPL-3.0-or-later licence. A development branch is a reasonable thing to develop against and an unusual thing to run in production. f/prompts.chat makes the other half of the point, with our analysis noting that the install is short while the operational surface is not.
Storage. Photos, video and logs grow quietly, and the disk that filled at 2am is the disk you did not monitor. There is no equivalent line item for this on a hosted invoice.
The exposed admin panel. A self-hosted service reachable from the internet with a login page is a target, and the network configuration around it is part of the application now.
The licence follows the code. Our analysis of RustDesk puts it directly: an AGPL-3.0 licence that follows the code. NocoDB is a different shape of the same question, with our analysis recording that its licence is not OSI-approved, which is a fact to establish before you build on it and not after.
No service level. Nothing here comes with a support contract, and the practical substitute is knowing which project you are running and having a plan when it stops.
How the projects divide
The list is a spectrum, and reading it in tiers is more useful than reading it as a ranking.
Discovery first. awesome-selfhosted/awesome-selfhosted is the index most people start from, and our analysis describes it as a curated catalogue of free software network services you can run on your own servers, a discovery index rather than a deployment tool, with a last push recorded on 2023-08-22. That date matters in a specific way: a catalogue that has not been updated will list projects that have changed licence, been archived or been superseded, so treat it as a map of the territory rather than a list of recommendations.
Single-binary services. Memos for notes, Gitea for a forge, both of which our analysis describes as runnable from one binary or one container. This tier is genuinely approachable, and the work is backups and disk.
Databases behind an interface. NocoDB is the representative case, and our analysis also notes the README says little about upgrades, which is worth knowing before the first schema migration.
Applications with a stack behind them. Dify is the largest here, and Odysseus is the compact one. Both are the tier where you decide that several components are now part of your system.
Remote access. RustDesk is the one that is not a database or a workspace, and the reason to run it yourself is structural rather than financial.
And the platform. Coolify exists for the moment when the answer to every other question is to run more than one of these things, and it is the point at which self-hosting stops being a project and becomes a platform responsibility.
In practice
Self-hosting is a trade of money for responsibility, and the projects here differ mostly in how much responsibility one person can hold: a single binary with a backup plan, a container that owns your schema, a stack whose components have to agree, or a platform for everything else. Pick the smallest tier that satisfies the data boundary you actually have, not the most capable one. Read the licence before you modify anything, restore a backup before you need to, and pin a version rather than tracking a development branch, because the incidents in this category are almost never caused by the software being wrong.