Four LXCs
this post was submitted on 29 Jan 2026
119 points (98.4% liked)
Selfhosted
56036 readers
775 users here now
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!
founded 2 years ago
MODERATORS
I have 43 running, and this was a great reminder to do some cleanup. I can probably reduce my count by 5-10.
61 containers in 26 docker files.
49, I could imagine running all of those bare would be hard with dependencies
Uh.. Probably somewhere around 150?
12 LXCs and 2 VMs on proxmox. Big fan of managing all the backups with the web ui (It's very easy to back to my NAS) and the helper scripts are pretty nice too. Nothing on docker right now, although i used to have a couple in a portainer LXC.
13 in a docker LXC, most of my stuff runs on 13 other dedicated LXCs
None. I run my services they way they are meant to be run. There is no point in containers for a small setup. Its kinda lazy and you miss out on how to install them.
Small setups can very easily turn into large setups without you noticing.
The only bare-metal setup I'd trust to be scaleable is Nix flakes (which I'm actually very interested in migrating to at some point)
I've never even heard of NIX flakes before today. It looks like another soluion in search of a problem. I trust debian and I trust bare metal more than any container setup. I run multiple services on one machine. I currently have two machines to run all my services. No problems and no downtime other than a weekly update and reload. All crontabed, all automatic.
At work I have multiple services all running in KVM including some windows domain controllers. Also no problem and weekly full backups are a worry free. Only requiring me to checks them for consistency.
In short as much as people try to push containers they are only useful if you are dealing with more than few services. No home setup should be that large unless someong is hosting for others.
I disagree that Nix is a solution in search of a problem, in fact it solves arguably the two biggest problems in software deployment: dependency hell and reproducibility (i.e. the "It works on my machine" problem)
Every package gets access to the exact version of all the dependencies it needs (without needless replication like Flatpaks would have) and sharing a flake to another machine means you can replicate that exact setup and guarantee it will be exactly the same
Containers try to solve the same problems, and succeed to a somewhat decent extent, although with some overhead of course.
I'm not trying to criticize you or your setup at all, if Debian alone works for you, that's fine. The beauty of open source and self hosting is that we can use whatever tools we want, however we want. I do though think it's good practice to be aware of what alternatives are out there should our needs change, or should our tools change to no longer align with our needs.
All containers do that. Its nothing new just another implementation of the idea with its own idea about what is best. It only saves resources in the form of time if its a large scale operation and finally its just the last in a long line of similar solutions.
- Because I'm old, crust, and prefer software deployments in a similar manner.
I salute you and wish you the best in never having a dependency conflict.
I've been resolving them since the late 90s, no worries.
load more comments
(1 replies)
load more comments
(4 replies)
140 running containers and 33 stopped (that I spin up sometimes for specific tasks or testing new things), so 173 total on Unraid. I have them gouped into:
- 118 Auto-updates (low chance of breaking updates or non-critical service that only I would notice if it breaks)
- 55 Manual-updates (either it's family-facing e.g. Jellyfin, or it's got a high chance of breaking updates, or it updates very infrequently so I want to know when that happens, or it's something I want to keep particular note of or control over what time it updates e.g. Jellyfin when nobody's in the middle of watching something)
I subscribe to all their github release pages via FreshRSS and have them grouped into the Auto/Manual categories. Auto takes care of itself and I skim those release notes just to keep aware of any surprises. Manual usually has 1-5 releases each day so I spend 5-20 minutes reading those release notes a bit more closely and updating them as a group, or holding off until I have more bandwidth for troubleshooting if it looks like an involved update.
Since I put anything that might cause me grief if it breaks in the manual group, I can also just not pay attention to the system for a few days and everything keeps humming along. I just end up with a slightly longer manual update list when I come back to it.
I’ve never looked into adding GitHub releases to FreshRSS. Any tips for getting that set up? Is it pretty straight forward?
load more comments
(4 replies)
All of you bragging about 100+ containers, please may in inquire as to what the fuck that's about? What are you doing with all of those?
Kube makes it easy to have a lot, as a lot of things you need to deploy on every node just deploy on every node. As odd as it sounds, the number of containers provides redundancy that makes the hobby easy. If a Zimaboard dies or messes up, I just nuke it, and I don't care whats on it.
In my case, most things that I didn't explicitly make public are running on Tailscale using their own Tailscale containers.
Doing it this way each one gets their own address and I don't have to worry about port numbers. I can just type http://cars/ (Yes, I know. Not secure. Not worried about it) and get to my LubeLogger instance. But it also means I have 20ish copies of just the Tailscale container running.
On top of that, many services, like Nextcloud, are broken up into multiple containers. I think Nextcloud-aio alone has something like 5 or 6 containers it spins up, in addition to the master container. Tends to inflate the container numbers.
load more comments
(3 replies)
load more comments
(8 replies)
0, it's all organised nicely with nixos
Boooo, you need some chaos in your life. :D
That's why I have one host called theBarrel and it's just 100 Chaos Monkeys and nothing else
load more comments
(2 replies)
load more comments
(1 replies)
I know using work as an example is cheating, but around 1400-1500 to 5000-6000 depending on load throughout the day.
At home it's 12.
I was watching a video yesterday where an org was churning 30K containers a day because they didn't profile their application correctly and scaled their containers based on a misunderstanding how Linux deals with CPU scheduling.
load more comments
(1 replies)
I am like Oprah yelling “you get a container, you get a container, Containers!!!” At my executables.
I create aliases using toolbox so I can run most utils easily and securely.
load more comments
(4 replies)
Zero. Either it’s just a service with no wrappers, or a full VM.
Why a full VM, that seems like a ton of overhead
For some convoluted networking things it’s easier for me to have a full “machine” as it were
Zero.
About 35 NixOS VMs though, each running either a single service (e.g. Paperless) or a suite (Sonarr and so on plus NZBGet, VPN,...).
There's additionally a couple of client VMs. All of those distribute over 3 Proxmox hosts accessing the same iSCSI target for VM storage.
SSL and WireGuard are terminated at a physical firewall box running OpnSense, so with very few exceptions, the VMs do not handle any complicated network setup.
A lot of those VMs have zero state, those that do have backup of just that state automated to the NAS (simply via rsync) and from there everything is backed up again through borg to an external storage box.
In the stateless case, deploying a new VM is a single command; in the stateful case, same command, wait for it to come up, SSH in (keys are part of the VM images), run restore-<whatever>.
On an average day, I spend 0 minutes managing the homelab.
load more comments
(6 replies)
How it started : 0
Max : 0
Now : 0
Iso27002 and provenance validation goes brrrrr
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| DNS | Domain Name Service/System |
| LXC | Linux Containers |
| NAS | Network-Attached Storage |
| Plex | Brand of media server package |
| SSH | Secure Shell for remote terminal access |
| SSL | Secure Sockets Layer, for transparent encryption |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
| k8s | Kubernetes container management package |
9 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #42 for this comm, first seen 29th Jan 2026, 11:00] [FAQ] [Full list] [Contact] [Source code]
44 containers and my average load over 15 min is still 0,41 on an old Intel nuc.
view more: next ›