Why I built an open-source alternative to Microsoft's System Center Orchestrator (Windows Automation)

Florian Kemper — Thu, 17 Sep 2026 13:04:00 +0000

Why I started building NodePilot, a modern alternative to System Center Orchestrator

I have been working professionally in Windows enterprise environments for several years, and during that time I have also become a heavy user of System Center Orchestrator.

For those who haven't worked with it, Orchestrator is basically a workflow automation platform for enterprise environments. You build runbooks by connecting different activities, pass data between them and use them to automate things across your infrastructure.

A lot of our automation is based around PowerShell, services, databases, Active Directory and other Windows-related tasks, so the general concept of Orchestrator still makes a lot of sense to me.

The problem for me was never that it is on-premises or focused on Windows. In fact, those are two of the reasons why I still use it.

The problem is that the product around that concept has aged quite a bit.

The basic idea is still good

I actually like the way Orchestrator approaches automation.

You have a visual workflow, you can see how activities are connected, you can pass published data from one activity to another and you have a central place where your automation runs.

For larger Windows environments, this can be much nicer than ending up with hundreds of PowerShell scripts spread across servers and scheduled tasks without really knowing what is running where.

The architecture has become quite heavy

A complete Orchestrator environment consists of several components.

There is the Management Server, one or more Runbook Servers, the database, the Web API, the web console and the Runbook Designer. Depending on the environment, these roles can of course share systems, but it is still quite a lot of infrastructure for what is essentially a workflow engine.

This isn't necessarily a problem once everything is running.

It becomes more noticeable when you have to install a new environment, migrate one, troubleshoot communication between components or keep everything patched and compatible.

The same applies to Integration Packs.

They are an important part of Orchestrator because they provide additional activities, but they also have to be registered and deployed to the relevant Runbook Servers and Runbook Designers. Updating them can require removing older versions first.

It works, but it doesn't exactly feel lightweight.

The Runbook Designer still feels like a product from another generation

The Runbook Designer does its job, and I have built a lot of workflows with it.

But compared to modern workflow tools, the whole authoring experience feels very desktop-centric.

You work in a dedicated Windows application, connect activities on a canvas and configure most things through dialogs.

Again, none of this makes Orchestrator unusable. I still use it professionally.

But once you have worked with newer web-based tools, it becomes hard not to notice the difference.

Things like working from a browser, quickly searching through executions, looking at live output, managing workflows from different machines or integrating automation more naturally into modern development processes are things I started missing more and more.

I also wanted workflows to feel less like something that lives inside a specific designer and more like a normal part of the infrastructure that can be moved, inspected and maintained easily.

Troubleshooting can become surprisingly complicated

This is probably one of the bigger issues for me.

When an automation platform works, nobody really cares how it works.

When a workflow fails at 3 AM, that changes very quickly.

With larger Orchestrator environments, troubleshooting can involve the Runbook Designer, the web console, Windows services, event logs, SQL and sometimes PowerShell just to understand what actually happened.

If a runbook calls another runbook which then executes PowerShell on another system, finding the exact point where something went wrong isn't always as straightforward as I would like.

Over time, I started wanting something where execution history, audit messaging and current activity were a more central part of the product.

Not just did the workflow fail?, but:

What input did it receive?
What output did it produce?
What triggered this workflow in the first place?
Who accessed Runbook Designer or Web UI?

Those things are especially useful when automation grows beyond a handful of simple runbooks.

Orchestrator 2025 didn't really change that for me

Microsoft is still maintaining Orchestrator, and the 2025 release did bring some useful platform updates.

There is support for things like .NET 8 for the Web API, TLS 1.3, gMSA and newer SQL connectivity.

Those are good and necessary changes.

But they don't really change the way you build and operate runbooks.

The core architecture, the Runbook Designer and the general workflow model are nearly identical to what they have been for a long time. Furthermore it is always difficult to track and trace whats happening on the Orchestrator server.

That was probably the point where I started seriously thinking about what a modern version of the same idea could look like.

So I started building one

A large part of my work also consists of programming, and development and AI tools have improved a lot over the last few years.

So one thing led to another, and I started building NodePilot.

The idea wasn't to invent a completely new kind of automation platform.

Actually, it was almost the opposite.

I wanted to keep the parts I like about Orchestrator:

visual workflows
central execution
Windows-focused automation
PowerShell as a first-class option
reusable activities
passing data between workflow steps

But build those ideas on a more modern foundation.

NodePilot currently supports activities for PowerShell, REST, SQL, WMI, registry, files, Windows services and LLMs, among others.

Workflows can be triggered through schedules, webhooks, file watchers or Windows Event Log events.

There is also an execution history and a live operations view, because those were two areas I personally wanted to have much more visibility into.

The backend uses .NET 10, the frontend uses React, and the database can be either PostgreSQL or SQL Server.

It is currently Windows-only.

Existing Orchestrator environments were another important part

One thing I knew from the beginning was that simply telling someone to rebuild ten years of Orchestrator runbooks in another product isn't very realistic.

Some environments have hundreds or even thousands of runbooks.

Because of that, NodePilot includes a mechanism for importing existing System Center Orchestrator runbooks.

The goal is to translate as much of the existing workflow as possible instead of starting from an empty canvas.

This is also one of the parts where I am especially interested in real-world testing, because every Orchestrator environment is different and there are many ways people have built their runbooks over the years.

NodePilot also supports things I would expect from a tool used in enterprise environments, such as LDAP and SSO.

Where the project is now

NodePilot is completely open source under the Apache 2.0 license. There are no paid features or features hidden behind a commercial version.

If you just want to test it, there is also an Electron-based Windows 11 build that bundles the required components. It can be downloaded from the Releases section.

I also recorded a demo video, and the README contains some screenshots and more technical information.

Repository:
NodePilot on GitHub

Demo:
Demo video

Documentation:
Documentation

What I am interested in now

At this point, I am mainly interested in feedback from people who actually work with automation in Windows environments.

The project has not had a huge amount of real-world testing yet.

I would especially be interested in hearing from people who currently use Orchestrator:

What parts of SCORCH are still important to you?
What are the things that annoy you most about it?
Does the runbook import work with your existing workflows?
Which activities or integrations would you consider essential?
What would prevent you from moving an existing automation to another platform?

I'm also interested in feedback from people using tools like n8n, Rundeck, Jenkins or similar platforms for infrastructure automation.

There are probably quite a few things I haven't thought about yet.

PS: I originally wrote this in German and used AI to help with the English version.

DEV Community: Florian Kemper