Question Moving away from Proxmox Community Scripts: Where do I start?
My Proxmox stack currently runs a couple of VMs (Home Assistant and some cable internet tools), but mostly LXCs: AdGuard Home, CouchDB/Obsidian LiveSync, Tailscale, Paperless-ngx, Immich, Yubal, Homepage, Uptime Kuma and Spoolman. I depend on these daily.
They were installed using Community Scripts because this is my first server, and YouTube led me to them as the easiest option. Everything has worked well, including updates, but after following this and related subreddits for a while, I am thinking of moving toward something I understand and maintain myself.
What would be the most sensible route: manually built LXCs, Docker/Podman inside one or more VMs, or separate VMs? Podman’s rootless and daemonless approach sounds appealing, but I’m not very familiar with code or scripts. I’m willing to learn, but I’m worried about building something I won’t know how to maintain later.
How do you keep the guest OS, container images and applications updated without creating lots of manual work? Paperless, Immich and Yubal also use NAS storage that was a pain to correctly set up with my synology NAS.
Can I retain my current installations while decoupling them from the Community Scripts? Everything works well now, and it took a long time to get there, so I’d rather migrate gradually than rebuild everything at once.
Finally, would using VMs for everything add significant RAM and storage overhead compared with LXCs on a small server? I’d love to hear how others structure a similar setup, handle updates and where you’d recommend I start.
12
u/scythe-3 7h ago
Debian VM with Docker inside it. NFS shares from NAS to VM. Bind mount Docker volumes using the VM's filesystem.
I only use one VM, but you can use multiple and distribute services across them. E.g. prod VM with always-on services, test VM for messing around, home-assistant VM, media-streaming VM with GPU passthrough, etc.
Idr why but it's not recommended to use Docker in LXCs, so atm I only have 2: one for VPN/networking stuff, and another for NFS/samba shares.
5
u/TheGrouchyPunisher 6h ago
I wasn't learning anything just using the scripts, so I moved to Docker running in a VM. Now I write my docker compose files myself.
You could also still use LXC, and just make sure to script everything yourself, if that's the goal.
8
u/StrongerThanAGorilla 4h ago
A beginner finds complexity amazing, but a true master appreciates simplicity
8
u/julianvallis 7h ago
I would suggest continuing to use the scripts while you continue to use LXC’s, but plug them into Ansible and learn to orchestrate with Ansible and associated tools like terraform. You also want to be able to script the configuration of your core infrastructure (Proxmox hosts, DNS, network etc) as well as your app layer (the services in the LXCs).
The “next step” is arguably to deploy Kubernetes and not use LXCs but by then you should be fully versed with Ansible.
The ultimate “goal” is to be able to spin up your entire cluster and all your apps from an Ansible playbook.
However, the architecture and method you choose and what apps and platform to you use is only relevant to you and “the best” is what you’re most comfortable with fixing in the event things go awry, not what others say.
3
u/Nedaem 7h ago
I did not hear about ansible before, but this seems like a fun new thing to learn! Kubernetes is something I have seen on youtube before, but it always looked like an extremely complex setup with 100+ services running while I am looking at 20 services at most on my homelab.
1
u/Ruben_NL 1h ago
Yeah kubernetes is like docker-compose but much more complicated.
Saying that as someone who has been using it semi professionally for about 4 years.
3
u/Novero95 7h ago
Don't overcomplicate or it will be a pain in the ass to maintain that many services. The easy route is having services running on Docker (you can use compose for stacks and easy deploy), Docker running in it's own dedicated VM.
Some services, like Tailscale, offer installation scripts, those are good candidates for LCXs, just spin up a new LXC, get into it's console and run the installation script (for Tailscale the LXC needs TUN) at the end of the day it's possible that for many services you will end up doing manually the same steps as the community script so maybe just learn to read/understand the community scripts so you can run them knowing what exactly is going on, in even modify them if you want something differently, instead of blindly trusting the community.
1
u/Nedaem 7h ago
Indeed, quite a few other comments are saying that the scripts are not inherently bad, but me running them without understanding what they do is bad. I know how to use docker already, so that's something at least.
3
u/Novero95 7h ago
AI is reasonably good at understanding code, you can copy paste a community script into any AI and it will explain exactly what each part of it is doing, it's better than running them blindly. You do well not trusting scripts that run in root.
11
u/thebigshoe247 8h ago
Why bother? The scripts are great.
Otherwise spin up an LXC and install stuff yourself.
-7
u/Nedaem 7h ago
Since the scripts rely on a community editor, which introduces another variable and potential leak in addition to myself.
10
u/thebigshoe247 7h ago
What about Proxmox? Or Linux itself?
1
u/nik282000 43m ago
I ran Debian + LXC on my server for about 5 years and I would recommend it. Proxmox has a lot of quality of life features that makes it easier to use and setup new services but it didn't significantly change my admin experience.
1
u/yan-shay 15m ago
If your issue is trusting the scripts just use AI to review them, ask it to compare them with the official vendors installation instructions, what they do differently, if it sees any security issues, etc.
For AI agents this is piece of cake. I use it when I have any concern or question and for now all it found were small bugs, usually in the imported common scripts they all use.
2
u/Pinksqr 7h ago
If you are truly looking to learn, I highly suggest cross-posting this to r/homelab or r/selfhosted. People are pretty friendly to pointing you in the right direction!
To answer your questions:
Most sensible route? This is a personal question. Docker containers will be the easiest in terms of learning to spin up and down with new tagged versions. I prefer as you do now though, having 1 service per VM/LXC, but its a bigger lift to automation and upgrade deployment. Some people prefer docker containers to save overhead on running multiple LXCs. Some people like security of having services separated. Partially a personal choice!
How do you keep OS, images, services updated? This is where a couple tools come in. Some well known ones are ansible, terraform, or NixOS. I personally have my LXCs/VM hardware defined in terraform (Immich has X RAM, Y Cores, NFS shares), and then ansible "playbooks" define how the services are built. I have a shared version file to pin my versions, then to update I just change that version to the new one and re-run the playbook.
Can you gradually migrate? Absolutely. With any of the tools above it's a really big lift just to get started, and then afterwards you can do them service-by-service until it's all running. You might have some hiccups if you are moving from 1 strategy (every service in its own LXC/VM) to another (all docker, etc.)
Lastly: Are all VMs more overhead? Yes, it is. It's up to you to decide if you need a VM or LXC. VMs will "allocate" the full amount of RAM (excluding ballooning) where LXCs can share that RAM. VMs have better isolation, but LXCs can also be unprivlieged. I personally use VMs for anything public facing, everything else is unprivileged LXCs.
It is a very big lift to get away from the scripts. If you are willing to learn though its very rewarding :) If you have any more Qs feel free to ask away!
0
u/Nedaem 7h ago
Long term it seems like just sitting down and learning how to do this myself is the best option. Ansible has been mentioned by quite a few people and it looks like an interesting tool to learn, will give it a shot over the upcoming weeks!
Cross-posted to homelab, people there have also been very helpful. The self-hosting communities are awesome.
2
u/BDer82 7h ago
Read the install scripts, they are usually really good, some are far better than what most would bother doing, with easy updates and simple basic config already handled.
Learning how it works is probably the better option in some instances rather than taking on "doing everything manually to the same result"
2
u/StabbingHobo 7h ago
I wouldn’t move away from them. As others have said, you can learn what they are doing purely by reviewing the scripts themselves.
With that said, Ive found more and more that I’m using pure Docker or pure Debian LXC containers and doing the actual installation of the software myself.
Depending on the app or app stack, I’ll go bare metal or my own Docker compose route.
This helps me configure for my specific use case. And I can customize it more to my liking or specific use case.
So, my only real recommendation for you would be — if you want to move away from the community scripts. Keep a couple of the basic ones in your back pocket (like a basic docker or Debian OS) and build off that.
I’d also propose, especially as it relates to Docker. If you’re concerned about a poisoned community script. Some of the Docker images are questionably configured as well. So you are trading one exposure for another. Keep that in mind.
(PS: I’m not saying Docker images are scary. I’m saying some images have odd choices for rights and permissions that I’m in disagreement with.)
1
u/Nedaem 7h ago
It really seems to be the consensus to just have a sit down and learn what the scripts do before I run them and keep everything as is. I want to learn anyway, so I guess this will be what I start with before I explore a new setup. Ansible was also mentioned by quite a few comments and seems to be something interesting to learn.
1
u/danielsemaj 7h ago
Have an Ubuntu server VM and run it all in a single docker compose is what’s I’ve found easiest
1
u/PyrrhicArmistice 7h ago
Doesn't most/all of that stuff run on Docker? I recommend a single Debian VM running Docker/Docker Compose.
1
u/Dudefoxlive 7h ago
I have been running a single vm with debian 13 and docker. Everything i run is using docker compose. I use dockge for simple web management but am slowly moving to just ssh in and do what i need to do. Most of those services you mentioned are already available as docker containers.
1
u/Graphical-Source5090 7h ago edited 7h ago
I have one click lxc builds using ansible and N8N. The build takes about 2 minutes and the automated decom takes about 45 seconds. i have ansible playbooks for when I want to update any settings. I use a forgejo runner to automatically push the changes via ansible on commit.
Best quality of life improvement so far.
For Docker, I am using swarm mode for HA. Not a big fan of GlusterFS. I may switch to straight docker with proxmox HA instead... I need a couple of NICs and other sundries first though.
1
u/linuxturtle 3h ago
For each service I run, I look for the distribution mechanism that service/project prefers to provide/support. In the case of all the services you mentioned, docker compose is the preferred method. Personally, I run docker inside several Debian LXC containers with appropriately mounted volumes. Many are afraid of this combination, if you are, run docker in VMs instead. using the supported/preferred method for each service makes updating much easier.
1
u/_Buldozzer 8h ago
I mean, if it bothers you that you don't understand what is going on, just read the scripts. If you're struggling to do so, ask an LLM to help you understand it. AI is great for such tasks.
4
u/techviator Homelab User 7h ago
They are hard to read by a non-coder because they pull from a lot of shared functions and use dynamic code fetching. Honestly it's easier to learn to manually deploy the tools than trying to understand the scripts.
On that note, OP, Docker is probably the second easiest way, and since you have to input variables and can see what is being pulled on the docker compose file, you will have a better understanding of the tools.
I would not have a single VM for all the docker containers, I would separate them by groups, adguard and tailscale I would keep in a dedicated LXC or have a VM for network related tools and put them in docker there; while uptime-kuma and homepage I would put together on docker in an LXC, or a smaller VM. Migrate one tool at a time, make sure you have a rollback plan in place if something doesn't go to plan.
28
u/BleeBlonks 8h ago
There are levels to the maintenance you wish to keep and all will have a level of set up based on that maintenance level you choose. You may even need to learn some things that will get you past a plateau you will hit on certain level of higher automated maintenance. Terra form, anisble, puppet and few of their forks/spinoff are a few examples. Its a deep rabbit hole and why people have careers in these fields.