# Git Repository Structure and Asymmetric Deployment Modes Strategy **URL:** \ **Category:** Ignition\ **Tags:** ignition83, perspective\ **Created:** [August 3, 2026, 5:15pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633 "2026-08-03T17:15:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![hflores](https://avatars.discourse-cdn.com/v4/letter/h/71e660/32.png) [@hflores](https://forum.inductiveautomation.com/u/hflores)\ **Post date:** [August 3, 2026, 5:15pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633/1 "2026-08-03T17:15:12Z")
Hi everyone, We are planning our migration/implementation workflow under **Ignition 8.3** , leveraging a **Scale-Out Architecture**. Our infrastructure consists of: - **Multiple Frontend Gateways:** Handling Perspective and UI. - **Multiple Backend Gateways:** Functionally identical in terms of global logic and scripts, but with **distributed/asymmetric devices** mapped across them. To add context, our environments are unbalanced: we have **5 Backend Gateways in PROD** (each with unique device connections) and **2 Backend Gateways in TEST** (with different, potentially simulated device connections). As we adopt the new file-system structures and **Deployment Modes** in 8.3, we are re-evaluating our version control and deployment pipeline. We would highly appreciate the community's feedback on our current questions and our proposed strategy. ### 1. Repository Structure: Micro-repos vs. Monorepo? Right now, we are separating everything into independent Git repositories (separate repos for Tag Definitions, UDTs, Global Project, Scripting, and Frontend Perspective). - Given the new 8.3 architecture, is this highly granular approach still recommended, or is the community moving towards a unified **Monorepo per Gateway type** (e.g., one Monorepo for Frontends, one Monorepo for Backends) to avoid dependency issues? ### 2. Deployment Modes in Asymmetric Scale-Out clusters Since our backends within the same environment are not identical clones (Backend A has different devices than Backend B), a simple "TEST" and "PROD" deployment mode structure doesn't fully cover our needs. - Can Deployment Modes natively handle hierarchical overrides? (e.g., a _Core_ mode inherited by an _Environment_ mode, which is then inherited by a specific _Gateway_ mode?) Or does this overcomplicate the 8.3 native structure? ### 3. Strategy Validation: Hybrid Instance-Profiles + OS Env Variables To solve the asymmetry between our 2 TEST backends and 5 PROD backends, we are designing the following **hybrid architecture** within a Monorepo, and we want to validate if this is considered a solid best practice: - **Instance-Level Overrides in Git:** Instead of environment-wide modes, we create **7 distinct Deployment Modes** representing each physical/logical server instance (`prod-backend-1` to `prod-backend-5`, and `test-backend-1` to `test-backend-2`). These folders will exclusively contain the configuration overrides for that specific gateway's local device connections. **Our questions for the experts:** 1. Is combining granular, instance-specific Deployment Modes in Git with OS Environment Variables for the network/database layer considered a robust and scalable practice in Ignition 8.3? 2. Are there any hidden pitfalls or performance issues when scaling the number of individual deployment mode folders inside a single repository? 3. Would you manage this differently (e.g., keeping devices entirely out of Git and managing them via EAM/manually)? We would love to hear your thoughts and experiences managing similar large-scale setups with the new 8.3 features. Thanks in advance! ---
**Author:** ![Noah\_Burnette](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/noah_burnette/32/83777_2.png) [@Noah\_Burnette](https://forum.inductiveautomation.com/u/Noah_Burnette)\ **Post date:** [August 4, 2026, 1:15pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633/2 "2026-08-04T13:15:00Z")
Hello, There is a lot here. I would first recommend to look at the ignition documentation: > **[Version and Source Control Guide | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/tutorials/version-control-guide)** > > Learn more about best practices for setting up version control in Ignition. > **[Best Practices for Using Git in a Team Environment | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/tutorials/version-control-guide/best-practices-for-team-environments)** > > The following is aimed to outline best practices for using Git effectively in a team environment. > **[Gateway Deployment Modes | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/platform/gateway/web-interface/platform/gateway-deployment-modes)** > > Gateway Deployment Modes allow you to configure different running environments for your Gateway. This can be useful in cases where you want to use your Gateway in different capacities, such as in a production or development environment. For monorepos I like the trunk based development [approach](https://trunkbaseddevelopment.com/monorepos/). I have had much success with it. Based on the phrasing of your questions, please take a look at the [guidelines](https://forum.inductiveautomation.com/guidelines#stealing) on AI content. More than happy to take a look at your current implementation and layout if you post it here. ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [August 4, 2026, 2:13pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633/3 "2026-08-04T14:13:49Z")
> [@hflores](#): > > ### 1. Repository Structure: Micro-repos vs. Monorepo? > > Right now, we are separating everything into independent Git repositories (separate repos for Tag Definitions, UDTs, Global Project, Scripting, and Frontend Perspective). > > - Given the new 8.3 architecture, is this highly granular approach still recommended, or is the community moving towards a unified **Monorepo per Gateway type** (e.g., one Monorepo for Frontends, one Monorepo for Backends) to avoid dependency issues? Monorepo is the best if your organisation structure/vendor structure allows for that. Way easier to manage. > [@hflores](#): > > ### 2. Deployment Modes in Asymmetric Scale-Out clusters > > Since our backends within the same environment are not identical clones (Backend A has different devices than Backend B), a simple "TEST" and "PROD" deployment mode structure doesn't fully cover our needs. > > - Can Deployment Modes natively handle hierarchical overrides? (e.g., a _Core_ mode inherited by an _Environment_ mode, which is then inherited by a specific _Gateway_ mode?) Or does this overcomplicate the 8.3 native structure? Deployment modes are for test, staging production, not meant for different gateways handling completely different devices. You will need one config structure per gateway. (automations/shared stuff is still possible in a monorepo. > [@hflores](#): > > ### 3. Strategy Validation: Hybrid Instance-Profiles + OS Env Variables > > To solve the asymmetry between our 2 TEST backends and 5 PROD backends, we are designing the following **hybrid architecture** within a Monorepo, and we want to validate if this is considered a solid best practice: > > - **Instance-Level Overrides in Git:** Instead of environment-wide modes, we create **7 distinct Deployment Modes** representing each physical/logical server instance (`prod-backend-1` to `prod-backend-5`, and `test-backend-1` to `test-backend-2`). These folders will exclusively contain the configuration overrides for that specific gateway's local device connections. Imo you are abusing deployment modes here. What you should be building are pipelines that deploy to different gateways based on the environment you are deploying to. > [@hflores](#): > > 1. Is combining granular, instance-specific Deployment Modes in Git with OS Environment Variables for the network/database layer considered a robust and scalable practice in Ignition 8.3? No, you will need to have different configs per gateway. Deployment modes are only good for handling differences on gateways that fulfil the same role, but just in a different environment. > [@hflores](#): > > 1. Are there any hidden pitfalls or performance issues when scaling the number of individual deployment mode folders inside a single repository? No, not really, but you will get yourself in a unmaintainable solution. You can achieve what you want without abusing the deployment modes. > [@hflores](#): > > 1. Would you manage this differently (e.g., keeping devices entirely out of Git and managing them via EAM/manually)? Everything in Git, use deployment modes for what it is good at, no EAM. ---
**Author:** ![Noah\_Burnette](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/noah_burnette/32/83777_2.png) [@Noah\_Burnette](https://forum.inductiveautomation.com/u/Noah_Burnette)\ **Post date:** [August 4, 2026, 2:23pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633/4 "2026-08-04T14:23:22Z")
> [@louagejasper](#): > > Imo you are abusing deployment modes here I think this is strong wording. That is absolutely how we deploy our configuration changes to our gateways. I spoke with IA at proveit! about this approach and they said that it was perfectly valid. It works ridiculously well. I can spin up a **single** gateway and make all my configuration changes there in a single commit and all within the gateway UI. ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [August 4, 2026, 3:26pm UTC](https://forum.inductiveautomation.com/t/git-repository-structure-and-asymmetric-deployment-modes-strategy/116633/5 "2026-08-04T15:26:35Z")
> [@Noah\_Burnette](#): > > I think this is strong wording. That is absolutely how we deploy our configuration changes to our gateways. I spoke with IA at proveit! about this approach and they said that it was perfectly valid. It works ridiculously well. I can spin up a **single** gateway and make all my configuration changes there in a single commit and all within the gateway UI. Might have been strong wording. I'm open, but I guess I never looked from that perspective. So you have you device config only in the deployment modes? So in overrides you just have entirely different devices, not just overrides on the devices in core? I still do wonder why would you not just handle it in the deployment pipelines? You would still be able to edit everything in one gateway, since you can mount all folders to your one development gateway.