Stack in git repo

[GeirMydland]

As the subject says could we have the functionality to point my stack root to some git url maybe even with ref branch? Any new stack would trigger a commit to branch/repo

[GeirMydland]

On the other hand you could also just clone a remote repo to the local my stack and just have some kind of git add . and commit to remote.

[BadCo-NZ]

I'm also keen on a stack git back end.

[ankushg]

Also interested in this!

Would love some sort of bidirectional sync so changes in git would get pulled (via polling or maybe even a webhook), and changes from dockge would get pushed :)

[kasek61]

+1 to this as well, being able to house my compose files in something like gitea and deploy a stack that way is one of the major portainer features I use.

[snapshotleisure]

Also support this

[almereyda]

For supporting push-based, PaaS-style "GitOps" with Compose files, there is antoniomika/pcompose, from which bits of logic could be ported or taken inspiration from.

Pull-based syncing involves a lot of repository handling, from what I can tell from experiences with ArgoCD, esp. around authentication and secrets management.

[nightly-brew]

Just found this discussion, and I feel it's so similar to something I have in mind, that another request would be unnecessary.

On my end, I would love to have the ability to

• clone a git repo
• pull updates for a previously configured git repo

For the clone action, one could theoretically specify the repo url and provide credentials in some way (if needed), which would be then archived for later use.

For the pull action, the credentials could be reused.
If between pulls one was to change some stack settings, thus changing the local repo, there could be a dockge setting/variable specifying how to react on next pull:

• ask the user
• discard changes and pull
• sync both ways

I, for one, wouldn't want to have changes pushed to git, so something like this would allow the behaviour to be pretty customizable.
Maybe a suitable default would be "ask the user".

For supporting push-based, PaaS-style "GitOps" with Compose files, there is antoniomika/pcompose, from which bits of logic could be ported or taken inspiration from.

Pull-based syncing involves a lot of repository handling, from what I can tell from experiences with ArgoCD, esp. around authentication and secrets management.

What if the standard git binary was used? Dockge already manages stacks by invoking docker-compose, from what I can tell.

[ebaldebo]

Probably not quite what you're looking for but I missed the GitOps functionality when switching from Portainer. I have no compose files locally, they're all in git. Basically polling the repo and updating my stacks if there are change is all I need.

Wrote a simple container that I run together with the Dockge one to handle this. Note that the functionality is very limited but it does enough for me to completely replace Portainer with Dockge. It will ignore your local changes though and replace them if there are changes in the git repo.

ebaldebo/dockge-gitops

[nightly-brew]

Good idea, thanks for sharing!

Still, this would work only on a single host.
Would be good to have this functionality working on multiple hosts, if agents are defined and connected.

For example, my setup consists of 3 vms, each with its set of containers.
Some of them bind mount config files and other resources, which are tracked in the same repo that contains the compose files, as in

Thinking about it now, maybe git-added stacks should have a "scope".
It could be possible to define which hosts "receive" a particular stacks repo, but I think this one is going more towards the direction of "host groups" and should get a separated discussion maybe?

What do you think?

[ebaldebo]

Got a few other things in my backlog(using go-git instead of adding git to the container etc), but can look into this and see if I can get something working.

Like you mentioned though I also feel like it will diverge a bit from its original purpose. Wish my typescript/js knowledge was better so I could make PRs towards the main repo instead.

[knuurr]

It would be really cool.

Maybe instead of handling entire git repo (which would be ideal, especially if I could point to individual paths on that repo) let's start with simple wget from fixed endpoint?

That is: for given stack, dockge pulls every n minuts/hours/whatever from particular endpoint. It could check updates based on checksuming what's locally in stack vs what's received (I think compute power for this wouldn's be too much, but not sure) if there's difference, replace local file (if not read only) and redeploy.

I know it doesn't take into consideraiton rollbacks, newer commits etc. but sounds really simple in implementation. And if something you can always roll back on branch itself.

[zoopli]

I also would love to see some kind of gitops functionality. This would be a killer feature.

[Roundaround]

Just wanna put my two cents here that I think there are two separate feature requests here.

1. Manual git integration from the UI. If the stacks directory happens to be a git repository, add mechanisms to pull, commit/push, diff, etc from the UI. The obvious quick-win would be to allow enabling the "git" command from the embedded console window. Perhaps this could be tied to an opt-in environment variable if security is a concern.
2. Some kind of GitOps solution that automatically keeps your containers and compose files in sync with a git repository. Personally I think this is stretching outside the purpose of Dockge a bit too far and probably would be better served by some other solution (Ansible and the likes).

[apperrault]

I wanted to see if there was any traction on this feature.

I have been using a utility called Dokemon (https://github.com/productiveops/dokemon), which is very similar to Dockge, except it has a setup for managing multiple docker hosts in one console (with an Agent type setup), as well as the ability to point my compose library to Github. Unfortunately, the owner of the repo, has had to step away so there has been no development for a while.

Any thoughts on getting this feature in Dockge?

thanks
app

[erviker]

+1

What i prepose one repo for multiple servers. But that each server is standalone when it comes to checking if there are updates via button in the web interface, and maybe an automated check and fetch compose up on a configurable variable.
Prepose a structure like this.

• My-dockge-repo
• • Server 1
• • • Service 1
• • • Service 2
• • Server 2
• • • Service 3
• • • Service 4
      As the servers are "standalone" there is also the possibility to run multiple servers from the same folder in casese where one is running muliple server with the same config.

[rubenssoto]

Any update on this guys? I would love to have this feature

[apperrault]

I normally wouldn't recommend one container in the support section for a different container, but I have been playing around with Komodo https://komo.do/docs/intro, and it does do most of what is mentioned here.

There is kind of a Learning curve, but it works pretty well once you get it setup. I have a repo of "base compose" files, and then when I want to deploy them to a server, I simply copy the stack to the new location and tell it "Go" and it will checkout and deploy the stack.

HMU on Reddit, here or Discord if you want more info

[rubenssoto]

It seems pretty good, I will definitly try.

[Nick2253]

I just wanted to throw in my support for this idea. Currently, I use Portainer, but I'm not in love with all the decisions that it makes. If dockge could do something more sophisticated with its git integration, then I'd jump ship in a heartbeat.

Right now, I'm using a Gitea instance to hold my compose files in a repo.

In particular, @Roundaround's suggestion of a manual git interface in the WebUI would be perfect for me. I use Portainer's GitOps webhooks to automatically update my containers, when I push updates to the repo, but that's really a minor benefit given that I'm a one-man hobbyist with a home-lab. It would be trivial to manually trigger an update in dockge after committing the changes to the repo. And it would also be amazing to have a purpose-built web-based GUI to edit the compose files, so I can quickly make changes from work or on the road when I have some time to play around with the home lab (as opposed to using the rather clunky Gittea interface).

[BadCo-NZ]

Have you looked at Komodo? It is very git focused. I also used Poratainer but the workflow for adding a stack from git was painful, so I manual manage my stacks now. Komodo looks like a good option for a bit based workflow instead of dockge.

[Nick2253]

This was the push for me to fully investigate Komodo. And with the enhancements that came in v2, I finally pulled the plug. I've now been running Komodo for 3-4 months, and I love it. The only features that I miss from Portainer is creating networks, but that's an easy command, and I don't really need it that often.

The biggest benefit, for me, is the combination of integrated git backends and updates.

[apperrault]

I have made the flip to Komodo 100%, and I'm on scratching the surface. There are aspects of dockge I enjoyed, but the guy integration flipped it for me App *Don't hold onto a mistake just because you spent a long time making it. * Aaron Perrault ***@***.***

…

On Tue, Dec 2, 2025, 18:47 BadCo-NZ ***@***.***> wrote: Have you looked at Komodo? It is very git focused. I also used Poratainer but the workflow for adding a stack from git was painful, so I manual manage my stacks now. Komodo looks like a good option for a bit based workflow instead of dockge. — Reply to this email directly, view it on GitHub <#36 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLHMYQ4WRE2PAIBUNRNAWL37YQJ7AVCNFSM6AAAAACN2Z7X5CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJUGE2DENA> . You are receiving this because you commented.Message ID: ***@***.***>

[Aerya]

Hi, added to my Enhanced fork.