Backstage vs Port When Software Lives on the Shop Floor

A hosted tool like Port needs some way to learn about a system it can't reach directly, which means either an agent running inside the plant network that pushes status updates out, or a scheduled export process that periodically syncs data to somewhere Port can read it. Neither is exotic engineering, but both are real integration work your team has to build and maintain, and Port's own documentation and support won't cover the specifics of your particular plant network architecture.

Backstage has the advantage of being something you can run inside the plant network itself if your infrastructure allows it, avoiding the agent-and-tunnel problem entirely for that portion of your catalog. The tradeoff is the same maintenance burden self-hosting always carries, now potentially split across two environments if you run different instances for corporate IT and the shop floor.

Check with whoever manages your plant network's security policy before assuming either path is even permitted. Some manufacturers operate under contractual or insurance requirements that restrict what can connect outward from the plant floor at all, regardless of how convenient a sync agent would be.

Not every machine data collector needs to show up in a developer portal at all. The real question is whether your engineering team needs a queryable, ownership-tagged record of these systems, or whether your existing MES or historian software already answers that question well enough for your purposes. A portal is worth the integration cost for systems your engineering team actively maintains and modifies; it's often not worth it for stable, vendor-managed equipment that rarely changes and already has its own operational monitoring.

Many contract manufacturers end up cataloging their corporate-side software, ERP connectors, customer portals, internal tools, in whichever portal they choose, while leaving true shop-floor systems documented separately in whatever operational technology monitoring they already run. That split avoids forcing an ill-fitting tool onto systems it wasn't designed for, while still getting the ownership and discovery benefits for the software your engineering team actually iterates on regularly.

The split works best when it's explicit rather than accidental. Write down which category each system falls into and why, so a new engineer joining the team understands the boundary immediately instead of discovering it by asking why half your infrastructure isn't in the catalog they were just onboarded onto.

Map which of your systems sit on a network with any path, even indirect, to the public internet, and which are genuinely isolated. For the isolated systems, note who currently owns keeping their status visible to the rest of the organization, and how that visibility works today. If the honest answer is that nobody outside the plant floor knows a machine collector's health without physically checking, that's a real gap, but it may be better solved by better operational technology monitoring than by forcing that system into a developer-focused catalog it was never built to represent well.

Run the audit in this order:

1. Map which systems sit on a network with any path, even indirect, to the public internet, and which are genuinely isolated.
2. For each isolated system, note who currently keeps its status visible to the rest of the organization and how that works today.
3. Flag systems whose health nobody outside the plant floor can see, since those are candidates for a sync agent or scheduled export.
4. Check with whoever manages plant network security policy whether any outward connection is permitted before choosing either path.

Deployment frequency by DORA cluster applies cleanly to the corporate-side software you catalog in either tool, since that portion of your stack behaves like a standard engineering environment even if the plant floor doesn't¹. Change failure rate matters just as much for that same corporate-side software, since a standardized deploy path catches more of the mistakes that would otherwise reach production unnoticed in your ERP or customer-facing systems². DevOps spend as a share of revenue is a useful sanity check on the size of this investment relative to your overall technology budget, since manufacturing margins often leave less room for open-ended internal tooling projects than a software company's margins do³.

Apply these numbers only to the software actually inside your catalog's scope. Extending a DORA-style framework to shift-scheduled shop-floor systems can produce numbers that look alarming without saying much about equipment that was never designed to be measured that way.