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.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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
You can get much better isolation with separate machines but that gets very expensive very fast.
It's not that it provides complete isolation - but it provides enough isolation very cheaply. You still compete with other applications for compute resources but you run in your own little filesystem jail and can run that janky python version that your application needs and not worry about breaking yum. Or you can bundle that old out-of-support version of libaio that your application requires. All of your dependencies are bundled with your application so you don't affect the rest of the system.
And since containers are standardized it allows you to move between physical computers without any modification or server setup other than installing docker or podman. You can run on Amazon Linux, RedHat, Ubuntu, etc. If it can run containers it can run your application. Containers can also be multi-platform so you can run on both ARM64 and AMD64 seamlessly.
And given that isolation you can run on a kubernetes cluster, or Amazon ECS with FARGATE instances, etc.
But that starts to get very enterprisey. For the home-gamer there is still a ton of benefit to just having file-system isolation and an easy way to run an application regardless of the local system version and installed packages. It's a bit of an "experience" thing to truly appreciate it I suppose. Like I said - if you've tried running a lot of services on a system in the past without containers it gets kinda complicated rather fast. Especially if they all need databases (with containers you can spin up one db for each application easily).
I still feel like I'm missing something. Flatpaks help you sidestep dependency hell, so what is docker for? What advantages does further containerization give you if you aren't going as far as proxmox vms.?
I guess I've only tried running one service at a time that needed a database, so I get it if a Docker container can include a database and a flatpak cannot.
Docker will let you run as many database containers as you want and route things such that each service only sees its own database and none of the others, plus even processes on your host machine can't connect unless you've configured ports for that.
Flatpaks are similar, but more aimed at desktop applications. Docker containers are made for services and give more isolation on the network.
Docker containers get their own IP addresses, they can discover each other internally, you get port forwarding, etc. Additionally you get volume mounts for persistent storage and other features.
Docker compose allows you to bring up multiple dependent containers as a group and manage connections between them, with persistent volumes. It'll handle lifecycle issues (restarting crashed containers) and health checks.
An example - say you want a Nextcloud service and an immich service running on the same host. You can create two docker-compose files that launch both of them, each with its own supporting database, and give each db and application persistent volumes for storage. Your applications can be exposed to the network and the databases only internally to other containers. You don't need to worry about port conflicts internally since each container is getting its own IP address. So those two MySQL DBs won't conflict with each other. All you need to do is ensure that publicly available services have a unique port forwarded to them. So less to keep track of.
That sounds really great! I see now why people like it