Setting Up Symbolic Links for Shared Project Libraries Across Ignition 8.3 Gateways

Ignition 8.3’s file-based project structure makes it practical to treat gateway resources as standard source-controlled assets, allowing teams to track changes in Git, review diffs, and modify certain files directly outside of the Designer when needed. This level of transparency and control significantly improves the development workflow.

In a recent Ignition 8.3 project, we had two gateways in a single Git repository that needed to share library elements. While 8.3 enables a more Git-centric workflow, it does not provide a built-in mechanism to keep shared resources synchronized across multiple gateways. Without an automatic way to manage this, shared libraries can quickly drift and become difficult to maintain.

We addressed this by creating symbolic links from each gateway’s library folders to a shared “source of truth” directory. A symbolic link (symlink) is a special file that points to another file or folder—like a shortcut at the filesystem level. When you access it, the system transparently redirects you to the target location. This approach allows both gateways to reference the same underlying files while still fitting cleanly into a Git-based workflow, making it a simple, low-friction way to keep shared resources consistent.

This blog walks through how to set up shared libraries between two Ignition gateways in a single Git repository using symlinks on Windows, helping you avoid duplication and keep shared code synchronized in one place.

With this setup, any time a symlinked file is modified in a Designer and saved, it’s immediately overwritten in the shared “source of truth” location. After changes are made and tested in one gateway project’s Designer, the files can be committed and pushed to the repo as usual.

We’ll walk through setting up a shared script library folder as an example. You can use the same pattern to share views, styles, and additional files as needed for your project.

What are Symbolic Links?

A symbolic link, often referred to as a symlink, is a reference point in a filesystem that points one file or folder to another location. Instead of duplicating the files, a symlink acts as a pointer. When an application accesses the symlinked path, the operating system (OS) redirects it to the target destination.

In Ignition 8.3, a symlinked folder behaves exactly like a project directory. Associated scripts, views, and resources load as one would expect; however, the actual files live somewhere else in the filesystem.

Sample Repository Structure

Here is a visual representation of what the structure would look like after the symlinks are set up. The file structure for gateway1 and gateway2 down to script-python is default to ignition. You will have to create the “shared” folder location and structure manually in your repo, and you can organize it anyway you want.

repo/
└── gateways/
   ├── shared/
   │   └── script-python/
   │       └── library/ (real files live here for this example)
   │
   ├── gateway1/
   │   └── projects/
   │       └── project1/
   │           └── ignition/
   │               └── script-python/
   │                   └── library/ -> symlink to ../../../../../shared/script-python/library
   │
   └── gateway2/
       └── projects/
           └── project2/
               └── ignition/
                   └── script-python/
                       └── library/ -> symlink to ../../../../../shared/script-python/library

Setup Steps for Windows

Before creating any symbolic links, complete the following one-time setup steps. Every developer working with this repository must perform these steps on their local machine. Skipping them can result in broken links when the repo is cloned or checked out.

Prerequisites

1. Enable Git symlink support

By default, Git on Windows may treat symlinks as plain text files. This setting ensures symlinks are created and checked out correctly.

Run the following command in Git Bash:

git config --global core.symlinks true

git config --global core.symlinks true

2. Enable Windows Developer Mode

Developer Mode allows non-admin users to create symbolic links without permission-related issues.

Settings > Privacy & Security > For Developers > Developer Mode

Turn Developer Mode on.

3. Restart your computer

Restarting your computer ensures Developer Mode is fully applied before creating symlinks.

Initial Creation of Symbolic Links

Follow the steps below to set up the initial symlinks for the script-python library folder in our example. The same approach can be used for other shared resources.

Gateway 1:

1. Open Command Prompt as an Administrator

2. Navigate to the target directory for your symbolic links

Move to the directory where the symlink will live in Gateway 1: cd gateways\gateway1\projects\project1\ignition\script-python

3. Move any existing library files:

If you already have files in the library folder and/or the library folder exists, move the entire library folder to the shared directory at gateways/shared/script-python. If not, skip this step.

If you leave the library folder here: \gateways\gateway1\projects\project1\ignition\script-python. The following error will occur because Windows cannot create a link where a directory already exists:

4. Create the symbolic link

Run the command below to create the symlink linked to the actual files in the shared location:

mklink /D library ……….\shared\script-python\library

5. Verify the symlink was created successfully

Verify the link has been created by running the command dir at the symlink location in the command prompt. If the symlink was created correctly, then you should see it in your output.

In addition, you can visually verify that the folder was created correctly in File Explorer by looking for the arrow icon in the bottom left. When you double-click into this symlinked folder, it will take you to the location it is linked to.

Gateway 2

Repeat the same steps for Gateway 2, adjusting the path as needed:

cd gateways\gateway2\projects\project2\ignition\script-python

Create the symlink pointing to the same library location.

Once both gateways are linked, the shared library folder is ready for use. Any changes made through one gateway’s Ignition Designer will be written directly to the shared directory and can be committed to Git as usual.

Ignition Designer/Gateway Refresh and Test

After creating the symbolic links, the final step is to confirm that Ignition detects and uses the shared files properly. Because Ignition doesn’t automatically reload filesystem changes, users must manually initiate file and project scans to update each gateway.

1. Close all open Ignition Designer sessions

Closing active sessions of Designer resolves any potential validation interference caused by cached projects.

2. Trigger file and project scans on both Gateways

On each gateway, run the following:

• Platform → Overview → Scan File System
• Platform → System → Projects → Scan Projects

3. Open Ignition Designer for Gateway 1

• Create a new script or modify an existing script in the share library.
• Save the changes.

4. Refresh Gateway 2

• From the Gateway 2 web UI, trigger both the file system scan and project scan again.

5. Open Ignition Developer for Gateway 2

• Open Ignition Developer for the second Gateway and verify that the adjustments are present.

Now the library symlinks are setup and ready to be used. If the changes appear as expected, the symbolic link configuration is working correctly, and both gateways are pulling from the same shared source of truth. Once validated, follow your project’s specific git workflow to push these changes to your repository.

Final Thoughts and Best Practices

It’s important to keep in mind that whenever a file in the gateway filesystem is changed, the gateway doesn’t automatically update to reflect those changes. You will need to perform two file scans for the latest changes to be reflected. The screenshots below show where to trigger these scans.

At some point during testing, you may need to view/test a library file in both gateways. In this scenario, it is important to regularly perform the above file and project scans, as changes are being made and saved. Below is an example of a possible order of operations:

1. Make changes to library file in Gateway 1 project designer.
2. Save changes to library file in Gateway 1 project designer.
3. Open Gateway 2 webpage UI.
4. Press Scan File System on both Platform > Overview page and Platform > System > Projects page for Gateway 2.
5. Open a fresh designer session of Gateway 2’s project to view latest changes.

Keep in mind that if changes are made in both gateways to the same library object, the last place it was saved will be the effective, latest state of the file. In the above example, if a change is made in Gateway 2’s project designer session and saved there, Gateway 1 would have stale library files internally, requiring file scans to refresh them.

To avoid accidentally overwriting changes, the best practice is to separate work into separate commits and modify a given shared file from only one gateway at a time.

Finally, make sure the other developers run through the setup steps on their machines to avoid accidentally breaking any symbolic links during initial setup.