# Gateway Deployment Modes: Use core as development collection? **URL:** \ **Category:** Ignition\ **Tags:** ignition83\ **Created:** [September 29, 2026, 7:50pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256 "2026-09-29T19:50:36Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [September 29, 2026, 7:50pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/1 "2026-09-29T19:50:36Z")
I am finally starting to dabble with v8.3, and I'm not sure which way to go with the deployment overrides. Should I setup my `core` DB connections with development settings, then add overrides for a `production` collection, or should I have `core`, `dev`, and `production` configs? This seems like a lot more duplication, but I will do it this way if it has some benefit. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [October 2, 2026, 3:45am UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/2 "2026-10-02T03:45:02Z")
I prefer a configuration where `core` contains the entirety of production resources, then add other deployment (dev & stg) overrides to that base. It has been convenient developing workflows where the entire production config is contained in a single folder. ---
**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\ **Post date:** [October 2, 2026, 12:17pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/3 "2026-10-02T12:17:48Z")
I agree with @Chris_Bingham . The number of overrides you need for a dev and staging environment tend to be small so keeping core as production makes the most sense IMO. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [October 2, 2026, 1:47pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/4 "2026-10-02T13:47:28Z")
> [@Chris\_Bingham](#): > > I prefer a configuration where `core` contains the entirety of production resources, then add other deployment (dev & stg) overrides to that base. That makes sense, but it seems a little risky using core for production settings. If a test gateway gets spun up without a deployment mode setting, production connections would be the default. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 2, 2026, 2:42pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/5 "2026-10-02T14:42:40Z")
> [@dkhayes117](#): > > production connections would be the default Deployment modes aren't a substitute for proper network isolation, IMNSHO. Modes can and should supply the alternate targets needed match the isolated environment. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [October 2, 2026, 2:58pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/6 "2026-10-02T14:58:42Z")
Most of my confusion came from every example and demonstration I have found on deployment modes end up showing production/dev separate from core. Fair point on the networking isolation. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [October 2, 2026, 6:37pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/7 "2026-10-02T18:37:39Z")
> [@dkhayes117](#): > > example and demonstration I have found on deployment modes end up showing production/dev separate from core That certainly is a logical design choice. With CI/CD automated workflows, the sky is the limit...for better or for worse. In my preferred, changes to `core` (=prod) also end up in other deployment modes by default - whereby overrides are required in those environments to restrict access (or redirect connections). This might stem from our **current** workflow (subject to change as CI/CD is embraced) - where minor changes are performed directly against the prod gateway. I.e. The prod gateway is the source of truth (not the repo). That design choice might have some undesirable outcomes in your architecture. So, you might decide to create read-only (or undefined) connections in `core` and override them with read/write connections in a dedicated `prod` deployment mode. In a larger SCADA architecture we're building, we're planning to utilize `external` for shared resources between all nodes. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [October 2, 2026, 8:53pm UTC](https://forum.inductiveautomation.com/t/gateway-deployment-modes-use-core-as-development-collection/117256/8 "2026-10-02T20:53:45Z")
Perhaps relevant (and well-timed): [https://forum.inductiveautomation.com/t/8-3-database-connections-configuration-as-code/117318/3?u=chris\_bingham](https://forum.inductiveautomation.com/t/8-3-database-connections-configuration-as-code/117318/3)