What to people use and recommend for this? I’ve read a bit about portainer, but I’m still learning - and don’t know what the best solutions are.
Today I have a handful of selfhosted services running on my home machine - mostly installed directly, but a couple running as docker containers. As the scale of my selfhosting has grown, I’ve realized that things would be a lot easier to manage if each service was run as its own container, so that installed services are isolated.
The solution I’m looking for would make it easy (possibly a web UI) for me to monitor, modify, update, and remove containerized services, including networking and storage.
Edit: Also I would only want a FOSS solution.
You must log in or register to comment.
I recently moved from docker compose to podman quadlets. Took a bit of effort, but fully foss, and for me it’s set and forget. Have about 30 containers across about 12 services. Have them set to auto update and it all runs through systemd.
Podman pods (or quadlets) managed by ansible.
try NixOS
all your containers and other services will be managed through one re-usable file
if your server is >= 8GB then proxmox gives a nice interface builtin. i use it to make nixos lxc containers in which i run my containers. which does actually make sense
NixOS modules are great when they
- Exist.
- Are maintained.
If either of these points aren’t fulfilled you will have to spend a lot of time learning the Nix language and then creating and maintaining the modules yourself, which is easier said than done for many services. I eventually moved on to Podman quadlets, and shortly after that I moved from NixOS to Fedora Kinoite.
I personally like dockge, it’s simple and lightweight and I like the fact that the webui has a good phone interface.
Dockhe is awesome. You can edit the docker-compose files from its interface and it makes managing containers very easy.
I’d absolutely recommend Kubernetes (k3s/rke2) or podman quadlets. Quadlets are a lot easier to get started with, but are still very flexible.
I’d recommend against using portainer. I tried it quite recently and I did not like it at all. A lot of features are paywalled, and was overall just a frustrating experience. I’ve heard it was a lot better some years ago.
I’ll second podman quadlets. Good security, full integration with systemd, pods allow applications to easily share a namespace, and you can manage graphically through Cockpit if you really want to.
systemd integration would be nice
Dockhand is great. I haven’t touched Portainer ever since.
https://github.com/Finsys/dockhandLooks nice but what kind of license is that?
That looks pretty good. Looks like Portainer is getting replaced this weekend.
Thanks, what have you liked about switching to this from portainer?
I just recently switched from portainer to dockhand and I really like it. The UI is great and the setup and config wasn’t too complicated. I like that I can put both of my servers into one instance and can update all of my containers from dockhand vs manually. The other thing I like is being able to view the logs for my containers. Idk if it’s a me thing, but whenever I would try to view logs in portainer I would never be able to scroll up as it would update and send me back to the bottom. Again, I could’ve just been doing something wrong, but it always bothered me and I don’t have that issue with dockhand.
Might take a little bit of effort to do a conversion if you’re locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.
- Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
- Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.
Other than that, the more usable solutions I’ve tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.
Im not locked into docker, but it’s what I have experience with so far, and a lot of services seem to have docker installation as a default option.
Do you think those things make it difficult to switch to podman? What are the differences?
Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn’t recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you’re best to take the compose file and write it out to Quadlet unit(s).
Other differences not mentioned can include:
- Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as
localhost,127.0.0.1, or::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures. - Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you’re not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
- Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
- Podman by default won’t shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the
docker.io/prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor. - Podman can optionally let you auto-update containers based on the release tag specified for the container.
- Because of Podman’s integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).
- Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as
Docker’s main advantage is just being more well known and hence more supported as a default option.
Even then, I feel that this availability of docker compose files is an illusion, due to their verbosity and limitations inherent to docker. Less granular control of permissions, clunkiness in updating images, and multi container stacks feeling like an afterthought.
In pretty much all other ways podman feels superior. Cockpit provides a basic web gui, but quadlets are the main draw. Way easier to configure, explicitly designed for multi containers, and updating all images is a single command.
Roughly, the different ecosystems from least to most complex are:
Docker/Portainer -> Podman/Cockpit/Quadlets -> Kubernetes
You can use the same containers with Podman, but docker-compose is not recommended with Podman and you rather use Quadlets which integrate nicely with Systemd.
If you want robust (and a ton to learn) go with k3s for a lightweight Kubernetes deployment and FluxCD.
If you want simpler go with docker-compose and doco-cd.
With a GitOps workflow you define it all in files in a bit repo then the server automatically deploys and updates. IMHO its much easier to maintain long term than click ops.
Docker Compose and CLI.
Indeed, I’d agree, it is the way I do it
As a tinkerer, I have tried Portainer a couple of times, and another similar thing, but I end up never looking at them, and revert to just jumping into the command line. A bonus of this approach is keeping a copy of all my compose files in a repo.
If OP is being drawn to this because they want to know everything’s running, what they’re really looking for is monitoring - probably Uptime Kuma.
This is the way I figured I’d go down at first, but I’m also curious if there’s a popular solution I could manage remotely in a browser without having to ssh, for example
Dockge - https://github.com/louislam/dockge
Docker compose with webui and upgrade button.
Thanks, I’ll look into this
I was using CLI exclusively for a year or so, but recently added DockMon and it’s helped with updates and at-a-glance management.
Kubernetes. For a homelab, the stripped-down k3s is fantastic and surprisingly easy to get going.
Once you’ve got Kubernetes set up, you can lean on all the many tools already out there for things like deploying complex projects (Helm) and monitoring (Prometheus/Grafana). OpenLens is a nice piece of software you can use to monitor and control your cluster too, as is k9s.
What do you use for repeatable recovery and deployment of systems?
I’ve looked at ArgoCD and FlexCD. ArgoCD was too flaky. When I made changes to helm files it would often fail to deploy them and the UI often wouldn’t really show the detailed errors from things like helm syntax errors, so it was a pain to troubleshoot.
FlexCD was just really a pain to configure in the first-place and I didn’t want to learn kustomize when I already have helm charts.
And neither really supported staged deployments or dealt with dependant services well. So I couldn’t get it to deploy the infrastructure level helm charts like PostgreSQL before deploying the services that depend on it. Technically, with Kubernetes it shouldn’t matter about the order of deployment but in reality when ArgoCD would deploy the other stuff first and wait for it to come up and it never came up because the dependencies weren’t there, it caused it to choke a lot.
Just an example of the issues I’ve had. But I really want an easy way to make lots of small changes to charts and deploy them quickly as well as being able to quickly recover the cluster from backups if something catastrophic happens like a fire without having to manually deploy each chart. Just curious how others handle it or if it’s always manual deployment of charts via CLI only.
This is how I went and what I’d recommend. But that said, it’s a bit of a steep learning curve as not everything in the self hosted/home lab community comes with helm charts.
I personally have switched over to Komodo after using portainer for years. Never looking back, I love it. Works perfectly and can do GUI, compose files, and repos for docker. I also have multiple machines running stuff and it let’s me fiddle with everything in one UI.
Ooo that looks nice, I’m using portainer right now, how was the migration?
Honestly, not entirely certain I did it right, but it was super easy. I literally spun up Komodo, spun down Portainer without shutting any of the other containers/stacks down, then added the same stacks back through the GUI option into Komodo with the same exact compose/title/env options. It literally just recognized that the containers that were already running on my server were the correct ones and “added” them back to the stack in Komodo. I vaguely remember reading that there is a more “correct” way to do it, but I only read about it after the fact.
Cool! What makes you prefer this to portainer?
I like the fact that there isn’t a distinction between the community edition and the business edition. Its all the same thing for Komodo, whereas I felt like Portainer had a bunc hof random things locked away behind the “Business Edition” and that just rubbed me the wrong way. If I’m self hosting something, I feel like I should be able to access all portions of it.
The GUI is a little different but once you’re used to it, I feel like it makes more sense for the most part. It has a nice way to connect other machines, so I can monitor all of the different machines in my network that are hosting things. I also wanted to mess around with some of the automation features, but I haven’t had as much time to dick around with that as I would like. I also wanted to start doing stuff from a personal Forgejo, and it was super easy to integrate. (No idea how easy it is on Portainer, as I had already jumped ship at that point)
Portainer had a bunc hof random things locked away
Sounds like a Hassel
I edited my missing line break but I’m leaving this. Its too good.
There are nice friendly frontends for this, Yunohost or CasaOS spring to mind but might be too simplistic if you already are familiar with Docker.
