# New installed module in Ignition 8.1.5 docker container is gone after container reboot **URL:** \ **Category:** Ignition\ **Created:** [June 4, 2021, 9:27pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482 "2021-06-04T21:27:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![zhangxucuit](https://avatars.discourse-cdn.com/v4/letter/z/f19dbf/32.png) [@zhangxucuit](https://forum.inductiveautomation.com/u/zhangxucuit)\ **Post date:** [June 4, 2021, 9:27pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/1 "2021-06-04T21:27:22Z")
I am running ignition 8.1.5 in docker on MacOS Mojave, with a named volume attached to `/usr/local/bin/ignition/data` within the container. Today I was successfully installed MQTT distributor module, however this module go away after container reboot, I guess attach `/usr/local/bin/ignition/data` folder is not enough, any workaround? ---
**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:** [June 4, 2021, 9:49pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/2 "2021-06-04T21:49:06Z")
Modules are located in `/usr/local/bin/ignition/user-lib/modules/` by default. ---
**Author:** ![zhangxucuit](https://avatars.discourse-cdn.com/v4/letter/z/f19dbf/32.png) [@zhangxucuit](https://forum.inductiveautomation.com/u/zhangxucuit)\ **Post date:** [June 4, 2021, 10:00pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/3 "2021-06-04T22:00:43Z")
It’s works, it would be wonderful to update the doc in docker hub as well ([Docker Hub](https://hub.docker.com/r/inductiveautomation/ignition)) ---
**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:** [June 4, 2021, 10:47pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/4 "2021-06-04T22:47:33Z")
We have a ticket in the works for better support of third-party modules in a container. Currently the system locates all modules at `/usr/local/bin/ignition/user-lib/modules/`, like @paul-griffith mentioned. Choosing the `/usr/local/bin/ignition/data/` path for your named volume _is_ the correct strategy for preserving gateway state. The `user-lib/modules` should stay “with” the image (of version 8.1.5, for example) so that you can upgrade your deployment by just swapping image versions (and keeping your _data_ volume). The best method right-now is to bind-mount the module directly into `/usr/local/bin/ignition/user-lib/modules`. See the example screenshot below: ![2021-06-04 at 5.43 PM](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/4/243ebb93e7cf30a821faa6bb7df583c3acbe582f.png) Once you start your container with this setup, you’ll then need to go to the gateway webpage (_Config-\>Modules_) and accept the EULA and certificate to conclude the module installation. The good news is that with this strategy, you can still upgrade to newer versions by just stopping/removing this container, and starting a newer one (such as `inductiveautomation/ignition:8.1.7`) in its place against the same _data_ volume. Another alternative is to build your own derived image where you’ve copied that module into place. Then upgrading would simply be a matter of changing the `FROM` directive in the `Dockerfile` and then rebuilding your image, and then relaunching your container (again, still using your _data_ volume). ---
**Author:** ![321liftoff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/321liftoff/32/27544_2.png) [@321liftoff](https://forum.inductiveautomation.com/u/321liftoff)\ **Post date:** [August 28, 2025, 6:17pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/5 "2025-08-28T18:17:54Z")
@kcollins Has this been improved over the past few years? The [documentation here](https://docs.inductiveautomation.com/docs/8.1/platform/docker-image#integrate-third-party-modules-after-an-upgrade) has no mention of the the technique you listed above, which may be easier for some. Could the documentation be re-organized to have a section titled “How to preserve your state across container restarts” and include steps that are needed for all things that could get modified to persist across reboots? For modules specifically, seems it would be best for Ignition to allow mounting docker volume against a directory for 3rd party modules to land in. ---
**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:** [August 28, 2025, 9:38pm UTC](https://forum.inductiveautomation.com/t/new-installed-module-in-ignition-8-1-5-docker-container-is-gone-after-container-reboot/47482/6 "2025-08-28T21:38:16Z")
This is vastly improved with Ignition 8.3. Here are some feature highlights: - When running the container image, modules that are installed through the Web UI end up in a folder that is within the `data` volume (specifically, `/usr/local/bin/ignition/data/var/ignition/modl`). - If you happen to install a module with the same module ID as a built-in module, it will "shadow" the built-in module and load from your external folder. Note that in this situation, uninstalling the module will simply revert to the built-in module. This is probably a rare situation but perhaps worthy of mention. - _Uninstallation_ of built-in images (located in the traditional location of `/usr/local/bin/ignition/user-lib/modules`) is blocked since these modules are part of the image itself. - Enable/disable of any module is persisted in the module configuration file under `data/modules.json` - If you’re using `GATEWAY_MODULES_ENABLED` env var, changes to enable/disable status of any module is blocked. Note: use of this var used to be required in order to keep built-in modules from popping back to life after container recreation, but that is no longer a problem. - There are new `ACCEPT_MODULE_LICENSES` and `ACCEPT_MODULE_CERTS` environment variables that will accept fully qualified module identifiers to automate module license/cert acceptance on startup. The module ID of a given module can be discovered with this helpful little shell snippet (substituting the path to your module file): ```bash unzip -c -q path/to/module.modl module.xml | \ xmlstarlet sel -t -v "modules/module/id" -nl ``` The result is that you no longer need special handling for third-party modules. As long as you're persisting your data volume, module installations (that flow to that new folder) and enable/disable changes will stay put as expected, just like a traditional installation.