I often see people mention the Portainer project and how it’s useful, but I never hear any reason to use it other than as a more user friendly front end to service management.

So is there any particular feature or reason to use portainer over docker’s CLI? Or is it simply a method of convenience?

This isn’t only strictly for self hosting, but I figure people here would know better.

  • Voroxpete@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    77
    arrow-down
    6
    ·
    edit-2
    1 month ago

    Please don’t use Portainer.

    • It kidnaps your compose files and stores them all in its own grubby little lair
    • It makes it basically impossible to interact with docker from the command line once it has its claws into your setup
    • It treats console output - like error messages - as an annoyance, showing a brief snippet on the screen for 0.3 seconds before throwing the whole message in the shredder.

    If you want a GUI, Dockge is fantastic. It plays nice with your existing setup, it does a much better job of actually helping out when you’ve screwed up your compose file, it converts run commands to compose files for you, and it gets the fuck out of the way when you decide to ignore it and use the command line anyway, because it respects your choices and understands that it’s here to help your workflow, not to direct your workflow.

    Edit to add: A great partner for Dockge is Dozzle, which gives you a nice unified view for logs and performance data for your stacks.

    I also want to note that both Dockge and Dozzle are primarily designed for homelab environments and home users. If we’re talking professional, large scale usage, especially docker swarms and the like, you really need to get comfortable with the CLI. If you absolutely must have a GUI in an environment like that, Portainer is your only option, but it’s still not one I can recommend.

    • ikidd@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 month ago

      As another commenter mentioned, Lazydocker combines Dockge and Dozzle features, and adds some other things to give you a TUI environment that works over SSH so you don’t have to open a web port to use it.

    • heyixen815@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      1 month ago

      You can just connect a (local) Git repo to it and store your compose files over there. There should be even an auto-sync (if you’re into that kind of thing).

      • Voroxpete@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        11
        arrow-down
        3
        ·
        1 month ago

        Not the point. If you want to interact with the compose files directly through the command line they’re all squirelled away in a deep nest of folders, and Portainer throws a hissy fit when you touch them. Dockge has no such issues, it’s quite happy for you to switch back and forth between command line and GUI interaction as you see fit.

        It’s both intensely frustrating whenever it comes up as an issue directly, and speaks to a problem with Portainer’s underlying philosophy.

        Dockge was built as a tool to help you; it understands that it’s role is to be useful, and to get the fuck out of the way when its not being useful.

        Portainer was built as a product. It wants to take over your entire environment and make you completely dependent on it. It never wants you to interact with your stacks through any other means and it gets very upset if you do.

        I used Portainer for years, both in my homelab and in production environments. Trust me, I’ve tried to work around its shortcomings, but there’s no good solution to a program like Portainer other than not using it.

    • Wolfram@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      I’ve never used Portainer but I feel a GUI setup like it just abstracts Docker and prevents learning concepts that are conducive to understanding Docker. That’s why I’ve never used a GUI to manage my Docker environment.

      • Voroxpete@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 month ago

        I don’t think there’s anything inherently wrong with the idea of using a GUI, especially for a non-professional who mostly just wants to get into self-hosting. Not everyone has to learn all the ins and outs of every piece of software they run. My sister is one of the least technical people in the world, and she has her own Jellyfin server. It’s not a bad thing that this stuff has become more accessible, and we should encourage that accessibility.

        If, however, you intend to use these tools in a professional environment, then you definitely need to understand what’s happening under the hood and at least be comfortable working in the command line when necessary. I work with Docker professionally, and Dockge is my go to interface, but I can happily maintain any of my systems with nothing but an SSH connection when required. What I love about Dockge is that it makes this parallel approach possible. The reason I moved my organization away from Portainer is precisely because a lot of more advanced command line interactions would outright break the Portainer setup if attempted, whereas Dockge had no such problems.

        • Wolfram@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 month ago

          Totally, I get it if its a means to an end to get something like Jellyfin up.

          Maybe its a me thing. I just like to understand the mechanics of the tools I use.

    • 𝓢𝓮𝓮𝓙𝓪𝔂𝓔𝓶𝓶@lemmy.procrastinati.org
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      3
      ·
      1 month ago

      Just because something doesn’t fit your use case doesn’t make it a terrible product. Portainer isn’t meant to complement managing docker via CLI. It’s meant to be the management interface.

      If you want to manage your environment via CLI, I agree, don’t use Portainer. If you’re content (or prefer) a GUI, Portainer is a solid option. Esp if you have multiple hosts or want to manage more than just the compose stack. Last time I checked Dockge doesn’t do either.

      • ShortN0te@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        3
        ·
        1 month ago

        The thing is, those poor design decisions have nothing to do with those features, i claim that every feature could be implemented without “holding the compose files hostage”.

        Btw. dockge does support connecting to another docker dockge instance.

        • Voroxpete@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          1
          ·
          1 month ago

          The thing is, those poor design decisions have nothing to do with those features, i claim that every feature could be implemented without “holding the compose files hostage”.

          Yes, this is exactly my point. I think I’ve laid out very clearly how Portainer’s shortcomings are far more than just “It’s not for your use case.”

          Portainer is designed, from the ground up to trap you in an ecosystem. The choices they made aren’t because it’s necessary to do those things that way in order to be a usable Docker GUI. It’s solely because they do not want you to be able to easily move away from their platform once you’re on it.

  • walden@sub.wetshaving.social
    link
    fedilink
    English
    arrow-up
    21
    ·
    1 month ago

    I switched from portainer to dockge. Dockge makes updating a 1-click process which I love. Portainer is overkill for homelab, but I like how it lists things like images and networks.

  • Earth Walker@lemmy.world
    link
    fedilink
    English
    arrow-up
    12
    ·
    1 month ago

    Like many GUIs it makes it so you don’t have to remember and type a bunch of commands to carry out basic tasks. I especially find it convenient for checking logs. But no unique functionality compared to CLI. So it’s a matter of preference.

    • interurbain1er@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      4
      ·
      edit-2
      1 month ago

      But that’s also why you don’t know the commands in the first place, if you used them you would remember them. It’s self sustaining ignorance ;)

      Ps: I kid, there a lot of stuff I don’t care to remember the cli for and I happily use GUI.

      PPS: docker logs -f container_name ;)

  • grimer@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 month ago

    95% of the time I’ll use the CLI but occasionally it’s faster for me to check a bunch of boxes in Portainer and restart entire stacks at the same time instead of going to each one’s folder. Maybe a few other little things like that but you get the idea.

    • ikidd@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      Excellent utility, this covers everything I used Portainer for and works over SSH.

      • ikidd@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 month ago

        TUI so it’s easy to use over SSH. And I think it’s a lot more featureful than dockge. You can remove images, get a running log, performance graphs and more environment info.

        I put this on all my docker hosts and alias it to lzd, use it all the time.

  • 𝒎𝒂𝒏𝒊𝒆𝒍@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    1 month ago

    If you know Linux CLI, is there a reason to use GUI? Same principle CLI gives you more granular control and GUI simplifies a lot of things, gives you more of insight etc

  • gamermanh@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 month ago

    My main 2 reasons for installing it both come from needing to restart services sometimes:

    Portainer let me allow other people access to restarting specific containers that occasionally misbehave

    Portainer lets me update and restart all of the containers running in my VPN stack without breaking. For some ungodly reason, even with dependency set and everything in docker-compose, a CLI reboot will basically always start a service or 2 before gluetun is actually advertising it’s in a healthy state and everything breaks. With portainer that doesn’t happen, with the exact same compose, and I don’t get why lol

    • aStonedSanta@lemm.ee
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 month ago

      And then there is me. I had to start my stack 7 times yesterday in portainer. I should really figure out how to set it up right. I had thought setting gluetun to a static IP would get it to launch first. Or adding it to the top of the config. But alas. No go.

      • gamermanh@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 month ago

        What works for me:

        Networks first in docker-compose

        Gluetun first in Services, uses the network I set for it and the stack

        Everything else goes below it, relying on the gluetun CONTAINER (I plan to have another stack running gluetun for other reasons so having it check the service is a no go for me) to be running in a HEALTHY state

        All are set to restart: unless-stopped except gluetun, which is never

        The expected behaviour is that containers will always wait for gluetun to report that it’s healthy before trying again to restart. Should gluetun fail and crash for any reason it won’t reboot and potentially fuck itself up harder, and no services will be able to start because it’s not reporting healthy.

        This works perfectly in portainer and should when running docker-compose up, but for me it took portainer to work. Saw someone somewhere mention it has some sort of priority handling override built into it that docker itself doesn’t, meaning it’s less likely to fuck that lind of thing up, but idk how true it is

        I’ll see if I can remember to snag a couple snips of my YAML to make it more clear

        • aStonedSanta@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          Awesome. Thank you so much. Saving this for when I get back into town. Gonna fuck around and find out Monday 💜🙏

          • gamermanh@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            1 month ago

            Ok, had my wife send me the file from my network

            networks:
              main-network:
                name: ${COMPOSE_PROJECT_NAME}
                attachable: true
                ipam:
                  driver: default
                  config:
                    - subnet: configure
                      ip_range: this
                      gateway: yoself
            
            services:
              # Gluetun - <https://github.com/qdm12/gluetun>
              gluetun:
                image: qmcgaw/gluetun
                container_name: gluetun
                networks:
                  - main-network
                cap_add:
                  - NET_ADMIN
                environment:
                  - PUID=${PUID}
                  - PGID=${PGID}
                  - TZ=${TZ}
                  - VPN_SERVICE_PROVIDER=custom
                  - VPN_TYPE=wireguard
                  - VPN_PORT_FORWARDING=true
                  - VPN_PORT_FORWARDING_PROVIDER=protonvpn
                  - WIREGUARD_ADDRESSES=use your own
                  - WIREGUARD_ALLOWED_IPS=0.0.0.0/0
                  - WIREGUARD_PRIVATE_KEY=nope
                  - WIREGUARD_PUBLIC_KEY=69420
                  - WIREGUARD_DNS=
                  - VPN_ENDPOINT_PORT=
                  - VPN_ENDPOINT_IP=
                volumes:
                  - ${DOAPPDAT}/gluetun:/gluetun
            

            I left in the wireguard stuff without my details because for me Gluetun refused to work when setting the exact same info to wg0.conf, so I define it in my compose

            Then, services that rely on gluetun go below and look like:

            # qBittorrent - <https://hub.docker.com/r/linuxserver/qbittorrent>
            qbittorrent:
              container_name: qbittorrent
              network_mode: container:gluetun
              image: lscr.io/linuxserver/qbittorrent:latest
              depends_on:
                gluetun:
                  condition: service_healthy
              restart: unless-stopped
            
            

            Works perfectly when I run it through portainer

            • aStonedSanta@lemm.ee
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              28 days ago

              It worked. Muahaha it worked. Thank you so much. I still have so much to learn. But one click and repulled and redeployed. The only change I needed in my config was to add.

              depends_on:
                  gluetun:
                    condition: service_healthy
              

              Into each container that was controlled by gluetun

            • aStonedSanta@lemm.ee
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 month ago

              Thank you so much. 😊 I see a few things already worth changing in my file. You da best.

              • gamermanh@lemmy.dbzer0.com
                link
                fedilink
                English
                arrow-up
                2
                ·
                1 month ago

                It took me too long to get everything working myself because people love to share shit exclusively in CLI format and look down at anyone who asks for YAML it seems, so I’m always glad to pass it on

                (I can understand CLI, but the ADHD brain finds YAML much easier for documentation purposes and it surprises me how many people seem to disagree)

  • K3CAN@lemmy.radio
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 month ago

    I’d imagine that if your job is making YouTube videos, portainer and other graphical abstraction layers probably make more visually interesting videos than just watching someone type out a bunch of commands.

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 month ago

    It’s a good way to have all the different parts exposed to you. Once you’re familiar, it’s usually easier to write those parts up in a compose file and just run or rerun docker-compose.

    • yonder@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 month ago

      This is exactly what I do. I find Portainer to be nice for getting an overview of my containers that are all created using docker-compose.

  • Pissio@feddit.it
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    1 month ago

    I’m using it to manage a little swarm , the useful thing is that is easy to explain to a non IT person how to log in and restart a service if needed.

  • 𝓢𝓮𝓮𝓙𝓪𝔂𝓔𝓶𝓶@lemmy.procrastinati.org
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    2
    ·
    1 month ago

    Personal preference? I prefer the Portainer’s presentation over the CLI. I especially find it easier to manage networks and volumes.

    But my main reason is I have multiple docker hosts and it gives me a “single pane on glass” to manage everything from.

  • just_another_person@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 month ago

    It’s just a front-end abstraction for different c ontainer backends, so no. I don’t think they have some distinct features that deal in any functionality for the container ecosystem or anything.