What does each gateway own after the split?
Follow the packet. A Perspective client is a browser session holding a websocket to the frontend gateway. Every binding in a view resolves on the frontend, which forwards tag reads and writes across the Gateway Network to the backend. The backend owns the device connections and the realtime tag provider.
Session load stays on the frontend: view rendering, binding evaluation, session scripts, and message handlers. Polling, tag change scripts, alarm evaluation, and history collection stay on the backend. The whole point of the split is to keep roughly 60 concurrent sessions, plus spikes, from competing with device polling for the same CPU and memory. That division also decides what goes into each repository.
| Resource | Backend gateway | Frontend gateway |
|---|---|---|
| Device connections / drivers | Owns | None |
| Realtime tag providers, UDT definitions | Owns | Remote tag provider only |
| History collection, alarm evaluation | Owns | Consumes over the Gateway Network |
| Perspective projects (views, styles, session events) | None | Owns |
| Tag-driven gateway event scripts | Owns | None |
| Database connections | For history and logging | For UI-side queries only |
Check: inventory every project and every gateway-scoped resource on the current single gateway and assign each one to exactly one column. Anything that seems to need both columns is shared config. Write it down, because it drives the repository decision in the next step.
One repository or two?
Use two repositories, one per gateway role. Each repository maps onto one gateway's data directory: its projects plus whatever file-based configuration the gateway exposes. Git operates on a whole repository at a time, so a pull on the frontend brings in only frontend material and a pull on the backend brings in only backend material.
| Layout | Structure | Strength | Failure mode |
|---|---|---|---|
| Two repos | One repo per gateway, each holding its own config/ and projects/
|
Clean pulls, independent history, clear ownership | A shared change needs a commit in each repo |
| Monorepo, nested per gateway |
backend/config/, backend/projects/, frontend/config/, frontend/projects/
|
A single commit updates shared config on both sides | Each gateway needs only its own subtree. Pulling a subset of a repo is awkward, and it is easy to deploy the wrong subtree |
| Single repo, features disabled per gateway | Identical content on both gateways, with providers and projects toggled off | None worth the risk | The backend carries Perspective projects and the frontend carries disabled device connections. One wrong toggle and both gateways poll the PLC |
Once tags move behind a remote provider, most shared config disappears. The backend owns the tag and UDT definitions, and the frontend sees them through the remote provider. Put whatever is still shared, typically script libraries, in a Git submodule or a third repository that both gateway repos consume.
Check: clone each repository into a scratch directory. The frontend clone must contain no device connections or tag definitions. The backend clone must contain no Perspective views.
How does the frontend reach the backend's tags?
Layer one first. Confirm that the frontend host has a routed path to the backend host and that every firewall between them passes the Gateway Network port. Read that port and the SSL requirement from the backend's Gateway Network settings page rather than assuming a default.
- On the backend, confirm the Gateway Network is enabled. Note the listening port and whether SSL is required.
- On the frontend, create an outgoing Gateway Network connection to the backend host and port.
- On the backend, approve the incoming connection if your security settings require approval.
- Configure service security and security zones on the backend. Grant the frontend read access to the tag provider, and grant write access only where operators actually write.
- On the frontend, create a remote tag provider that points at the backend's realtime provider. Give it the same name as the backend provider so that tag paths in bindings resolve identically on a single gateway and on a split pair.
| Symptom | Hop where it stops | Check |
|---|---|---|
| Connection faulted or never connects | Network or TLS | Test TCP reachability to the port from the frontend host, then check certificate trust |
| Connection running, remote provider empty | Service security | Check the provider's read permission for the frontend's security zone |
| Reads work, writes rejected | Security zone write permission | Grant write on the specific provider |
| Bindings report tag not found | Provider name mismatch | Compare the remote provider name with the provider prefix in the binding paths |
Check: open a Designer on the frontend. The Tag Browser must show the backend's tags with live values. A write from a test view must change the value on the backend tag itself.
Can development stay on a single gateway?
It can, as long as the provider-name contract holds. The trade-off is that several failure classes only appear on a split pair:
- Gateway Network security rejections
- Quality and latency across the remote hop
- Gateway-scoped scripts written into the wrong project
A single dev gateway also produces commits that mix frontend and backend resources. Someone then has to separate them by hand before promotion, which is the error the two-repo layout exists to prevent.
| Dev topology | Advantage | Cost |
|---|---|---|
| Single gateway | One install, fast iteration | Manual resource separation on every commit. Remote-hop faults surface first in test |
| Two gateways (same host or separate) | Commits land in the correct repo. Security and remote-provider behavior are exercised early | Two installs to maintain |
Mirror the test and prod topology in dev. Two small gateways on one host are enough.
Check: a fresh clone of both repositories into the dev pair starts cleanly. The only manual edits should be environment-specific values.
How do changes promote from dev to test to prod?
Run the existing dev/test/prod Git workflow once per repository. Environment-specific values include the frontend's outgoing Gateway Network target, database connection strings, and credentials. These differ at every stage, so keep them out of committed files or isolate them in ignored, per-environment config. A committed backend hostname is the most common promotion break.
Order matters when the tag structure changes:
- For added tags or UDT members, merge and pull the backend repo first. Trigger the gateway's resource scan or restart according to your process.
- Confirm the new tags exist on the backend.
- Merge and pull the frontend repo so the new bindings find their targets.
- For removed tags, reverse the order. Remove the frontend bindings first, then remove the tags on the backend.
Check: git status is clean on both gateways after the pull. Any diff that appears later comes from an edit made directly in a gateway. Commit it back or revert it.
What proves the split works end to end?
- Layer one: the backend's Gateway Network port is reachable from the frontend host.
- Connection status: the Gateway Network connection shows running on both gateways.
- Tag visibility: the frontend's remote provider shows the same tag tree as the backend provider.
- Bindings: in a Perspective session on the frontend, every binding on a representative view shows good quality.
- Writes: a write from the session lands on the backend tag and the value is visible on the backend.
- Load test: open sessions up to the normal concurrent count plus spike margin. Watch CPU and memory on the frontend's status page, and confirm that backend device polling and tag throughput do not degrade.
- Git state: both repositories are clean and tagged at the released commit, and each gateway's deployed content matches that tag.
FAQ
Can I use one Git repo for both Ignition frontend and backend gateways?
Yes, if each gateway's config and projects sit in their own nested subtree so that one commit can update shared config on both sides. The catch is that each gateway needs only its subtree, and pulling a subset of a repo is awkward. Two repositories avoid that problem.
Does the frontend gateway need its own device connections?
No. The backend owns every device connection and realtime tag provider. The frontend reads and writes those tags through a remote tag provider over the Gateway Network, which keeps session load from competing with polling.
Can I develop on a single Ignition gateway and split only in test and prod?
You can if the frontend's remote tag provider carries the same name as the backend provider. You will then separate resources by hand on every commit and first meet Gateway Network security and remote-hop faults in test, so a two-gateway dev pair is the safer choice.
Does a remote tag provider change my Perspective tag paths?
Not if the remote provider on the frontend has the same name as the backend's realtime provider. The provider prefix in each binding path then resolves identically on a single gateway and on a split pair.
Can shared script libraries live in both gateway repos?
Put them in a Git submodule or a separate repository that both gateway repos consume, so a single change reaches both gateways. Copying them into each repo works too, but every change then needs two commits and the copies drift apart.