# Deployment Modes and resource definition UUIDs

**URL:** <https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966>\
**Category:** Ignition\
**Created:** [April 8, 2026, 9:41pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966 "2026-04-08T21:41:29Z")\
**Posts on this page:** 14\
**Page:** 1

<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:** [April 8, 2026, 9:41pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/1 "2026-04-08T21:41:30Z")

</div>

stating assumptions here prior to testing, perhaps for discussion about intent vs behavior

- it appears _default_ `core` resource.json files don't contain UUIDs
- it appears manually duplicating resource definitions across deployment modes in in Web UI generates **unique** UUIDs
  - but perhaps with no author/timestamp/signature

- presumably **identical** UUIDs across deployment modes are fine (e.g. copy a mode in the file system)
  - unsure if gateway will modify on startup/scan

- presumably **omitting** UUIDs from resource definitions is fine
  - unsure if gateway will generate on startup/scan

- i generally like to track resource.json since they're useful for author/timestamp/signature (e.g., when a resource is "saved" with no changes) but perhaps they're less useful in deployment modes

longstanding curiousity - why is `lastModificationSignature` not `lastModification.signature` (guessing just historical precedent)

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 8, 2026, 9:57pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/2 "2026-04-08T21:57:41Z")

</div>

> [@hunterdg](#):
>
> it appears _default_ `core` resource.json files don't contain UUIDs

Which resources are you not seeing with UUIDs? Every **named** resource should be getting a UUID on creation.

> [@hunterdg](#):
>
> it appears manually duplicating resource definitions across deployment modes in in Web UI generates **unique** UUIDs

Correct.

> [@hunterdg](#):
>
> but perhaps with no author/timestamp/signature

The UUID attribute is not related to the signature tracking/last modification stuff.

> [@hunterdg](#):
>
> presumably **identical** UUIDs across deployment modes are fine (e.g. copy a mode in the file system)

Between deployment modes is probably fine, but I wouldn't recommend it. Each resource in each location (across deployment modes) should have a unique UUID.

> [@hunterdg](#):
>
> presumably **omitting** UUIDs from resource definitions is fine

It depends on exactly which resource type. Different subsystems "opt in" to whether they care about the UUID; the only thing the UUID is used for at present is to track renames more intelligently, because some things need to care about that.  
For instance, if you rename an internal historian, that means a file on disk that contains stored history needs to get moved. Without the UUID matching on both sides, we would see the rename as though `my-old-historian` got deleted and a brand new `my-new-historian` got created. Per the documentation on the `NamedResourceHandler` that does the bookkeeping automatically, if you don't have a UUID key _on a resource that cares about renames_, then your resource is just ignored and treated as if it doesn't exist. And no attempt will be made to modify your resource to add a UUID key until something else in the system touches it.

> [@hunterdg](#):
>
> i generally like to track resource.json since they're useful for author/timestamp/signature (e.g., when a resource is "saved" with no changes) but perhaps they're less useful in deployment modes

You should still track resource.json files, even though the `lastModificationSignature` is a perennial annoyance. Anything else is not 'safe'.

---

<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:** [April 8, 2026, 10:05pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/3 "2026-04-08T22:05:03Z")

</div>

> [@paul-griffith](#):
>
> Which resources are you not seeing with UUIDs? Every **named** resource should be getting a UUID on creation.

```python
core/ignition/system-properties/resource.json
core/ignition/security-properties/resource.json
core/ignition/security-levels/resource.json

```

(i happen to be overriding these, haven't looked elsewhere)

---

<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:** [April 8, 2026, 10:07pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/4 "2026-04-08T22:07:24Z")

</div>

> [@paul-griffith](#):
>
> Between deployment modes is probably fine, but I wouldn't recommend it. Each resource in each location (across deployment modes) should have a unique UUID.

FWIW, identical uuids seem much more likely when using the `external` mode, as that basically _requires_ a manual copy/paste from somewhere

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 8, 2026, 10:09pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/5 "2026-04-08T22:09:20Z")

</div>

> [@hunterdg](#):
>
> ```python
> core/ignition/system-properties/resource.json
> core/ignition/security-properties/resource.json
> core/ignition/security-levels/resource.json
> 
> ```

Those are fine - they're not 'named' resources, so there's no way to "re" name them. Thus, no UUID.

> [@hunterdg](#):
>
> FWIW, "identical" uuids seem much more likely when using the 'external' mode, as that basically _requires_ a manual copy/paste from somewhere

Yeah, that's fair. But again, probably not a problem in practice - nothing inside Ignition can update `external`.

---

<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:** [April 8, 2026, 10:10pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/6 "2026-04-08T22:10:39Z")

</div>

> [@paul-griffith](#):
>
> Those are fine - they're not 'named' resources, so there's no way to "re" name them. Thus, no UUID.

ah i see your point (singleton?), but they do get UUIDs when overridden/duplicated into custom deployment modes

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 8, 2026, 10:20pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/7 "2026-04-08T22:20:09Z")

</div>

Got it, yeah, that's probably just a minor bug in the duplicate logic.

---

<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:** [April 13, 2026, 12:44pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/8 "2026-04-13T12:44:22Z")

</div>

well, unsure if i should create a new thread, but it also appears impossible to deploy a "fresh" gateway directly into a custom deployment mode without an automated password reset being performed (and temp IDP/user sources being created)

I suppose i get that the gateway needs to be 'commissioned' in order to create the 'default' IDP/User source in `core` but i had hoped the username/password env vars would do that, even though I'm never "booting" into core.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 13, 2026, 3:58pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/9 "2026-04-13T15:58:40Z")

</div>

Commissioning is about more than just the username/password, it's also where we present the EULA. If you pinky-swear to have reviewed it on another machine it's possible to bypass it:

> **[Example​ - ZIP File Installations | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/getting-started/installing-and-upgrading/zip-file-installations#example)**
>
> Aside from the graphical installers, our downloads page features ZIP files that can be used to install and run Ignition. The ZIP file installation process differs from the graphical installation process. Using the ZIP files to install involves...

We're still going to always create the username/password you seed in via env variable into core as far as I know.

---

<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:** [April 13, 2026, 6:12pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/10 "2026-04-13T18:12:47Z")

</div>

well, I "accept" the EULA via env var as well, but i see your point about `commissioning.json`

I guess my question/comment is more specifically - it appears 'booting' the docker image _ **directly** _ into a predefined custom deployment mode (or expecting core to inherit predefined user-source/IDP from external) doesn't work (a password reset is triggered that creates the temp user source/idp in core and nukes the custom user sources/IDPs (overwrites my custom mode's `security-properties/config.json`)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/7/c714845772a5d171864e146eba7a43b99fdc5cc9.png)

if this is (or will/is intended to be) a supported use case (without first booting into core) - it doesn't appear to work now.

```python
  environment: &ignition-env
    ACCEPT_IGNITION_EULA: "${ACCEPT_IGNITION_EULA:-Y}"
    GATEWAY_ADMIN_USERNAME: "${GATEWAY_ADMIN_USERNAME:-admin}"
    GATEWAY_ADMIN_PASSWORD_FILE: "/run/secrets/gateway-admin-password"
    IGNITION_EDITION: "${IGNITION_EDITION:-standard}" # standard, edge, maker
    DISABLE_QUICKSTART: "${DISABLE_QUICKSTART:-true}" # true or false
    TZ: "${TZ:-America/Chicago}" # set timezone, e.g., America/Chicago

    # CUSTOM environment variable to specify deployment mode, used in ignition-init.sh to set Ignition config mode dynamically instead of hardcoding it in the command (below)
    # will be officially supported in future docker images - https://forum.inductiveautomation.com/t/disable-devices-in-gateway-startup-script-v8-3-0/111599/10?u=hunterdg)
    DEPLOYMENT_MODE: "${DEPLOYMENT_MODE:-}"

```

> [@paul-griffith](#):
>
> We're still going to always create the username/password you seed in via env variable into core as far as I know.

guess it boils down to - this behavior appears to be different if deployment mode is specified/external mode is configured - (does a password reset) vs not (puts it in core.default)

(i was hoping to NOT have to source control core - or stage a commissioning.json for that matter)

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 13, 2026, 11:04pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/11 "2026-04-13T23:04:36Z")

</div>

Okay, yeah, this is a thing I recently helped clarify for someone from Sepasoft.  
Basically, it boils down to this:  
When you provide a username and password via environment variable, we have to store that **somewhere**. What we chose to do is put them in `core/ignition/security-properties`.

In principle, if you seed a `commissioning.json` that says you've already commissioned and accepted the EULA _and_ you have a valid admin user in `external/ignition/security-properties` (or whatever file) _and_ you are **not** passing admin credentials via env variable,  
**then** I would expect you to not have to commission.

If that's not working (and you can boil it down to an SSCCE) I'd appreciate it if you could send it in to support and we can see if there's some way we can iron things out. But in general, from what I remember when this last came up:  
You can **either** preconfigure system login via `external` **or** via the environment variables. It's trying to do both that gets you into trouble.

---

<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:** [April 13, 2026, 11:20pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/12 "2026-04-13T23:20:27Z")

</div>

if I _don't_ pass env vars, it lets me manually commission, but kicks off a password reset anyway (and doesn't create `core/ignition/security-properties.json`)

I assume the commissioning.json will work, just 😕

thanks for the feedback 🙏🏻

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [April 23, 2026, 11:51pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/13 "2026-04-23T23:51:10Z")

</div>

> [@paul-griffith](#):
>
> EULA. If you pinky-swear to have reviewed it

Wait, there's a EULA when you commission a gateway??? I thought there were only "Next" buttons?

---

<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:** [June 17, 2026, 10:54pm UTC](https://forum.inductiveautomation.com/t/deployment-modes-and-resource-definition-uuids/114966/14 "2026-06-17T22:54:37Z")

</div>

update: looks like this behavior has changed (thankfully) in 8.3.6

- I no longer experience a forced password reset when specifying Deployment mode (with valid user source) at first run 🎉
- I still need to seed a "real" `commissioning.json` - but somehow @Eric_Knorr/@Tyler_Earnest [get away with an empty one](https://github.com/ia-eknorr/project-template/blob/09cd5669821a033eee8552cf5588f3fc604965c6/scripts/docker-bootstrap.sh#L18)
- try as i might, it seems impossible to end up with an **empty** core "mode" - it seems to be generated if it isn't found 🤷‍♂️