For those unfamiliar, DockGE is “A fancy, easy-to-use and reactive self-hosted docker compose.yaml stack-oriented manager.”
Similar to portainer
Warning
Breaking change: Due to the security reason, the “Console” feature is now disabled by default. If you need this feature and understand the risk, you can enable it via the environment variable DOCKGE_ENABLE_CONSOLE=true.
See link for full notes
Breaking change: Due to the security reason, the “Console” feature is now disabled by default. If you need this feature and understand the risk, you can enable it via the environment variable DOCKGE_ENABLE_CONSOLE=true.
Good that they made a decision, the old security features restricting which commands you could run were awful and could be bypassed by accident. You could run
ALLOWED_COMMAMD; ANY_OTHER_COMMAND.preserve YAML comments when reordering items
This fix is massive, lost a lot of useful info when I moved my yml files
I haven’t experienced this, oddly enough. Many of my compose files have comments, and they’re still visible 🤔
I used this for a bit. Can you import existing stacks yet? That was my missing feature.
If the compose.yml can be moved to a place where Dockge is configured to look, then yes. Normally it’s configured to look in
/opt/stacks/, but that can be changed.I just updated my dockge container, you still have to start compose files from dockge in order to manage them. Which requires copy/pasting compose files into dockge. If you have more than 2-3 compose files, this is a pia. To me, that’s not an import of ‘existing stack’.
I think you might be misunderstanding here, Dockge doesn’t really work like that. You don’t import “into” Dockge - it works alongside Docker, and all you need to do is point it to where your compose files are located. Which, like I said, is normally set to
/opt/stacks/- but that’s not set in stone and can be changed to another location via theDOCKGE_STACKS_DIR=env variable within Dockge’s own compose file (located in/opt/dockge/).For example: I can create the directory
/opt/stacks/docker_container/, drop in my “docker_container” compose.yml file, and fire it up in the terminal withdocker compose up -d, and Dockge will automatically see the compose file and the stack status. Or, I can point Dockge at a custom location such as/home/username/docker_stacks/, and so long as each compose file has a labeled folder inside that directory, that’s all you need to do to be done with it.Also, something I just remembered - the folder structure, wherever it’s located, needs to be all lowercase. Otherwise Dockge won’t see it.
Thanks for the info, that’s definitely not how it’s working on my system, so I have something setup wrong. That explains my confusion.
Thanks for the detailed explanation! One thing is unclear to me, though: what’s the difference between the path and the why do I still need the ENV in addition? Won’t they match anyway in 99% of the cases? Since there’s not really a reason to not set the path to the stack folder?
The env variable is within the compose file itself - it’s fairly simple.
Yeah, I saw that, but why is it needed in the first place? Just in case the stack is in a subfolder of the path? But why even do that, if the ENV only accepts a single value anyway? I’m wondering in which cases the path differs from the DOCKGE_STACKS_DIR env var?
It’s needed because that’s how Dockge manages the compose files - it needs to know where your compose files live. Dockge normally lives in it’s own directory,
/opt/dockge/(the dev gave a reason for that, but I don’t remember why), so it won’t see anything else until you point it to wherever your compose files are normally located.
I’m a fan of Dockge. Nice simplicity, easy to update container stacks, etc. etc.
