TwinCAT Build Tools Landscape 2026: What Exists (and Why You Probably Need Better)

TL;DR TwinCAT has no built-in CI/CD. Most teams get by with local IDE builds until something breaks - an engineer leaves, a deployment goes sideways at 2 AM, or a customer asks for traceability you don’t have. Your real options are: build a pipeline yourself with Jenkins or GitHub Actions (takes weeks, requires ongoing maintenance, TwinCAT knowledge not included), or use a cloud service that already handles TwinCAT (~€150/month, dedicated build node, unlimited builds, data deleted after every build). Start before the pain hits.

Automation is probably a decade behind the rest of software when it comes to tooling. Anyone who’s worked in both worlds already knows this. TwinCAT is one of the better PLC environments out there, but the story for building, testing, and shipping still basically ends at “open the IDE and click build.”

In most software teams, automated builds, reproducible artifacts, and deployment audit trails are baseline expectations - not something you set up when you have time. In PLC development, they’re still considered advanced practice.

The default workflow at most shops is: write code locally, test on dev hardware if you’re lucky, deploy and hope. That works fine when it’s just you and a simple machine. It starts falling apart once you have multiple engineers on the same codebase, a customer asking for documentation, or any kind of regulatory requirement around traceability.

The root issue is that Beckhoff gives you a great IDE. Everything around it - version control integration, reproducible builds, test automation, artifact management - is your problem to figure out.

The Current Landscape

1. Local TwinCAT IDE Builds (what most people do)

You develop locally, build locally, and probably have a network drive somewhere with “v2_final_FINAL” sitting in a folder. This is fine at small scale. Every TwinCAT engineer already knows how to use it, and there’s nothing to set up.

The cracks appear when someone new joins and can’t reproduce the build because their IDE version is slightly different. Or when the senior engineer goes on holiday and takes all the context with them. There’s no test automation, no audit trail, no record of what changed between versions. It works right up until it doesn’t.

2. Self-Hosted Jenkins + DIY Tooling

You spin up Jenkins, write some tooling around TwinCAT’s Automation Interface, wire it to Git, and now you have CI/CD. Technically.

This requires someone who knows both Jenkins and TwinCAT well enough to build and maintain the pipeline. That’s not a common combination. The Automation Interface is also - putting it charitably - not the most pleasant thing to automate on top of. It gets the job done, but you’ll hit rough edges.

The bigger issue is long-term ownership. You built it, you maintain it. Security patches, Jenkins upgrades, the build scripts, the custom logic - all yours. It has a way of becoming the thing one person set up years ago that nobody else really understands.

3. GitHub Actions / GitLab CI

If your team is already in GitHub or GitLab, reaching for their CI/CD is the natural move. But TwinCAT adds friction that doesn’t exist for regular software.

TwinCAT needs Windows and Visual Studio to build. You can’t run on GitHub’s shared infrastructure - you need to register and maintain your own Windows build agent. There’s also no ready-made action for “build a TwinCAT project and run its unit tests.” That ecosystem just doesn’t exist yet, so you’re building it yourself. It’s a modern setup in principle. In practice you’re spending several weeks building what you assumed was already there.

4. Zeugwerk CI/CD (Cloud)

The alternative is to use a service that’s already solved the TwinCAT build problem. You keep your code wherever it is - GitHub, GitLab, Bitbucket - and the cloud service handles compilation, unit tests, and artifact generation on infrastructure that’s actually configured for TwinCAT.

How it works:

1. You push code to your Git repo
2. A lightweight proxy script detects the push
3. The proxy sends repo metadata + authentication to the cloud platform
4. The cloud platform builds on TwinCAT-capable infrastructure
5. Logs, artifacts, and test reports come back to your CI system

One thing worth being clear about: your build runs on a node dedicated to your team. Nobody else’s code is on that machine, and everything is deleted the moment the build finishes - even if it crashes halfway through. For teams shipping proprietary machine software, that’s not a small thing.

The obvious concern is external dependency and repo access. An NDA should be table stakes. If your security policy rules this out entirely, that’s fair - but for most teams it’s a reasonable trade for not having to build and maintain the infrastructure themselves.

Zeugwerk are providing a valuable and unique service that contributes to modernising the PLC software development experience. The build service is well integrated for GitHub and has been reliable, it just works. Their team has provided helpful onboarding and responsive ongoing support.

— Brianna Laugher · Principal Software Engineer · Celleo

Zeugwerk additionally provides services around automated builds (CI/CD), testing, and documentation that integrate meaningfully into the development process. With this set of ’tools’ we are able to reduce development times, raise software quality, and at the same time ensure a long-term maintainable and scalable architecture. Overall we have had consistently very positive experiences and see clear added value in the Zeugwerk Framework for modern, structured automation projects.

— Georg Tauber · Research & Development Electronics · Durst Group

Comparison

Where Things Are Heading

A few things are pushing the industry toward proper build tooling, whether teams are ready or not.

Regulatory requirements are one. Standards like ISO 13849 and the Machinery Directive are increasingly expecting traceability - documented test records, reproducible builds, change history. That’s hard to produce after the fact. Remote work is another. The assumption that everyone can gather around the same hardware is quietly going away.

The AI angle is newer but worth taking seriously. LLMs are showing up in engineering workflows - code suggestions, refactoring, automated review. But AI-assisted development only works safely if there’s a real test pipeline underneath it. Without automated validation, accepting a code suggestion is just a faster way to introduce a bug you won’t find until production. CI/CD is what makes those tools actually usable.

Over the next few years, expect Beckhoff to invest more in tooling (PLC++ signals they’re aware of the gap), more cloud services targeting TwinCAT specifically, and a gradual shift toward CI/CD as standard practice for teams of any real size.

Honest Take

Small teams: Local builds are fine for now. The pain usually arrives when someone leaves, or when a customer asks for documentation you haven’t been keeping. You’ll know when you’ve hit the wall.

Teams using the Zeugwerk Framework: You’re already thinking about software engineering properly. CI/CD is the natural next step - it makes everything else more reliable.

Teams with DevOps capacity: Jenkins works. Just make sure it’s not a one-person system.

Teams that want it to just work: Cloud CI is the honest answer. Yes, external dependency. But reproducible builds and traceability without building the infrastructure yourself.

The Uncomfortable Truth

Most PLC shops don’t feel the pain yet. Local builds work, manual testing mostly catches things, and CI/CD sounds like overhead for a problem that isn’t obviously broken.

The pain tends to arrive all at once. The 2 AM call because nobody can tell what changed between the last two deployments. The three-week onboarding because the build process lived entirely in one person’s head. The customer audit asking for test records that don’t exist.

By the time it feels urgent, retrofitting is expensive and disruptive. Teams that sort it out early - when it still feels optional - are the ones who don’t end up in those situations.

Questions about CI/CD for TwinCAT, or want to see how Zeugwerk’s tooling works in practice? Get in touch.