# Preserving Sideloaded Resources persisting in Gateway Backup

**URL:** <https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777>\
**Category:** Ignition\
**Tags:** scripting\
**Created:** [November 6, 2026, 5:30pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777 "2026-11-06T17:30:40Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Julian\_Islic](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/julian_islic/32/57055_2.png) [@Julian\_Islic](https://forum.inductiveautomation.com/u/Julian_Islic)\
**Post date:** [November 6, 2026, 5:30pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777/1 "2026-11-06T17:30:40Z")

</div>

Hey Ignition Gurus,

Time and time again we are put in the situation where we have to sideload some jar/dll files into ignition/lib/\* in order to gain connectivity with platforms that ignition does not support by default.

Up till now, we have just been putting these additions into maintenance manuals to ensure the customer doesn't get screwed when restoring a gateway backup on a new server.

However, in these scenarios, the application won't be restored.

- If the manual gets lost
- They simply don't read the manual
- Sideloaded files are lost

Is there a proper way to keep sideloaded jars/dll in the ignition/lib files present in the gateway backups so we don't have to maintain instructions on how to include specific dependancies?

---

<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:** [November 6, 2026, 6:10pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777/2 "2026-11-06T18:10:24Z")

</div>

Get your LLM of choice to write you a module.

---

<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:** [November 6, 2026, 6:16pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777/3 "2026-11-06T18:16:41Z")

</div>

Well, the module won't end up in a gateway backup either, but it is a lot easier to tell a client to install such-and-such module. You can even write a gateway startup script that looks for a specific module ID and reports if it is missing from the install.

---

<div class="post-metadata">

**Author:** ![Noah\_Burnette](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/noah_burnette/32/83777_2.png) [@Noah\_Burnette](https://forum.inductiveautomation.com/u/Noah_Burnette)\
**Post date:** [November 6, 2026, 7:35pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777/4 "2026-11-06T19:35:08Z")

</div>

Another alternative is to use containerization and build it into the image. Something like:

```python
# Example file structure
Dockerfile
modules/
jars/

```

```Dockerfile
FROM inductiveautomation/ignition:8.3.10

COPY modules/*.modl /usr/local/bin/ignition/user-lib/modules/

COPY jars/*.jar /usr/local/bin/ignition/lib/core/common/ # fits most use cases

```

---

<div class="post-metadata">

**Author:** ![Julian\_Islic](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/julian_islic/32/57055_2.png) [@Julian\_Islic](https://forum.inductiveautomation.com/u/Julian_Islic)\
**Post date:** [November 6, 2026, 9:20pm UTC](https://forum.inductiveautomation.com/t/preserving-sideloaded-resources-persisting-in-gateway-backup/117777/5 "2026-11-06T21:20:31Z")

</div>

I wish i could containerize, but unfortunately some of my dependencies are windows only ;(

That being said, I haven't thought of packaging a 1 click install script. This would be a lot easier than instructions for customer.