One issue that arises with this workflow is that Ignition does not always immediately detect file changes made outside the Designer. After checking out a branch, merging changes, or pulling updates, the gateway will still need a manual file scan from the Gateway before the latest project or configuration files are reflected.

To make development workflows smoother for our projects at DMC, we created a script that uses the Ignition 8.3 Gateway API endpoints to trigger project and configuration file scans. By integrating this script into Git hooks, file scans can run automatically after branch checkouts or merges, eliminating the need to manually navigate to the Gateway webpage and trigger them each time (fig1 and fig2). Additionally, developers can manually run the script from Bash or the command line to trigger file scans on demand.

In this blog, we have provided a sample script and .env file, and we will walk you through the steps to set this up.

Why This Step Matters

There are a variety of reasons why automating this step is both important and beneficial. This automation reduces friction in the development workflow, reducing some of the common sources of errors and delays while improving team-wide consistency and clarity. By using Git hooks to automate file syncing in Ignition, developers avoid repeated trips to the Gateway UI and reduce mental load.

By adding automated file scans into the development workflow, teams can make Ignition 8.3 development feel more like regular software development, where Git-based practices like branching, merging, and pull requests fit naturally into SCADA projects.

Set Up Gateway API Key

In order to access the API endpoint, we need to set up an API key in the Gateway. Follow Ignition’s manual for this.

By default, Ignition requires API keys to be used over secure HTTPS connections. Since this script commonly runs against local development Gateways using standard HTTP, the Require secure connections for API Keys setting must be disabled for the requests to succeed.

Make sure to copy the ENTIRE api key. We will add it to the .env file in the next section.

Repo and Environment Variables Set Up

Copy the example script (included in the section below) into your desired location in your repo. For example, in this repo, we have put it at the following location and called it gateway_scan.py.

Path: ignition-docker-8-3\scripts\gateway_scan

Next, add the following variables to your .env file:

GATEWAY_IP= (your gateway’s IP address)
HTTP_PORT = (your gateway’s port)
GATEWAY_API_TOKEN=(your generated API token for the gateway)

The example script looks for these variables; if they are already in your .env and are named differently, open the example script and do a find-and-replace to update the variable names.

Git Hook Set Up

Git hooks let us automatically run scripts when certain Git actions occur. For this workflow, we typically set up Git hooks to run the gateway_scan.py script after branch checkouts and merges.

This means that when a developer switches branches, pulls changes, or merges updates, the Gateway file scan can run automatically without having to open the Gateway webpage and manually trigger it.

To set this up, create two files in the .git/hooks folder:

.git/hooks/post-checkout
.git/hooks/post-merge

Paste the following code into both files:

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

The post-checkout hook runs after switching branches. The post-merge hook runs after a merge, which also commonly happens when pulling new changes from the remote repository.

The first command moves the terminal to the root of the Git repository. This helps ensure the script runs from the correct location, even if Git triggers the hook from within the repository.

The second command runs the Gateway scan script:

py scripts/gateway_scan/gateway_scan.py

Developers can also run this command manually from Bash or the command line whenever they want to trigger a Gateway file scan on demand.

If the repository contains multiple gateways you want to automatically file scan for, add a separate set of environment variables for each gateway in the .env file, create an API key for each gateway, and then update the gateway_scan.py script following the comments, so the script knows which gateways to scan.

Example Script & env. File

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f""

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f"http://{ip}:{port}/data/api/v1/scan/{action}"

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

Conclusion

Automating file syncs in Ignition 8.3 is a simple configuration change that can deliver meaningful improvements to your development workflow. By reducing manual steps and ensuring the Gateway always reflects the latest project state, teams can work more efficiently and with greater confidence. For engineers using Git to manage their Ignition projects, this approach unlocks the full benefits of modern version control while keeping SCADA development reliable and consistent.

The post Triggering Gateway File Syncs for Ignition 8.3 Using Git Hooks appeared first on DMC, Inc..

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 set up and ready for use. 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.

The post Setting Up Symbolic Links for Shared Project Libraries Across Ignition 8.3 Gateways appeared first on DMC, Inc..