Portainer is changing to a mostly AI and kubernetes supported app.

all 52 comments

sorted by: hot top controversial new old
[–] 61 points 1 month ago (19 children)

Dropped portainer years ago. Managing some compose files isn't hard, and Dockhand is better for managing updates

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

    Portainer has worked well for me but it has so much that I don't need or use. It looks like Dockhand has a Home Assistant integration which is nice, so I'll check that out thanks for the rec.

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

    Another good option is Arcane. Its project structure gives you a good place to put bind mounts which you can edit the contents of in app (like configs and such). It's pretty handy. I am in the process of switching to it from komodo for all of my stacks

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

    Very happy when I migrated over to dockhand. Fits exactly my needs for a simplistic overview of all of my containers and their resources.

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

    How does it compare to dockage? I haven't used either.

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

    I completely forgot portainer was a thing and I've used compose files for a few years. If I try anything new a unified dashboard (for managing multiple hosts) would be cool.

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

    Definitely checkout dockhand. It gives a single dashboard for all your hosts. I primarily use it for updating containers and checking logs, but it does quite a bit more. You can even point it towards your compose files and it can edit them in with a GUI, but I haven't played with that yet.

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

    I used to use watchtower. But then it killed a few services that had pre-update instructions, and I learned my lesson.

    It just gives me a GUI to see when a service needs an update, and a button to perform it, then I just backup and read the update notes before I do it.

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

    Do you know if there's a way to pin to a version but have dockhand tell me if there is a new latest version tagged? Not having a clean rollback method is driving me nuts.

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

    Yeah, version tags work fine. All my containers come from compose, and it follows whatever tags I declared there.

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

    That sucks. It was one of the few GUIs that did a good job with most aspects of Docker Swarm. I knew it was heading in a shitty direction, but I was hoping something else would come along to fill the gap in the mean time.

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

    I dumped Portainer on my home server when they did the 'Fortnite' graphical rebranding. Now using Arcane to manage my servers and edge nodes. Very much enjoying the CVE scan tools and in-place image updating.

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

    My devs prefer Docker, and don’t want Kubernetes! We have a fix for that: Portainer-D2K. Portainer-D2K is a Docker translator for Kubernetes

    As someone who was using mostly podman and is now switching to kubernetes I can confidently say that the cli interface was not what was holding me back. Instead it was the sheer amount of setup and complexity kubernetes can bring into an environment. Kubernetes is great when you want most or all the features it offers, it is horrible if you want to deploy 3 containers for your application on one host.

    Oh well, not like I have to care, I wasn't interested in portainer to begin with.

  • source
  • hideshow 3 child comments
  • [–] 19 points 1 month ago

    Welp, no more portainer for me

  • source
  • [–] 11 points 1 month ago (1 child)

    I switched from Portainer to Komodo a while back. I like how everything is declarative. It almost has a Argo CD feel to it without needed kubernetes.

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

    Embarrassing

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

    Having read this whoke thread, i feel its time to drop Portainer. I find it useful to edit the stackfile and do updates, as well as cleaning old volumes and images. Seems like Arcane and Dockhand are the most popular substitutes. Is the migration from Portainer easy?

  • source
  • hideshow 3 child comments
  • [–] 8 points 1 month ago

    I just finished the migration to Dockhand. I never had to stop a single container.

    I copied out all the docker compose files portainer stored for the stacks:

    sudo rsync -a /var/lib/docker/volumes/portainer_data/_data/compose/ ~/stacks-backup/

    The bonus of doing it this way is permissions, and it also nabs the .env files if you've configured vars in the Stacks config (and not directly in the compose file)

    Because all the folders were just ID's, I renamed them:

    docker ps -a --format '{{.Label "com.docker.compose.project.working_dir"}}\t{{.Label "com.docker.compose.project"}}' | sort -u | while IFS=$'\t' read -r wd name; do id="${wd##*/}"; [ -n "$id" ] && [ -d ~/stacks-backup/"$id" ] && mv ~/stacks-backup/"$id" ~/stacks-backup/"$name"; done

    After that, I ran du -sh against both directories to ensure they match.

    Once the rename was done, I settled on moving all my stack configs to /opt/stacks, and added a folder for the compose file for dockhand, because dockhand can manage itself, unlike Portainer. Additionally, I made sure the /opt/stacks folder I moved those files to was mounted by Dockhand in the compose file.

    docker compose up -d in the dockhand dir, and then went to the UI.

    Configure the env how you want, and have it point at whatever your config was. I am running everything in Ubuntu server, so I just left the default Unix stuff set.

    From there, the Stacks UI in Dockhand listed everything, but it knew nothing really about them. Pick a low-impact stack, and open it. You should see a section on the left where you can browse to /opt/stacks, for example, and if you've renamed the folders, easily find the yaml. Once loaded, you should see the config on the left. On the right is where you can add your env vars. If you have a .env that moved over, there's a folder icon at the top you can use to navigate to it and pick it.

    I have 18 stacks. Start to finish was approx 1 hour. I have 14 volumes, and those are all present, including the association to the stack they belong to, and everything matches what I see in Portainer, which is still up and running alongside Dockhand.

    I hope this all helps you. Realistically, I don't know if you'll have an issue with volumes. All mine are managed via docker itself and not portainer, so there was nothing I needed to do there.

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

    This was obvious to anyone who's used it for any length of time. I'm just surprised the monetisation enshittification didn't win the race.

    The only thing I've used Portainer for in the last few years is to easily tidy up my old images.

    Sure, it's trivial on CLI, but why not. 😄 In short: nothing of value lost.

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

    Maybe it helps if you have a gigantic stack of containers, but I've honestly never seen the point of Portainer when I can just look at my compose file.

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

    Does your compose file in itself give you a nice, easily readable status display, analytics, metrics, logging, etc. interface?

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

    I set it up years ago when I still had Ubuntu desktop running on an old laptop. Just kept using it even after using and learning kubernetes at work on an enterprise scale. Also the automatic image checks, easy to check metrics, logs, and endpoints. I have 33 containers right now, it's just simple to see them all in one screen.

  • source
  • parent
  • [–] 11 points 1 month ago (7 children)

    Portainer was outdated 5 years ago, and it sucked at the job it did.

    I'ma stick with dockge and argocd

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

    I went from Dockge to Dockhand, though both are good. Dockge was my UI of choice for the last couple of years, so slim and simple. I tried Dockhand on a whim and the extra features won me over, without having a bazillion buttons and confusing UI.

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

    For a lot of my remote hosted services managed with compose, I've just been hand rolling the compose files and ssh'ing in.

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

    How do you detect outdated containers?

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

    Switching to Podman. Supposedly Cockpit has a gui for it.

  • source
  • [–] 4 points 1 month ago

    Phew. Dodged a bullet just by adhering to SLSA.

  • source
  • 29 comments in c/selfhosting@slrpnk.net view that post
    [–] 14 points 1 month ago (9 children)

    Since I posted that I have migrated to arcane.

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

    Portainer-ce is staying on 2.*. Will look into arcane

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

    why dance with asking Portainer pretty please to give you a license when there are multiple alternatives that are free and fully functional.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 1 month ago (4 children)

    I like Portainer Agent. And I got used to the Portainer UI. Are there any others that support distributed environments like Portainer + Agents?

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

    I had looked through the docs and didn't see anything to indicate that there are agents or equivalent. Can you point me to the right place?

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

    it means I moved to Arcane with zero features left behind

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

    As someone who has been OOTL regarding self-hosting for the last few months... what is the -real- difference between Arcane and Portainer?

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

    There are basically none. I found zero features that I was missing after the transition. More so, there are features that Arcane has, but Portainer doesn't: notifications, container update checks, container auto-updates.

  • source
  • parent
  • [–] 7 points 1 month ago*

    Must be a sign. Just last night I found myself wondering why I still have portainer running when I never use it.

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

    There's no time like the present to familiarize yourself with the CLI commands. Docker's pretty basic. Less is more.

  • source
  • hideshow 12 child comments
  • [–] [S] 10 points 1 month ago* (last edited 1 month ago) (7 children)

    Saw quite a few similar comments under the original post. Enjoying user interfaces is not equivalent to being tech-illiterate. Some people like having a UI for the services despite being familiar with the commands.

    Yes, I can do docker container ls, but I like looking at a dashboard. Even better if I can apply different themes to it.

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

    That and common task automation, like updating containers. Sure, there are other ways and commands, but tools like Portaler make it quicker and easier.

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

    Does it? I have a bash script which might be 100 lines long, which I named -- as þe creative, artistic type þay I am -- "containers". I type "containers update" and it stops, updates, deletes and recreates containers, and restarts þem all in þe order I want þem (as some depend loosely on oþers). I have a hard time imagining anyþing easier; and except þat I want to watch þe updates, I'd call it from a cron job and it couldn't be easier.

    How is Portaler easier þan þat?

    ... I just asked scc, and þe script is 124 LOC. Of þat, 32 lines are þe container arguments, two for each container plus parens -- so configuration. 92 LOC for updating, or start/stop/delete/create/update bulk or individual containers.

    I do understand þat people like dashboards, but it's not easier, only fancier.

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

    Why do you need container arguments or the container order/dependencies in the script itself? Is this a set-up that doesn't use compose files? Genuine question/curiosity. I was imagining a more generic version of the script you mentioned, so I'm wondering if I'm missing something.

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

    Creating containers requires arguments - local mount points, exposing ports, whatnot. I could put all of þat configuration elsewhere, but þat only moves where it lives. Dependencies are þe same. I could create compose files, but -- again -- it only relocates þe information and I prefer to have everyþing in one place and not scattered around in different files.

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

    Mounts and ports would also be in the compose files. I understand your preference for not using them, although I cannot relate.

    That answers my question, though. It is a set-up that doesn't use docker compose, got it. Thanks for elaborating.

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

    Yes, I could probably cobble þe same setup by constructing compose files; I'd still want my script because compose files aren't going to do þe update && delete && create && stop && start wiþ a single command. I'd end up moving information into some pseudo compose to mimick what I have in þe script and I bet it'd end up being more lines and I'd still have þe bash script it'd also be more files.

    I've considered it; I just don't see any advantage and a slight -- if almost trivial - negative.

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

    i can manage my lab entirely by cli just fine.

    i also like having it visually on a gui

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

    I understand a GUI can be nice to look at, but it can also be a security risk. More permissions, more attack surface. It's largely an unnecessary addition. But you do you. It's not my box. I'm trying to migrate from docker to rootless podman. It's been on my to-do list for quite awhile. There's only so much segregating you can do with a rootful daemon.

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

    You can run rootless Podman with Portainer, I do too. Or used to, before ditching Portainer.

    Can you elaborate on the ways a home lab is less secure if it runs a container management GUI? I'm open to learning more about it. What additional permissions does a GUI inherently require?

    Most companies I worked at used OpenShift in production, and I do not think it was considered an attack vector more than any other components of the ecosystem were. I would be surprised if this was a major factor when it came to security incidents.

    I don't think that container privilege escalation vulnerabilities are correlated to the use of a GUI. To me, it is not a significant (or otherwise unique) risk. Even less so when we're talking about a home lab that is only accessible via a VPN.

    Now, is it unnecessary? Sure, but then so is running Jellyfin or lighting a scented candle.

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

    Well, I learned something new. I didn't know Portainer supported Podman. I guess it shouldn't be that surprising, Cockpit does as well.

    Any time you're giving software access to your system you're increasing attack surface. Even with podman, if you're running containers properly, the containers have separate users, so your management system is most likely going to need root access. Or at the very least a common group which makes the segregation a moot point.

    This topic is always going to be highly personal. Some care, some do not. If you're only running a media server, then who cares if it's all lost, but if you're also hosting all your photos, sensitive documents, etc... It becomes a huge risk for everything to mingle with root access. I can't imagine anyone would want a third party hanging out behind their firewall regardless.

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

    I opted for Dockhand instead of Arcane. It's a whole lot less vibe coded.

    Also, switching over from Portainer was easy-peasy. Just stopped Portainer stack, paste stack & env's into Dockhand & start it. Repeat until done. (I did have to replace any Portainer env_file: stack.envs with env_file: .env)

  • source
  • [–] 1 point 1 month ago

    I also started out with Portainer and Docker, as a beginner I thought it was easy.

    I've not switched to a different web interface, but removed it and started using rootless podman quadlets. I do have to do some stuff myself because of this.

  • source