Share this post
The first time an OT team deploys Portainer across a factory network, the instinct may feel straightforward: install it the same way at every level. One Portainer Server per site, one per production line, one per device. It feels thorough. It looks right. And for a handful of devices, it works. In fact, it's a common starting point with Portainer.
The problem surfaces later. Usually, when the deployment grows, or when someone asks why updating a single containerized application requires touching every device individually, or when a security audit reveals that each of thirty sites is running a slightly different configuration. By that point, the architecture has already become a liability.
What the Wrong Edge Architecture Pattern Actually Looks Like
Running a Portainer Server on every edge device means each device is its own independent management environment. There is no shared control plane, no central visibility, and no way to act across the deployment from a single point.
In practice: if you're managing 30 edge devices, you have 30 separate Portainer Server instances to log into. Updates, configuration changes, and policy enforcement have to be applied one device at a time. If you want to know what version of an application is running across your fleet, you're checking thirty consoles. If something breaks at a remote site, finding out what changed requires logging into that specific instance and investigating manually.
Configuration drift is the natural result. No two devices stay identical for long when each one is managed independently. Over time, what started as a consistent deployment becomes a patchwork of slightly different configurations. Each is a potential source of risk, and each is harder to audit than the last.
The management overhead doesn't grow linearly with device count. It compounds.
The Wrong Edge Architecture Also Costs More
There's a commercial dimension worth naming directly. Portainer's licensing model means that running a full Server instance on every edge device is more expensive than the correct pattern. The right architecture - one Portainer Server managing many lightweight Portainer Agents - isn't just better operationally. It's the more cost-effective way to deploy at scale.
Getting the architecture right early isn't only about avoiding pain later. It affects what you're paying now.
The Edge Architecture Pattern That Scales
The correct deployment pattern separates the control plane from the endpoint. A single Portainer Server - deployed at the edge gateway level, or centrally in cloud or on your self-hosted infrastructure - manages the entire deployment. At each individual edge device, a lightweight Portainer Agent handles local execution and communicates outbound to that central server.
One login. One view across the many endpoints of your connected environment. One place to push an update, enforce a policy, or investigate a fault across the full deployment.
The agent executes. The server manages. That separation is what makes scale possible.
What Changes When the Architecture Is Right
Software updates can be staged and rolled out across all connected devices from a single interface. Security policies defined at the control plane propagate automatically. Role-based access controls give OT and IT teams visibility into exactly what they're responsible for. When something goes wrong on a specific device, the information to diagnose it is available in one place, not scattered across 30 independent consoles.
Compliance and auditing also become more tractable. When deployment records, configuration history, and access logs live in a centralized control plane, producing them for an audit is a report and not a manual reconstruction.
One control plane. Many agents. One source of truth for everything running at the edge.
Starting Right Is Easier Than Fixing It Later
Most teams don't discover this architecture problem at five devices. They find it at 50, or when a security review reveals that every site is running a different configuration, or when a critical update takes three times longer than it should because there's no centralized rollout mechanism.
The correct pattern is not more complex to deploy. It requires one Portainer Server instance at the appropriate level of the network hierarchy and lightweight Portainer Agents at each edge device, designed to work within existing network constraints, without requiring infrastructure changes.
The pattern is the same either way: one control plane, many agents, and the operational visibility to manage what you've built.
.png)
