Selfhosted
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:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
This is a good way to get started.
Docker and Docker compose on whatever hardware you want to start on.
Most important there. You aren't building a production system for corporate clients, you're doing this for fun. Focus on one thing, try to get that one thing running. Toy with it, make it work. Then start on your next thing. Slowly you'll build up a large system, but it won't be immediate.
I personally have been working on switching from compose to kubernetes, which is way more advanced than a starter needs - but I've been slowly migrating for about 4 weeks now, one service at a time. Just how homelabs are done
What's the benefit of kubernetes over docker for a home server setup?
For home use? Barely any. You can use multiple computers to spread out your load, which is nice for me because I have about 20ish containers running with differing workloads.
But I'm also a developer who needs to keep up on devops, so it's mostly a learning thing for me. But I gotta say it's real nice having everything laid out in a few yaml files that I can tear down and rebuild on a whim
Oh absolutely, but for me docker compose already does that. Kubernetes might be a good learning exercise but I don't think I need load balancing for 1 user, me, on the home network 😅
Some additional benefits also are the management of secrets. In compose you will shove them inside a .ENV file if not directly inside the compose file, while in Kubernetes you can use the secrets resource or even plug in Vault relatively easily. Stateful storage is also better handled. Named volumes are nasty to keep track of, backup and it's not possible to spread them across multiple devices (as in disks) while bind mounts are insecure in general. Kubernetes provides a storage abstraction which is easier to manage.
Obviously the big advantage comes when you want to run stuff on multiple devices to spread the load (or because the one box is saturated), since with compose you would need completely custom and independent setups.
Finally, I would say that running compose makes it much harder to have a monitoring stack supporting your services, since you will need to do all the plumbing for metrics endpoints yourself. And - very last - you can have admission controllers in Kubernetes that prevent certain configuration (e.g. Kyverno with a bunch of default policies), while with compose you need to manually vet every compose file and image (for example, to ensure it doesn't run as root).
That said, compose is perfect to get started and to run stuff on one machine.