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.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
My biggest problem is every docker image thinks they're a unique snowflake and how would anyone else be using such a unique port number like 80?
I know I can change, believe me I know I have to change it, but I wish guides would acknowledge it and emphasize choosing a unique port.
Most put it on port 80 with the perfectly valid assumption that the user is sticking a reverse proxy in front of it. Container should expose 80 not port forward 80.
Containers are ment to be used with docker networks making it a non-issue, most of the time you want your services to forward 80/443 since thats the default port your reverse proxy is going to call
Why expose any ports at all. Just use reverse proxy and expose that port and all the others just happen internally.
Still gotta configure ports for the reverse proxy to access.
Reverse proxy still goes over a port
🤮 I hate gui config! Way too much hassle. Give me cli and a config file anyday! I love being able to just ssh into my server anytime from anywhere and fix, modify or install and setup something.
The key to not being overwhelmed is manageable deployment. Only setup one service at a time, get it working, safe and reliable before switching to actually using full time, then once certain it's solid, implement the next tool or deployment.
My servers have almost no breakages or issues. They run 24/7/365 and are solid and reliable. Only time anything breaks is either an update or new service deployment, but they are just user error by me and not the servers fault.
Although I don't work in IT so maybe the small bits of maintenance I actually do feel less to me?
I have 26 containers running, plus a fair few bare metal services. Plus I do a bit of software dev as a hobby.
Story of my life (minus the dev part). I self host everything out of a Proxmox server and CasaOS for sandboxing and trying new FOSS stuff out. Unless the internet goes out, everything is up 24/7 and rarely do I need to go in there and fix something.
I love cli and config files, so I can write some scripts to automate it all.
It documents itself.
Whenever I have to do GUI stuff I always forget a step or do things out of order or something.
exactly this! notes in the config files is all the documentation i need. and scripting and automating is so important to a self running and self healing server.
Yes, I get lab burnout. I do not want to be fiddling with stuff after my day job. You should give yourself a break and do something else after hours, my dude.
BUT
I do not miss GUIs. Containers are a massive win in terms because they are declarative, reproducible, and can be version controlled.
Yeah, since Christmas, I more it sounds silly, but I've been playing a ton of video games with my kids lol. But not like CoD, more like Grounded 2, Gang Beasts, and Stumble Guys lmao
You're doing i right. Playing cool games with your kids sounds like a blast and some great memories :)
I don't run a service unless it has reasonably good documentation. I'll go through it first and make sure I understand how it's supposed to run, what port(s) are used, and if I have an actual, practical use case for it.
You're absolutely correct in that sometimes the documentation glosses over or completely omits important details. One such service is Radicale. The documentation for running a Docker container is severely lacking.
You should take notes about how you set up each app. I have a directory for each self hosted app, and I include a README.md that includes stuff like links to repos and tutorials, lists of nuances of the setup, itemized lists of things that I'd like to do with it in the future, and any shortcomings it has for my purposes. Of course I also include build scripts so I can just "make bounce" and the software starts up without me having to remember all the app-specific commands and configs.
If a tutorial gets you 95% of the way, and you manage to get the other 5% on your own, write down that info. Future you will be thankful. If not, write a section called "up next" that details where you're running into challenges and need to make improvements.
I started a blog specifically to make me document these things in a digestable manner. I doubt anyone will ever see it, but it's for me. It's a historical record of my projects and the steps and problems experienced when setting them up.
I'm using 11ty so I can just write markdown notes and publish static HTML using a very simple 11ty template. That takes all the hassle out of wrangling a website and all I have to do is markdown.
If someone stumbles across it in the slop ridden searchscape, I hope it helps them, but I know it will help me and that's the goal.
Would love to see the blog
I appreciates that but unfortunately it is under a different identity and I don't want to cross the two.
Understandable. Stay safe out there, thanks anyways :)
I found a git repo with docker compose and the config files works well enough as long as you are willing to maintain a backup of the volumes and an .env file on KeePass (also backed up) for anything that might not be OK on a repo (even if private) like passwords and keys.
I reject a lot of apps that require a docker compose that contains a database and caching infrastructure etc. All I need is the process and they ought to use SQLite by default because my needs are not going to exceed its capabilities. A lot of these self hosted apps are being overbuilt and coming without defaults or poor defaults and causing a lot of extra work to deploy them.
Some apps really go overboard, I tried out a bookmark collection app called Linkwarden some time ago and it needed 3 docker containers and 800MB RAM
Found an alternative solution to recommend?
No, but I'd like to hear it if anyone else finds one
Databases.
I ran PaperlessNGX for a while, everything is fine. Suddenly I realize its version of Postgresql is not supported anymore so the container won't start.
Following some guides, trying to log into the container by itself, and then use a bunch of commands to attempt to migrate said database have not really worked.
This is one of those things that feels like a HUGE gotcha to somebody that doesn't work with databases.
So the container's kinda just sitting there, disabled. I'm considering just starting it all fresh with the same data volume and redoing all that information, or giving this thing another go...
...But yeah I've kinda learned to hate things that rely on database containers that can't update themselves or have automated migration scripts.
I'm glad I didn't rely on that service TOO much.
Its a big problem. I also dump projects that don't automatically migrate their own SQLite scehema's requiring manual intervention. That is a terrible way to treat the customer, just update the file. Separate databases always run into versioning issues at some point and require manual intervention and data migration and its a massive waste of the users time.
If you'll let me self promote for a second, this was part of the inspiration for my Ansible Homelab Orchestration project. After dealing with a lot of those projects that practically force you to read through the code to get a working environment, I wanted a way to reproducably spin up my entire homelab should I need to move computers or if my computer dies (both of which have happened, and having a setup like this helped tremendously). So far the ansible playbook supports 117 applications, most of which can be enabled with a single configuration line:
immich_enabled: true
nextcloud_enabled: true
And it will orchestrate all the containers, networks, directories, etc for you with reasonable defaults. All of which can be overwritten, for example to enable extra features like hardware acceleration:
immich_hardware_acceleration: "-cuda"
Or to automatically get a letsencrypt cert and expose the application on a subdomain to the outside world:
immich_available_externally: true
It also comes with scripts and tests to help add your own applications and ensure they work properly
I also spent a lot of time writing the documentation so no one else had to suffer through some of the more complicated applications haha (link)
Edit: I am personally running 74 containers through this setup, complete with backups, automatic ssl cert renewal, and monitoring
@Dylancyclone @selfhosted This looks very useful. I will study your docs and see if it’s right for me. Thanks for sharing!
I hesitate to bring this up because you've clearly already done most of the hard work, but I'm planning on attending the following conference talk this weekend that might be of interest to you: https://fosdem.org/2026/schedule/event/VEQTLH-infrastructure-as-python/
No that's totally fair! I'm a huge fan of making things reproducible since I've ran into too many situations where things need to be rebuilt, and always open to ways to improve it. At home I use ansible to configure everything, and at work we use ansible and declare our entire Jenkins instance as (real) code. I don't really have the time for (and I'm low-key scared of the rabbit hole that is) Nix, and to me my homelab is something that is configured (idempotently) rather than something I wanted to handle with scripts.
I even wrote some pytest-like scripts to test the playbooks to give more productive errors than their example errors, since I too know that pain well :D
That said, I've never heard of PyInfra, and am definitely interested in learning more and checking out that talk. ~~Do you know if the talk will be recorded? I'm not sure I can watch it live.~~ Edit: Found a page of all the recordings of that room from last year's event https://video.fosdem.org/2025/ua2220/ So I'm guessing it will be available. Thank you for sharing this! :D
I love the "Warning: This talk may cause uncontrollable urges to refactor all your Ansible playbooks" lol I'm ready
That's neat. I never gave ansible playbooks any thought because I thought it would just add a layer of abstraction and that containers couldn't be easier but reading your post I think I have been wrong.
While it is true that Ansible is a different tool that you need to learn the basics of (if you want to edit/add applications), all of the docker stuff is pretty comparable. For example, this is the equivalent of a docker compose file for SilverBullet (note taking app): https://github.com/Dylancyclone/ansible-homelab-orchestration/blob/main/roles/silverbullet/tasks/main.yml
You can see it's volumes, environment variables, ports, labels, etc just like a regular docker compose (just in a slightly different format, like environment variables are listed as env instead of environment), but the most important thing is that everything is filled in with variables. So for SilverBullet, any of these variables can be overwritten, and you'd never have to look at/tweak the "docker compose." Then, if any issue is found in the playbook, anyone can pull in the changes and get the fix without any work from themselves, and if manual intervention is needed (like an app updated and now requires a new key or something), the playbook can let you know to avoid breaking something: https://dylancyclone.github.io/ansible-homelab-orchestration/guides/updating/#handling-breaking-changes
Yeah, self promote away lol
While I am gaining plentiful information from this comments section already, wanted to add that the IT brain drain is real and you are not alone.
Haha, thanks! It's probably more problematic being a solo IT guy as it feels like I don't always have did dedicated time to get projects done. Part of why my lab is overkill is because I want something at work, so I spend a little time at home figuring stuff out, but, you know, family time n all...
Its still fun mostly, but work keeps assuming I must've freed up a lot of time in automating or improving stability so I keep being rewarded with more work outside of IT.
You're not alone.
The industry itself has become pointlessly layered like some origami hell. As a former OS security guy I can say it's not in a good state with all the supply-chain risks.
At the same time, many 'help' articles are karma-farming 'splogs' of low quality and/or just slop that they're not really useful. When something's missing, it feels to our imposter syndrome like it's a skills issue.
Simplify your life. Ditch and avoid anything with containers or bizarre architectures that feels too intricate. Decide what you need and run those on really reliable options. Auto patching is your friend (but choose a distro and package format where it's atomic and rolls back easily).
You don't need to come home only to work. This is supposed to be FUN for some of us. Don't chase the Joneses, but just do what you want.
Once you've simplified, get in the habit of going outside. You'll feel a lot better about it.
That's true, I've done a lot of stuff as testing that I thought would be useful services but then never really got used by me, so I didn't maintain.
I didn't take the time to really dive in and learn Docker outside of a few guides, probably why is a struggle...
My advice is : just use Nix.
It always works. It does all the steps for you. You will never "forget a step" because either someone has already made a package, or you just make your own that has all the steps, and once that works, it works literally forever.
Check out the YUNOhost repos. If everything you need is there (or equivalents thereof), you could start using that. After running the installation script you can do everything graphically via a web UI. Mine runs for months at a time with no intervention whatsoever. To be on the safe side I make a backup before I update or make any changes, and if there is a problem just restore with a couple of clicks via my hosting control panel.
I got into it because it's designed for noobs but I think it would be great for anyone who just want to relax. Highly recommend.
Apparently I'm more than noob level 😅 every time I try to get to Traccar, I get my gateway's landing page.
Regular Traccar uses port 8082 for the web and 5055 for app. I cannot get that either through domain (gateway) or lan IP (yunohost)
Normally I'd go 1.2.3.4:8082 (not my real lan IP) but Yuno seems to ignore that.
I'll do some more digging when I get home, I'm at work with broken concentration
It's a mess. I'm even moving to a different field in it due to this.