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.
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.