# Docker Image: Custom UID/GID for running as non-root

**URL:** <https://forum.inductiveautomation.com/t/docker-image-custom-uid-gid-for-running-as-non-root/58238>\
**Category:** Ignition Early Access\
**Tags:** ignition81\
**Created:** [April 8, 2022, 9:15pm UTC](https://forum.inductiveautomation.com/t/docker-image-custom-uid-gid-for-running-as-non-root/58238 "2022-04-08T21:15:53Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\
**Post date:** [April 8, 2022, 9:15pm UTC](https://forum.inductiveautomation.com/t/docker-image-custom-uid-gid-for-running-as-non-root/58238/1 "2022-04-08T21:15:53Z")

</div>

Greetings container users! I wanted to drop some additional context on an upcoming enhancement to the official Ignition Docker image. In the nightly builds right now, there is support for two new environment variables that can be used to drive the user ID (UID) and group ID (GID) of the running gateway process in the container. When left undefined, the container will continue to launch as root as it did before.

| variable name | type | description |
| --- | --- | --- |
| `IGNITION_UID` | integer | Numeric ID of user to launch gateway, i.e. `999` |
| `IGNITION_GID` | integer | Numeric ID of group to launch gateway, i.e `999` |

This means you should be able to launch an image like so:

```shell
$ docker run -d -p 8088:8088 \
    -e IGNITION_UID=999 -e IGNITION_GID=999 \
    -v forum-xxxx-data:/usr/local/bin/ignition/data \
    --pull always \
    inductiveautomation/ignition:nightly

```

When it starts, the entrypoint will re-map the built-in `ignition` user/group within the image to `999:999`. Additionally, filesystem permissions for the Ignition installation will be updated to match the user/group ownership. This will take a few moments when the container starts up. Subsequent restarts of that container will not incur that initial re-mapping delay. If you do re-create the container (to change configuration, leaning on your preserved data volume for your gateway state), you'll observe another short delay as filesystem ownerships (from the base image contents, now fresh again) are once more updated.

If you'd like to build your own derived image to bake-in these environment variables, it is pretty to achieve with a `Dockerfile` such as the one below (EDIT: be warned that this does have the unfortunate circumstance of increasing the image size substantially due to the extra image layer being generated):

```python
FROM inductiveautomation/ignition:nightly

ARG IGNITION_UID
ARG IGNITION_GID
ENV IGNITION_UID=${IGNITION_UID:-999} \
    IGNITION_GID=${IGNITION_GID:-999}

RUN chown -R ${IGNITION_UID}:${IGNITION_GID} ${IGNITION_INSTALL_LOCATION:?expected in environment}

```

You could then build this with:

```shell
$ docker build . --build-arg IGNITION_UID=1002 \
    --build-arg IGNITION_GID=1002 \
    -t <organization>/ignition:nightly

```

I hope this feature helps those who are leveraging bind-mounts back to their host (with specific permissions) align the container's UID/GID with their host system.

Enjoy!

---

<div class="post-metadata">

**Author:** ![vladimir](https://avatars.discourse-cdn.com/v4/letter/v/94ad74/32.png) [@vladimir](https://forum.inductiveautomation.com/u/vladimir)\
**Post date:** [January 3, 2026, 1:46am UTC](https://forum.inductiveautomation.com/t/docker-image-custom-uid-gid-for-running-as-non-root/58238/2 "2026-01-03T01:46:37Z")

</div>

docker run might be missing -p argument for ports, should be:

docker run -d -p 8088:8088 \