# Ignition Gateway Instance on Docker

**URL:** <https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202>\
**Category:** Ignition\
**Tags:** docker, vision\
**Created:** [January 12, 2026, 12:07am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202 "2026-01-12T00:07:57Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![baye](https://avatars.discourse-cdn.com/v4/letter/b/df788c/32.png) [@baye](https://forum.inductiveautomation.com/u/baye)\
**Post date:** [January 12, 2026, 12:07am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/1 "2026-01-12T00:07:57Z")

</div>

We are looking into converting/Migrating our Ignition instances from WINDOZE to Linux. As part of that we started looking at Ignition Docker images from Inductive Automation Repo.

Has anyone braved enough to run their production architecture with Docker?

I’ve been using Docker for about seven years and know enough to be dangerous. (Even build somes Docker images from scratch for some of the Oracle Applications such as APEX and ORDS on Tomcat).

It was so much easier with Ignition since Inductive automation has already build Docker Images to be consume, it was such a no brainer.

With that being said, my vision is to have Docker Engine running on Ubuntu host where we will deployed Ignition Docker Image with Docker Volume mounted at run time for “Stateful” container.

Is it a “fever dream” and I should just stick to either WINDOZE or vanilla Linux?

Note: Of course we will test the heck out of this regardless of going to vanilla Linux or Docker.

---

<div class="post-metadata">

**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:** [January 12, 2026, 12:15am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/2 "2026-01-12T00:15:00Z")

</div>

It can be challenging to use a permanent license with Docker deployments. If you get leased licenses, and don't mind maintaining internet connectivity for lease checks, go for it.

But, for this reason, I would not recommend it for gateways placed on your isolated or semi-isolated OT networks.

---

<div class="post-metadata">

**Author:** ![baye](https://avatars.discourse-cdn.com/v4/letter/b/df788c/32.png) [@baye](https://forum.inductiveautomation.com/u/baye)\
**Post date:** [January 12, 2026, 1:03am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/3 "2026-01-12T01:03:04Z")

</div>

Would you be able to elaborate more on “challenging to use a permanent license with Docker deployments.”, please?

---

<div class="post-metadata">

**Author:** ![baye](https://avatars.discourse-cdn.com/v4/letter/b/df788c/32.png) [@baye](https://forum.inductiveautomation.com/u/baye)\
**Post date:** [January 12, 2026, 1:08am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/4 "2026-01-12T01:08:14Z")

</div>

> [@pturmel](#):
>
> It can be challenging to use a permanent license with Docker deployments. If you get leased licenses, and don't mind maintaining internet connectivity for lease checks, go for it.
> 
> But, for this reason, I would not recommend it for gateways placed on your isolated or semi-isolated OT networks.

I get it now, The license must be tie to an actual host name where with Docker container, it is container ID. (Am I in the ballpark?)

---

<div class="post-metadata">

**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:** [January 12, 2026, 1:30am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/5 "2026-01-12T01:30:06Z")

</div>

A permanent license places critical information in the filesystem, and is tied to root filesystem unique properties (and various other undocumented items). These properties change in many container restart/rebuild situations, even with a persistent volume. You are extremely likely to break your license and need IA support to reset it.

---

<div class="post-metadata">

**Author:** ![David\_Stone](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/david_stone/32/79749_2.png) [@David\_Stone](https://forum.inductiveautomation.com/u/David_Stone)\
**Post date:** [January 12, 2026, 2:16am UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/6 "2026-01-12T02:16:31Z")

</div>

If you delete your docker container and make a new one, you will lose the license activation. Using the 8-Character license key and the online tethering with it enables you to reuse the license key on the new container provided there is only one container running that license at one time.

---

<div class="post-metadata">

**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\
**Post date:** [January 12, 2026, 8:02pm UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/7 "2026-01-12T20:02:46Z")

</div>

Note for posterity, with 8-char licenses, one would have to add [leased activation session termination](https://docs.inductiveautomation.com/docs/8.3/appendix/reference-pages/gateway-configuration-file-reference#leased-activation-session-termination) to immediately release the activation back to the pool upon gateway shutdown.

---

<div class="post-metadata">

**Author:** ![baye](https://avatars.discourse-cdn.com/v4/letter/b/df788c/32.png) [@baye](https://forum.inductiveautomation.com/u/baye)\
**Post date:** [January 13, 2026, 3:25pm UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/8 "2026-01-13T15:25:33Z")

</div>

Yeesh, I’ll stick to vanilla Linux for our deployment model then. Shame because I really like using Docker for streamlining applications or services deployment.

---

<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:** [January 15, 2026, 3:00pm UTC](https://forum.inductiveautomation.com/t/ignition-gateway-instance-on-docker/113202/9 "2026-01-15T15:00:29Z")

</div>

> [@Eric\_Knorr](#):
>
> Note for posterity, with 8-char licenses, one would have to add [leased activation session termination](https://docs.inductiveautomation.com/docs/8.3/appendix/reference-pages/gateway-configuration-file-reference#leased-activation-session-termination) to immediately release the activation back to the pool upon gateway shutdown.

One additional point of clarification here--as long as you're persisting the data volume for a given Ignition "installation", recreating the container poses no risk to an active lease for your 8-digit license. When the license session is obtained, it is persisted to disk under the `data/leased-activation` folder; upon startup, that license session will be resumed if it is still valid.

The situation Eric and David describe is if you're fully wiping both your container and the underlying data volume in order to recreate from scratch; in this type of scenario, common in development, you may wish to leverage the automatic session termination so that a clean shutdown actually reaches out to the license server and releases that active session (making it available for a separate, fresh Ignition container).
