# Guide for Version Control with Ignition

**URL:** <https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004>\
**Category:** Ignition\
**Tags:** ignition81, docker\
**Created:** [January 9, 2024, 7:52pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004 "2024-01-09T19:52:05Z")\
**Posts on this page:** 1\
**Showing post:** 56

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [October 22, 2025, 6:21pm UTC](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004/56 "2025-10-22T18:21:40Z")

</div>

I’m buidling a ‘KISS' Portainer ‘GitOps’ edge ‘stack' + DevOps for project-level repo CD into named volumes. Would be nice if i could deploy an “empty” ignition container with separate config/project named/anonymous volumes and clone into them afterwards with a git-sync sidecar, but that’s not possible ATM. Criticism welcome of course

thoughts:

- mounting empty volume to /projects fails with unable to create .resources dir
  - guessing due to similar issue above, `data/*` dir init doesn’t fire if it exists, assuming pre-seeding would work

- named volumes/PVCs are best practice in orchestrated environments - might as well avoid bind-mounts in dev as well - the fact that “Advanced” section of the guide provides bind-mount examples alongside mentions of GitOps tools like Argo/Flux is surprising to me (though I’m admittedly a k8s noob, maybe I’m missing something)
  - historically the more OT-accessible Portainer didn’t support relative-path bind volume mounts for gitOps-based ‘stack’ deployment, without git, must seed the docker host with bind mount source data manually/via CD tools

---

_[View the full topic](https://forum.inductiveautomation.com/t/guide-for-version-control-with-ignition/84004)._