tl;dr: Proxmox or bare metal? Containers yes/no? What is your use case?

I used a Dell R710 when I first started self-hosting, it ran ESXi with one VM for each service I wanted. Restarting the server required me to first shutdown each VM in order and then the whole host. When setting up a new service to host I had to create a new VM (allocate RAM, disk etc), install the OS (I ran Debian) and then follow instructions for how to setup the service. This mostly was not a problem but one software I never managed to get working was Apache Guacamole.

Nowadays I have a Dell Optiplex I salvaged for parts, got a new case and all my HDDs from my R710. Because it has much less RAM and an old Intel i5 (6th or 7th generation), I decided to get into Docker. With Docker containers you write your compose file and it will just work. No more need to dig through documentation for which version of a dependency to use, how to handle if two services on the same host need different versions (this was part of the reason for one VM/service). With Docker, I can try out a software in seconds and have it configured to my liking in minutes.

Today I have NixOS (bare metal) and it comes with Podman which uses systemd. Hence restarting my OS (albeit not that often, almost never unless I mess up my config) is a no-brainer because Podman via systemd will manage everything. Adding, stopping or removing containers in general is easy. I have a script running as a service which will stop a container, create a BTRFS subvolume snapshot, start the service again and start borg backup to backup from the snapshot.

For me using Proxmox would just an extra layer of complexity I don't need. I only have one server and I am the only user.

Questions:

  • Do you use Proxmox instead of a bare metal installation?
  • Do you use containers or do you install manually?
  • What is you use case that requires your setup the way it is?

all 72 comments

sorted by: hot top controversial new old
[–] 38 points 1 month ago* (3 children)

I used to be bare metal Debian, but I moved to ProxMox for a few reasons.

  1. Backup and restore is a breeze, and the UI makes things human friendly.
  2. It makes it easier to separate my wiki notes in an LXC so that I can still see them if I’m doing maintenance on my main server VM that requires restarts.
  3. There is essentially no noticeable performance reduction.

It works, it’s easy, and the simplicity has saved my butt a few times. I don’t think I’ll be switching, and I’d recommend it to anyone running a homelab. I still use docker to manage most of my services inside a VM.

  • source
  • hideshow 3 child comments
  • [–] 1 point 1 month ago (1 child)

    Why not put your wiki notes on your admin machine (whatever machine you use to manage the proxmox server)?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 month ago

    I could, but it’s more convenient for me to have it served up by an LXC container on the server. I’m usually interacting with things on a laptop or a phone, so it’s just easy being able to have a tab open with my wiki served through Tailscale, and ProxMox makes sure it stays backed up to an external drive and the cloud so I don’t lose anything.

    The few times I’ve had a critical error with ProxMox, it’s been super simple to do a fresh install and just restore my daily backup.

    There are many ways it could be done, but this way has been mine, and it’s worked for me.

  • source
  • parent
  • [–] 29 points 1 month ago (2 children)

    I use both. The main benefit of proxmox is having VM snapshots/daily backups, if you mess up, just restore the whole thing. You also have stricter isolation, e.g. put public facing containers in one VM and local only stuff in another.

    Also has high availability if you have multiple nodes but that can be achieved with container orchestration as well.

  • source
  • hideshow 2 child comments
  • [–] 5 points 1 month ago* (last edited 1 month ago) (1 child)

    Couldnt you just make daily snapshots on baremetal? Like most configs will support a ZFS pool.

    All my stuff is just configs anyway, so my backup is a Git commit. Lighter than a full snapshot. My server can be restarted with like 50mbs of information.

    Docker images are images so disposable. All my files and databases are on my NAS which is a ZFS pool mirrored and with a weekly backup to a secondary NAS also mirrored. Plus I have an offsite cloud backup of everything. There isnt really anything on my server that matters other than some configs, scripts and ymls. Which by commiting to my Gitea, are all on my NAS with the rest of my data.

    I still feel like Proxmox just invites you to tinker and fiddle with stuff that should be set and forget. Or overcomplexify your setup with too many moving parts.

    For public stuff I just use a VPS. Better internet connection than at home, high availability and DDOS protection. Otherwise, an LXC with good firewall rules and a well configured reverse proxy should be sufficient.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 month ago

    Sure, you can probably build something similar with zfs snapshots, but it'll likely not be as convenient. Have a VM? Create daily snapshots. Break something and can't figure it out? Just reset to the last backup to a complete working state.

    Personally, I have the containers' mounts in the VMs (ergo on the nodes' disks) and just using the NAS for the backups. Even if both Proxmox nodes catch fire I can just import the snapshot to a new one and have a working VM in the same state again. That's a whole different level from re-cloning all the compose stacks, mount NFS shares etc. It's the ease of use.

  • source
  • parent
  • [–] 17 points 1 month ago

    I like the flexibility that proxmox provides me. I do this as a hobby and I'm self taught. I can try a bunch of things and if I mess up I can start over without much hassle.

  • source
  • [–] 28 points 1 month ago*

    It's not an either-or scenario. Running services in Docker/Podman is great and makes a lot of sense, as you've found. But there's no reason the OS running those Docker containers can't be a VM on a hypervisor like Proxmox. Then you get the simplicity of Docker, in addition to the isolation and segmentation (network and process) provided by VMs, and snapshot-based incremental backups from PBS. It's the best of both worlds. You wouldn't have a VM per service like you ran before, instead you'd have a VM per group of related services with common networking and security requirements. For example, all of your publicly exposed services can run in Docker in their own isolated VM that's walled off from the rest of your network, while your internal-only services also run in Docker, but on a separate VM on your internal network.

  • source
  • [–] 10 points 1 month ago

    Proxmox running LXC's and VM's, all of them also have docker installed

  • source
  • [–] 9 points 1 month ago

    Generally speaking:

    • just want it to work with minimal effort: containers
    • need very custom things, or very high efficiency: bare metal
    • need high security, emulating bare metal, or like to do extra IT work: virtualization

    Generally, these days, containers win 99% of the time as the best home lab backbone.

  • source
  • [–] 15 points 1 month ago (3 children)

    I'll die on this hill.

    Containers run on "bare metal" in the same way that other processes on your system run.

  • source
  • hideshow 3 child comments
  • [–] 7 points 1 month ago* (last edited 1 month ago)

    I moved from VMware Fusion after a hardware failure and migrated to Proxmox. I use VMs to isolate client information and to test and use different OS versions and distros.

    I have a VM that runs Docker and connect to it via SSH for running applications I don't want to install on my main workstation.

    My main workstation is also a VM.

    I came from bare metal Linux for years and found that I spent too much time recompiling kernels to make it work with my hardware.

    Now that everything is a VM, changing underlying hardware, and even hypervisor is trivial.

    If VMware hadn't been bought by Broadcom and allowed me to virtualise x86 on Apple Silicon, I'd still be running VMware Fusion. UTM by the way is completely unreliable .. I really tried.

    As it is, I'm running Proxmox on AMD.

    in summary, Proxmox allows me to build what I need when I need it virtually and it's running on a standard Debian host.

    Edit: #$#__# autocorrect (unreadable -> unreliable)

  • source
  • [–] 7 points 1 month ago

    You should be using them depending on your needs. There's a difference between app containers (single app per container), system containers (multiple apps in the same container) and VMs (OS + whatever, virtualized rather than containerized).

    You probably need app containers most of the time so docker or podman is a good fit. But sometimes you might feel more confortable with another level of abstraction. Tools like Proxmox or Incus make it easy to manage "system"-level abstractions like system containers (with LXC) or VMs (with KVM) and give you a unified management approach.

    You don't have to give up app containers either. You can run docker or podman inside an LXC system container and have the best of both worlds.

    Deciding when to take advantage of the system abstraction is the hard part. A simple rule of thumb is to do it when you'd like to manage the "machine" that holds the stack in a way that's different from the host. Maybe you want to run a different Linux distro; maybe it's the same distro as the host but you want to organize it differently; maybe you need to run a non-Linux OS.

  • source
  • [–] 6 points 1 month ago

    Check out the krun runtime for podman, if you want stronger container isolation from the host. It creates a small VM for each container. Gpu passthrough on linux is limited though.

  • source
  • Having to manually start and stop your VMs is very atypical, proxmox can absolutely handle that itself

  • source
  • [–] 5 points 1 month ago (4 children)

    I'm running Docker inside a Debian VM on Proxmox and I forgot why. Next time I'd just run Docker on Debian.

  • source
  • hideshow 4 child comments
  • [–] 2 points 1 month ago* (last edited 1 month ago) (3 children)

    I started with docker desktop on windows for a year. Got tired of resources redlining because windows is greedy. Tried proxmox and just couldn't get past the setup (don't remember which part). Anyway, running headless Debian with docker is working really well for about 2 months now. Between cockpit and my codeserver container I can get most anything done through gui. I even installed comai llm on my mint desktop machine to help me with commands.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 1 month ago (2 children)

    Sounds great. I can recommend Dockhand for monitoring and managing Docker containers.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 1 month ago

    @captcha_incorrect Currently I'm running my personal services similar to you using Podman Quadlets and I really like it.I have also a testing installation of Proxmox on another system, but I'm also not so clear, if it would be a good way for my purposes.

  • source
  • [–] 5 points 1 month ago

    Podman sounds like a podcast about other podcasts

  • source
  • [–] 9 points 1 month ago (2 children)

    Security is a big reason to use VMs. Containers share the kernel with the host. That means that any of the kernel vulnerabilities from this year (like DirtyFrag and CopyFail) could have been used to compromise your host. Once the host is compromised, the only way to be safe is to literally buy a new machine. Seriously. Viruses can bury deep and even infect the motherboard firmware to persist indefinitely.

    Kernel vulnerabilities are frequent enough that I find VMs worth it. I still use containers in my VMs though.

  • source
  • hideshow 2 child comments
  • [–] 6 points 1 month ago (1 child)

    Do you have any sources on motherboard firmware viruses? I'm curious to know more about them

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 month ago*

    Proxmox is a hypervisor, while docker is containerization.

    Comparing them is like comparing an apple to a glass of milk. They have different use cases.

    I run multiple VMs specifically for Docker services. I run other VMs for other things. And LXCs for applications where containerization makes sense but I don't want to use Docker.

  • source
  • [–] 4 points 1 month ago

    I have a mix...

    I have a home built NAS running on Arch with local installation of Immich (ie not a container)

    I also have a low power, passively cooed box with Proxmox installed to run VMs for Home Assistant, ansible, uptime kuma, smokeping, etc.

    I only intended to run Proxmox to test it out (my Home Assistant was running on a Pi3 and getting too slow for Voice), as I'd been using ESXi for years at work.

    I now want to migrate to Arch with Incus and move those VMs across, but as I currently only have the 1 host and hardware's expensive, it'll stay that way for a while...

    (Bonus: I have a few RasPi Zeros scattered around the house too running various things bare metal)

  • source
  • [–] 3 points 1 month ago

    I moved away from proxmox about 3 years ago to incus, primarily because Proxmox has a lot going on that I don't need, but also incus is much more amenable to configuration with ansible. Also, and maybe this has changed recently, but passing through PCI devices to incus is much easier.

  • source
  • [–] [B] 3 points 1 month ago* (last edited 1 month ago)

    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
    ESXi VMWare virtual machine hypervisor
    Git Popular version control system, primarily for code
    LXC Linux Containers
    NAS Network-Attached Storage
    NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency
    SSH Secure Shell for remote terminal access
    VPN Virtual Private Network
    VPS Virtual Private Server (opposed to shared hosting)
    ZFS Solaris/Linux filesystem focusing on data integrity

    [Thread #111 for this comm, first seen 24th Sep 2026, 14:20] [FAQ] [Full list] [Contact] [Source code]

  • source
  • [–] 3 points 1 month ago

    Proxmox with LXC’s and a few VM’s.
    Often with Portainer as well.

    It’s just nice to use and easy to automate backups.

    I used to run barebone on Debian, but I accepted that I’m not good enough in the terminal and to used to graphical solutions to go back.

  • source
  • [–] 3 points 1 month ago
    • No
    • Manual only
    • Because I'm old and crusty, and always rawdogged service setups. I'm sure containers are nice and all, I just never got around to learning them properly.
  • source
  • [–] 5 points 1 month ago

    I used to run bare metal monolith container host and it worked pretty well but eventually network configurations started tripping over each other and causing real issues (complicated by me running rootless Podman and wanting to run K3s cluster etc). I wanted to run Proxmox native containers but it turns out they run full root therefore breakout in one container means full host access, so now I run VMs as container hosts.

  • source
  • [–] 4 points 1 month ago

    I use Proxmox as a VDI server. I understand that this isn't homelab territory, but selfhosted VDIs have proven exponentially more reliable and easier to manage than cloud based ones (after the initial PitA setup). Flawless copy/paste, screen resize, and most importantly, file transfers. When you connect to 12 different clients, each with a different set of security requirements, system hardening, monitoring, and VPN access, being able to console amd fully interact with a sandboxed desktop becomes priceless.

  • source
  • [–] 2 points 1 month ago

    When I got started I saw a lot of suggestions for proxmox. For me, it was an extra layer I didn't feel like I needed. I installed Open Media Vault (just Debian with a web interface) and I have my docker containers for running the apps and eventually setup VMs for various other things. Staring out, Docker was a bit of a headache but now that I've got practice with it docker compose is fairly simple.

    I appreciate that these days there are a bunch of really good tools out there and options.

  • source
  • [–] 2 points 1 month ago

    I use a different 'type 1' hypervisor, create a small handful of VMs and then have a mess of containers inside containers in a couple of those. There's a distinct VM for email since that has so many special requirements that it was just easier, one lxc/incus container host for admin tools, one for user apps, one for piefed because all these fediverse apps are so busy with the constant exchanges it kind of needs its own host to not affect others...

    Why is more a case of ease of administration frankly. Pretty much everything gets auto patched and backed up and it's easy to put up a new service or restore things if I hose something up.

    The structure though has been a years long evolution that started out as 'I just want a NAS to share files' which then needed a frontend to make it more user friendly, and another app to play videos, and why not organize different file types rather than just dump em in a folder...

  • source
  • [–] 2 points 1 month ago*

    I like running docker containers inside of specific unprivileged LXCs on my proxmox host. Why? Because it works and I'm not an expert.

    I can spin up a new LXC and test things without fucking up my entire server. It allows me the flexibility to try new services or attempt things that I'd otherwise be too timid to try on the chance it fucks up my entire system and I have to spend two and half weekends trying to get back to where I was when things just worked.

  • source
  • [–] 2 points 1 month ago

    Just about everything is Proxmox for me, though a few things are just Debian.

    I use LXCs, in general I don't like Docker so I avoid it in most cases. I have a couple VMs for it where I may spin something up to test, but if its around long-term it gets moved to an LXC. Usually because I prefer a bit more control on setup, and find it more manageable than having a bunch of mounts for everything. It also keeps things arranged in a way I prefer, gives me a single interface to access what I want, and makes backup more straightforward.

    Whether I want a whole VM or just to run a single app as a service, I only have to go to one spot to do it.

  • source
  • [–] 2 points 1 month ago

    I don't care much for proxmox but that's because I live in the terminal anyway and have a lot of experience administering Linux systems. So for me it's just an extra layer of complexity, the benefits don't really apply when my setup has IaC, most of my containers are in Podman rather than LXCs, my backups are automated with my own scripts and cronjobs, and I only run a couple of VMs. Also it makes encrypting the base system more difficult than it is with a standard distro

  • source
  • [–] 2 points 1 month ago

    I run podman in proxmox vms

  • source
  • Install incus on your OS of choice to manage LXCs and VMs, it’s ideal!

    No need to chain yourself to an OS that is rolling on the free branch, get stability and control!

    As for LXCs vs Podman containers, seems it is preference of control. LXCs are little OSes you need to keep up to date, containers need to be rebuilt to keep up to date. (I think only Linuxserver images actually rebuild just for base OS updates, hopefully the reverse proxy and authentication images too)

    Podman brings some nice networking, read-only features, and user abstraction with it, I think that helps it push ahead.

    That said, LXCs are little OSes and that flexibility can be very useful. For instance, incus is able to make an LXC with a unique Mac from an Ethernet adapter - I haven’t cooked how to do that with Podman yet. So I run my DNS from there so it doesn’t mess with my server’s DNS port.

  • source
  • [–] 2 points 1 month ago

    Proxmox with VMs running Docker using Cosmos.

    Pros: backups, easy VM management, easy disk management.

  • source
  • [–] 2 points 1 month ago

    Proxmox exclusively with unprivileged LXCs, which themselves host other docker containers/stacks managed with Dockhand (a more modern alternative to both Portainer and Dockge). I have a very tiny low power machine so I have to be kind with my resources, therefore no VMs. But LXCs are simpler anyway. I can easily pass devices like /dev/tun for tailscale and i forget the name of the iGPU for accelerated workloads (for Immich, Nextcloud).

    Reasoning: with containers it's easy to make mistakes without dire consequences (just docker compose down -v and start over). The LXCs are easy to back up and restore. They hold internal running state of whatever docker containers I run in them.

    Pro tip: don't map host paths using the UI (mp0 etc), use lxc.mount instead. This will let you continue to have snapshots of your LXCs whereas the other approach makes your LXC incompatible with snapshots.

    Good luck!

  • source
  • Proxmox with Kubernetes and containerization can allow you more easily manage your services and to have less downtime. But, as you said, it adds another layer. Is it worth the time to set it up? Over a long period, yes.

    As a DevOps/Developer/Sysadmin, I'd probably use it if I set up a lot of services. If I just have some kind of file share thing, probably not.

  • source
  • [–] 2 points 1 month ago* (last edited 1 month ago)

    • Yes, but I also use podman on another machine.

    • Proxmox server hosts LXC's and a few VMs.

    • Proxmox makes it extremely easy to run and manage containerised workloads. Set it up in a flash and it runs happily, no intervention necessary. Podman containers on the other hand can be tricky to set up, but I prefer the controls I have on that machine. If it needs to be secure I Podman it, if not I just stick it in a Proxmox LXC.

  • source
  • [–] 1 point 1 month ago (9 children)

    Docker has its uses, but it has gone to far.

    I already have a webserver with Apache, mariadb and everything. Why does your PHP based website only come as a docker solution? Fuck you.

    When you go all in with docker, it quickly becomes a mess with rando NICs and containers named "random 32 character string" and dependencies up the wazoo. Ending up running ancient packages because the developer refuses to apt upgrade their shit.

    Proxmox or any other hypervisor platform gives you control. Whereas you have to take it for docker and youre still at the mercy or the developers to keep your shit secure.

  • source
  • hideshow 9 child comments
  • [–] 7 points 1 month ago (2 children)

    Years ago I'd have one PHP app that required version X of PHP and another that required version Y and my distro often only had one of them (or you couldn't install both simultaneously), so I'd have to either compile myself (or later use a 3rd party repo). All solvable of course, but then throw in MySQL version requirements and PHP extensions and it's just extra crap that containers just take care of for you. I've had this kind of inter app requirements conflicts with stuff other than PHP, but I've had by far more of it with PHP. For a while I used FreeBSD jails to help, but jails was kind of a pain. I enthusiastically embraced docker for PHP stuff early on.

    A benefit for application developers, particularly PHP is there's a lot of differences between distros and how people install and configure PHP. Even like which PHP extensions are available and their settings. Other languages things tend to be more consistent at the system level and customizations are app are usually application level (contrast with PHP extensions and system level configurations). It really helps reduce support issues due to distro/user differences if a developer just provides a working dockerfile as a reference implementation and in my experience this is far more likely with PHP than other languages. I realize this is mostly applicable outside of PHP, but I actually personally see more benefit with PHP based on my past experiences.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 month ago (1 child)

    Why not have the option for both?

    I dont see how this is a defense for jamming everything in to a container.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 month ago
    1. Why not both? Packaging multiple releases, documenting, and support is lessened with a single release. Officially supporting more ways to install is extra time and effort that is considerably worse with PHP than applications written in most (maybe all?) other popular languages due to the variety of ways people can configure PHP and how the web server executes it is huge and trying to support all of that is considerable. Even if you just narrow down to a single http server, there's a lot of variations just how the http server executes the scripts and that's ignoring the PHP/PHP extension level differences. I can't think of any popular languages that are worse or even in the same ballpark as PHP on execution environment inconsistencies.

    2. The existence of the docker release doesn't prevent you from running it outside of docker and the Dockerfile/image serves as a reference implementation. It provides you the exact steps and working configuration to deploy it outside of docker.

    Consider a PHP application with install instructions, you follow them and it doesn't work due to some non obvious configuration difference. With the docker image you have a reference of what should work and can use that to narrow down what is different between your PHP install/configuration and a working system.

    If you've not run in to these kinds of situations, consider yourself lucky. It was a nightmare back in early 7.x releases and older.

  • source
  • parent
  • [–] 5 points 1 month ago (2 children)

    all the problems you expressed with docker aren't real problems.

    I think you may not like it because you don't know how to use it.

    don't like how often a maintainer updates their images? build your own.

    don't like having multiple bridge interfaces on your host? configure and manage networks within docker and assign them to your containers.

    don't like having dozens of containers with random names? use docker compose. bonus, you can set up networking with it even easier.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 month ago (2 children)

    Ending up running ancient packages because the developer refuses to apt upgrade their shit.

    Tell me you never really had to deal with dependency hell without telling me. That's literally the main problem docker solves.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 month ago* (1 child)

    I have had to deal with dependency hells plenty, i am a Debian user after all.

    But with that argument you're now just running outdated shit in a container. Not a great pro-docker argument tbh.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 month ago

    @SirLeToet @3abas It's not that I deny Docker's various pecadilloes, butMy servers run ZFS on platters separate from the boot disk(s). My services (self-hosted or whatever) mostly run in Docker containers with compose files. What I get from that, is that I can nuke my server anytime I like, re-import the zpool, go to my docker directory and get everything spinning back up in minutes. Nobody who has to deal with more than one server doesn't use some form of this virtualization, be it VMs, docker or some other Container solution.

  • source
  • parent
  • [–] 1 point 1 month ago

    I run Proxmox and have all my services running as docker containers on a VM. Snapshotting is amazing

  • source
  • [–] 1 point 1 month ago

    Been using proxmox for 10+years. It is rock solid. Cluster of 3 automatically handles VM movement. Plenty of options for snaps, backups, etc. Tons of support out there too

  • source
  • [–] 1 point 1 month ago

    There are different reasons to run different things. Some apps are not able to be run as containers, or don't make sense to run containerized.

    VMs offer better isolation between systems, which is important for high-security applications.

    Traditional Hypervisors also allow you to easily run fleets of completely different OSes on the same hardware, which you can't do with containers.

    On the other hand, if you want/need high scalability, extremely efficient resource usage, and you don't need to run radically different OS environments simultaneously, containers, especially Docker containers or Podman containers are a great choice.

    Incus containers are a great middle ground that I'm a fan of more than Docker/podman containers or traditional VMs. They are system containers, vs application containers like Docker/Podman.

    That means they are actually full-fledged Linux distros by default, but are still much smaller than a traditional VM.

    Also, for any of these solutions, if you're constantly doing admin tasks manually, you're doing it wrong. All modern platforms have APIs or other ways to interact with them via code.

    For my own setup, I have everything. My main server runs XCP-ng for the hypervisor, and I have several traditional VMs on it, including my primary NAS. I also run a virtual Incus host that I have my Minecraft server running in, and some random other system containers. I have a Docker host VM, but I don't really use it.

    I also have my home media server which is a standalone system running TrueNAS on bare metal with Tailscale and Jellyfin running as Docker containers within TrueNAS.

    My setup is messy because it has been built slowly over several years, and I don't have enough time or energy to rip it all down and put it back together in a more optimal way.

  • source
  • [–] 1 point 1 month ago*

    Ram is expensive... so all my 24x7 things are containers (docker compose on Alpine Linux) or FreeBSD jails.

  • source
  • [–] 1 point 1 month ago*

    I use VMs for OS isolated and hardware isolation. I run containers on top of OSs for apps.

    That said I use Harvester so I can run containers on bare metal AND VMs as containers.

    Even on one bare metal I do this, so I can spin up a test VM of harvester to confirm configs. If you one node is super beefy a neat trick is to have VMs running a cluster so you can have a kind of high availability even if your infra is a single point of failure.

  • source
  • [–] 0 points 1 month ago* (last edited 1 month ago) (3 children)

    because sometimes i need a vm (home assisstant has more features thsn home assisstant container), sometimes a container (i mostly use lxc).

    its not really an extra lauer because proxmox is an os.you use nixos i use proxmox. everything is out of the box. proxmox has comminntiu scripts to run everything and set them up. there is an i stall script for about everything https://community-scripts.org/

    sure podman has similar setup but i also need vms and they are all mamaged in one place

    EDIT: you can read the script, its text

  • source
  • hideshow 3 child comments
  • [–] 6 points 1 month ago (2 children)

    so want to install radarr? Paste this totally not sketchy bash script into your terminal and execute it as root!!

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 1 month ago (1 child)

    ProxmoxVE helper scripts have been around for quite a while and are pretty easy to read, as well as being pretty well supported in the community. You can just go to the GitHub page and read them. I've used some of their scripts before by downloading them, customizing the scripts to my needs, and hosting it on a local web server inside my network. Now I can run one command and I'll have a new debian container on my host with ssh keys and everything.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 month ago

    While I agree with you that they're well seasoned and established I disagree a lot with them being easy to read. They have a lot of sub-scripts that they include willy-nilly over multiple levels.

    Another thing I dislike about them is basically the same as with docker, that they all include everything in it. Like every container wants his own mariadb/postgres/whatever. It should be at least an option to use existing containers, I don't need to run 5 psql servers... (I know that it had advantages too having everything separate but ehh). And then switching the software back to using the existing psql is more work then just not using the scripts at all...

  • source
  • parent
  • [–] 0 points 1 month ago* (last edited 1 month ago) (4 children)

    That's apples and oranges.

    Anyway, both podman and docker are extremely insecure. Safer to download signed ISOs to run in proxmox

  • source
  • hideshow 4 child comments
  • [–] 5 points 1 month ago* (3 children)

    trusting an oci repository is the same as trusting a distro repository, if its a dodgey unknown you got from god knows where and you cant verify, dont use it

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 1 month ago (2 children)

    Nope. You don't need to trust a distro Repo's publishing infrastructure because the packages are cryptographically signed.

    Whereas the oci repo had a ton of vectors for delivering maliciously modified code because they include image layers that are totally unsigned.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 month ago (1 child)

    oci repositories support signing artifacts, container trust policies are a thing. bootc repos are both signed and are distro repos, ostree Fedora and ublue are using it

    Just because quay.io or hub.docker can be accessed without signatures or trust doesn't mean there aren't repos out there using it.

  • source
  • parent
  • hideshow 1 child comment
  • My point is that they support unsigned packages.

    It's not possible to download a package on apt without signatures, by default. All packages are signed.

    We tell people to use Signal, not Telegram, because the later allows unencrypted messaged by default.

    I don't know of any common oci repos that have many signed packages. If you make it your policy to require signatures, there's almost no images you'll be able to download because almost none are signed.

    Whereas it's 100% of packages in Debian's apt that are signed.

  • source
  • parent