Selfhosted

I see containers as having a couple of advantages:

1. Separation of dependencies - while not as big of issue as it used to be, just knowing that you won't end up with the requirements for one application conflicting with another is one less issue to worry about. Additionally, you can do anything you want to one container, without having an effect on another container. You don't get stuck wanting to reboot or revert the system, but not wanting to break a different running service.
2. Portability - Eventually, you are going to replace the OS of that VM (at least, you should). Moving a container to a new OS is dead simple. Re-installing an application on a new OS, moving data and configs can be anywhere from easy to a pain in the arse, depending on the software.
3. Easier fall back - Have you ever upgraded an application and had everything go to shit? In my years working as a sysadmin, I lost way too many evenings to this sort of bullshit. And while VM snapshots should make reverting easy, sometimes it just didn't work out that way. Containers force enough separation of applications that you can do just about anything to one container and not effect others.
4. Less dependency on a single install - Have you ever had a system just get FUBAR, and after a few hours of digging the answer seems to be, just format the drive and start over? Maybe you tried some weird application out and the uninstall wasn't really clean. By having all that crap happen in containers, you can isolate the damage. Nuke the container, nuke the image, and the base OS is still clean.
5. Easier version testing - Want to try out upgrading to version 2 of an application, but worried that it may not be fully baked yet or the new configs may take a while to get right? Do it off in a separate container on a copy of the data. You can do this with VMs and snapshots; but, I find containers to be less overhead.

That all said, if an application does not have an official container image, the added complexity of creating and maintaining your own image can be a significant downside. One of my use cases for containers is running game servers (e.g. Valheim). There isn't an official image; so, I had to roll my own. The effort to set this up isn't zero and, when trying to sort out an image for a new game, it does take me a while before I can start playing. And those images need to be updated when a new version of the game releases. Technically, you can update a running container in a lot of cases; but, I usually end up rebuilding it at some point anyway.

I'd also note that, careful use of VMs and snapshots can replicate or mitigate most of the advantages I listed. I've done both (decade and a half as a sysadmin). But, part of that "careful use" usually meant spinning up a new VM for each application. Putting multiple applications on the same OS install was usually asking for trouble. Eventually, one of the applications would get borked and having the flexibility to just nuke the whole install saved a lot of time and effort. Going with containers removed the need to nuke the OS along with the application to get a similar effect.

At the end of the day, though. It's your box, you do what you are most comfortable with and want to support. If that's a monolithic install, then go for it. While I, or other might find containers a better answer for us, maybe it isn't for you.

Containers are just processes with flags. Those flags isolate the process's filesystem, memory [1], etc.

The advantages of containers is that the software dependencies can be unique per container and not conflict with others. There are no significant disadvantages.

Without containers, if software A has the same dependency as software B but need different versions of that dependency, you'll have issues.

[1] These all depend on how the containers are configured. These are not hard isolation but better than just running on the bare OS.

Just to throw another option in: Lxc are containers too. And they are the other major option proxmox comes with.

It feels more like bare metal installations, but are more lightweight and share there ressources they do not use.

I never got why having Proxmox and one VM with several docker containers except I absolutly don't want to deal with installations at all.

On the other hands I wanted to learn about linux and the basics of handling proxmox.

Cons of containers are slightly worse disk and memory consumption.

Pros:

• ease of installation
• declarative configuration
• security
• dependency management is solved

Stick with the containers

I've been asking myself the same question for a while. The container inside a VM is my setup too. It feels like the container in the VM in the OS is a bit of an onion approach which has pros and cons. If u are on low powered hardware, I suspect having too many onion layers just eat up the little resources you have. On the other hand, as Scott@lem.free.as suggests, it easier to run a system, update and generally maintain. It would be good to have other opinion on this. Note that not all those that have a home lab have good powered labs. I'm still using two T110's (32GB ECC ram) that are now quite dated but are sufficient for my uses. They have Truenas scale installed and one VM running 6 containers. It's not fast, but its realiable.

Personally, I always like to use containers when possible. Keep in mind that unlike virts, containers have very minimal overhead. So there really is no practical cost to using them, and they provide better (though not perfect) security and some amount of sandboxing for every application.

Containers mean that you never have to worry about whether your VM is running the right versions of certain libraries. You never have to be afraid of breaking your setup by running a software update. They're simpler, more robust and more reliable. There are almost no practical arguments against using them.

And if you're running multiple services the advantages only multiply because now you no longer have to worry about running a bespoke environment for each service just to avoid conflicts.