Demiton LogoDemiton
Back to all articles
Git for PLCs is Not Enough: Why Governance is the Missing Layer

Git for PLCs is Not Enough: Why Governance is the Missing Layer

By Justin Trollip, Founder of Demiton on 23 June 2025

industrial automation
devops
git
copia
plc programming
governance
change control
gmp
audit

For years, the world of industrial automation has been stuck in the dark ages when it comes to managing code. While the software world embraced tools like Git for powerful version control and collaboration, controls engineers were left saving files as Project_Final_v2_Johns_Changes.acd on a shared drive.

Recently, a new generation of tools has emerged to fix this, with Copia leading the charge. They've done a phenomenal job of bringing the power of Git—branching, merging, and visual diffing—to the PLC world. It's a massive leap forward, and for a pure development team, it's a game-changer.

This often leads to a question we get at Demiton: "You have version control and diffing. How are you different from Copia?"

It's a great question, and the answer gets to the very heart of the problem we're solving.

Copia is an excellent development tool. Demiton is a complete operational governance platform.

Copia perfects the "inner loop" of an engineer writing and managing code. Demiton manages the "outer loop" of how that code is approved, deployed, and proven to be running correctly in a validated, production environment.

Solving the developer's version control problem is only the first step. For a regulated manufacturer, it's not enough to know what changed. You have to prove why it was changed, who approved it, and that the right version is running on the right machine right now.

Let's break down the three critical layers of governance that exist on top of simple version control.

1. The Problem: Version Control vs. Change Control

Imagine an engineer uses a Git-based tool to create a new version of a PLC program. They commit their changes with a clear message: "Optimized pump cycle."

This is great for the engineering team. But for Sarah, the QA Manager in a GMP facility, it raises terrifying questions:

  • Did anyone approve this change?
  • Was a risk assessment performed?
  • Is this new version validated for use in a production run?
  • How do I stop the engineer from loading this unapproved code onto the validated production machine on the night shift?

Git is a system of record for code history. It is not a system of enforcement for process adherence.

This is where Demiton provides the "Active Governance Layer." A new version of code in Demiton is just a draft. To get it onto a machine, it must go through a formal, auditable workflow:

  1. A Deployment Request is created, linking the new code version to a specific device and requiring a justification for the change.
  2. A designated manager (like Sarah) receives a notification. They review the side-by-side diff and the justification before providing a 21 CFR Part 11-compliant electronic signature to approve it.
  3. Only after approval is the code made available for deployment.

Copia answers "what changed in the code?" Demiton answers "was this change authorized to be deployed to a validated production asset?" For an auditor, only the second question matters.

2. The Problem: Passive History vs. Real-Time State

A version control system is a passive database. It can tell you what the code should be, but it has no idea what is actually running on the PLC on the factory floor right now.

What happens if a maintenance technician connects their laptop at 2 AM to bypass a faulty sensor and forgets to revert the change?

  • Your Git repository says the machine should be running v2.0.
  • The machine is actually running v2.0_temp_fix.
  • This discrepancy, known as configuration drift, can lead to a million-dollar batch failure or a critical audit finding. No version control system can prevent this on its own.

Demiton is a System of Action, not just a System of Record. Our on-site Gateway continuously monitors the real state of your devices.

  • When it detects a deviation from the approved "Golden Record," it doesn't just log it.
  • It can be configured to instantly and automatically revert the change, writing the correct, validated parameters back to the device and preventing a bad batch before it even starts.

Copia provides a history of what the code was. Demiton provides active assurance of what the code is.

3. The Problem: A Dev Tool vs. An Operations Hub

Git is designed for developers. Your plant manager, QA lead, and maintenance technicians are not developers. They will not be cloning repos, managing branches, or using the command line.

They need a simple, centralized hub that gives them the information they need to do their jobs. They need to know the maintenance history of a machine, access its manuals, and see its compliance status.

Demiton is the Command Center for the entire asset lifecycle. We link everything together:

  • The Function Blocks (the code).
  • The Deployment Requests (the change control).
  • The Job Dockets (the maintenance history).
  • The Validation Reports (the "Certifications").
  • The physical Asset itself.

All of this is accessible from a simple web interface, tied to the real-world asset.

Better Together: The Path Forward

Copia is a fantastic tool that solves a real problem for development teams. But for a facility that needs to prove compliance, manage change across multiple stakeholders, and actively govern its production environment, a Git client is not enough.

You need a platform that manages the entire lifecycle of your operational code—from creation, to approval, to deployment, to real-time monitoring.

Demiton doesn't just version your code; it governs your operation.


Ready to move beyond version control and implement true operational governance? Schedule a demo with our team.