A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
You need different Subdomains as you suggested in your first paragraph. And add a reverse proxy like nginx or caddy to the machine which then proxies the different subdomains to the respective services (e.g. lemmy.your.site to localhost:2222, mbin.your.site to localhost:3333).
Theoretically, you could put a landing page behind some SSO/iam like authentik, and then link to the subdomains from the landing page, but eventually users will need be on the subdomain to use a specific site.
Caveat: this is not my area of expertise. However, I agree SSO is going to be the hardest part of this.
OP, you can use lldap to centralize authentication, so that each user had only one account and one password for all sites. It's trickier to get each of these platforms to work together with SSO. For that, you'll need something like Authentik (OSS SSO solution, like Okta) which you then back by lldap - Authentik handles the SSO and authorization part, and uses lldap for the authentication part. I suggest doing it in stages: install your servers, get them using lldap to log in, and then when it's all working insert Authentik into the mix. Doing something like this and learning all the technology at once is boiling the ocean.
I'm recommending lldap over OpenLDAP because I've used both extensively, and OpenLDAP is a nightmare whereas lldap isn't. lldap is trivial to install, and comes with a nice, simple user/group admin web interface, a sane default schema configuration, and is stupid easy to back up. Just getting OpenLDAP configured with the right schemas can take forever. If you'd said you already had a lot of experience with LDAP in general, then sure: OpenLDAP is capable and powerful. But it's harder.
My one caveat about lldap is that I'm not sure that it's possible to set up master/slave replication - or any sort of replication - which is probably not going to be an issue for your all-in-one set-up, but would limit scaling and failover if you ever get there.
I do rant a little about OpenLDAP because LDAP was in supposed to be lightweight OLAP, and yet is some of the most frustrating software I've ever had to deal with.
Again, I'm not a devops, or any sort of ops, guy, so my perspective is colored by the an attitude that ops is a necessary evil, and not something I love, so easier==better.
Alternatively, you can add an LDAP outpost/provider to Authentik. Now you don't need to manage any LDAP server at all, and use the Authentik directory to manage users and groups. wiki link
I haven't used Authentik myself at all; Okta at one place I worked, but that was managed by the ops team so I didn't have much to do with it.
Committing to LDAP is one thing; getting SSO is a whole other level of effort. Again, I have experience with LDAP so it seems manageable, and common enough to be worth setting up - does a large enough portion of OSS hosted software support SAML or OpenID or whatever to make setting up Authentik worth the effort?
I'll re-iterate, I do not enjoy ops. I do it only because it's slightly more important to me to have control over my data than it is to not have to admin stuff. I like lldap specifically because it's a single executable, one or two really basic config files (requiring a bare minimum of understanding LDAP to configure), and one SQLite DB file - backing it up is, like, 3 files. This has huge value to someone like me, far exceeding the capability limitations of lldap vs OpenLDAP. If Authentik is just as easy, with minimum external dependencies, then I'm interested. If I have to install, configure, and administer and maintain PostgreSQL, redis, and a half dozen other external dependencies... then my family can live without SSO :-)
Yea no I'd never recommend Authentik for its simplicity. In fact I'd say it's pretty complicated to set up and a lot harder to learn how to use.
It does indeed need an external database, and likes to run in a kubernetes cluster...
I mostly set it up to learn about SSO, but by now it's hooked into everything I could hook it up with.
Definitely not worth the effort in any normal homelab scenario, apart from needing some cool points
Thanks!
I have a similar setup with around 5 federated services (Lemmy/bookwyrm/mastodon(GoToSocial)/pixelfed/Peertube/etc... and it works well. The slowest component is the internet connection by far. Yunohost makes it easy but a couple of the more niche services are on docker. All self hosted on an old PC and a pi.
Just a note, these are all less than 5 users and my setup is not designed for anything more than the family. Also of all the services, Mastodon base install was by far the most resource intensive of all of them. It's definitely made for more than 100+ users and quite quickly used up all my hard drive. Their caching system needs some work if I'm honest. After self hosting for about half a year, I went with GoToSocial, which saved me 100s of gigabytes. It's no faster or slower but the same clients work with it. It's basically designed for less than 10 users which is nice. No issues after about a year.
I would recommend installing k3s and cnpg on the VPS. These will make it easier to run the various containers and databases you will need to run lemmy, etc. This is the standard way that big companies run servers in 2025, and it's 100% portable to any server/hosting company just through copying and pasting the yaml files (like docker compose).
https://docs.k3s.io/quick-start
https://cloudnative-pg.io/documentation/1.25/quickstart/
Make sure you save backups of your VPS, and use object storage to backup your databases.
I have example kubernetes configuration for lemmy on my Git. It doesn't use any volumes/local-storage, all user data is saved into either the database or object storage, to make it cheap and easy to backup.
I'm a professional DevOps engineer, so I work with hosting every day. Let me know if you have any questions or want advice.
Don't you think recommending k8s to someone who just wants to run some services, which partly don't even have k8s support/helmcharts on the same machine is a bit too much? Compared to docker compose or whatever op is using, it's way more complex if you're not already familiar with kubernetes resources.
I don't know much about k3s in particular admittedly, but I wouldn't recommend k8s for this unless op just wants to use it as a lab.
Probably overkill and I agree with you.
K8 is for scale. Like managing a whole fleet of servers. Even with my devops team, it's quite a lift to suggest it to someone who is getting their feet wet.
Of the services OP is asking about, I've only run Lemmy, but I will say that running fediverse services are quite advanced, which is exactly what k8s is made for - Running advanced web applications.
I'm firmly on the "k8s at any scale" team. If you can figure out how to run the k3s install command and are willing to look at some yaml documentation, you will have a much easier time setting up database and networking, running backups, porting your infrastructure to other providers, and maintaining everything, than with legacy control panels or docker compose. The main reason why Docker Compose is so much more accessible for self-hosters is because of the quantity of noob-focused documentation for Docker Compose, But learning either system requires learning the same concepts of containers, IP adresses, storage, etc. Docker Compose also has some disk and networking shortcuts for single-server workloads, but they also have their downsides (what is a macvlan?).
The main reason why I think Kubernetes is critical for this specific workload is the number of production-critical databases that OP will need to run. OP will be running something like 4-8 postgres databases, with high uptime and 100% durability requirements. Trying to do that manually with Docker compose just isn't feasible unless you're willing to code. Kubernetes makes all of that automated with CNPG. See how easy it is to create a database and have automated backups to S3 with Kubernetes
The biggest challenge for kubernetes is probably that the smaller applications don't come with example configs for Kubernetes. I only see mastodon having one officially. Still, I've provided my config for Lemmy, and there are docker containers available for Friendica and mbin (though docker isn't officially supported for these two). I'm happy to help give yaml examples for the installation of the applications.
you will have a much easier time setting up database and networking, running backups, porting your infrastructure to other providers, and maintaining everything, than with legacy control panels or docker compose.
I really don't see this. Database? Same but needs a service. Networking? Services and namespaces instead of docker networks. Backups? Basically same as Docker but k8s has cronjobs so you can have it at the same place as your other stuff which is a good point. Porting infrastrutcture? Copy compose file, env files and volumes vs. copying all resources and pv.
I am absolutely not against self hosting in k8s and if IP already had k8s running, I'd recommend it too. But I don't see the benefits for the scenario op described.
You might be right with the better/more accessible docker docs everywhere being the main reason it's so popular, but it's also usually just one file that describes everything AND is usually the supported install method of many projects where helm charts are often third party and lack configurability.
CNPG is cool, but then OP also needs to learn about operators and custom resources :) More efficient? Yes. More complex? Also yes.
The biggest challenge for kubernetes is probably that the smaller applications don’t come with example configs for Kubernetes. I only see mastodon having one officially. Still, I’ve provided my config for Lemmy, and there are docker containers available for Friendica and mbin (though docker isn’t officially supported for these two). I’m happy to help give yaml examples for the installation of the applications.
As said above, I agree it's one challenge, but added complexity is not to underestimate.
Completely off topic: Your post did make me think about running my own cluster again though. I also work on k8s at my devops dayjob but with a cloud provider it's not the same than running your own ofc. I've also been thinking about tinkering with old smartphones in that potential cluster..
I'd say the easiest is installing them using Docker, with a reverse proxy in front. That way you're not mixing multiple services into the same database and stuff like that.
Do you have any idea how enhance works and if I can have it alongside that, friendica seems easy enough to set up without docker or anything, I think im already using docker through enhance since I have a docker.list
Not to sound dismissive, but this post is such a perfectly phrased AI prompt. 😂
I prob got used to talking to it, have to reword what I say 50 times for it to work
Also Mbin vs Piefed?