octoplant Architecture: Server, Clients, Agents and the Plant Network

octoplant architecture follows a classic client and server pattern adapted to plant networks: a central server holds the repository and runs jobs, engineers work through clients, and agents reach devices on subnets the server cannot see directly. Since release 105 there is also a browser interface. Where each piece sits decides whether the tool fits your network segmentation or forces holes through it, so this page is for the OT lead, the IT network team and the security lead who will have to agree on the design.

For what octoplant does, see the parent page on octoplant. Some component details below are not publicly documented by AMDT; where that is the case we describe general behaviour for this class of tool and say so.

The components of octoplant architecture

Component	What it does	Public detail as of October 2026
Server	Holds the central repository, runs scheduled jobs, manages users and rights	Described by AMDT as the “Centralized OT repository” (AMDT)
Central repository	Every version of every device’s program, configuration and document	Version history with who, what, when and why
Database	Stores the repository metadata and history	PostgreSQL 17 as of release 105 (Novotek)
Jobs	Scheduled uploads from devices, followed by a compare against the approved version	Unlimited in every edition (pricing)
Desktop clients	Engineers check out, check in, compare and restore	Work alongside the native engineering tools
Agents	Reach devices on separated subnets on the server’s behalf	Named in public sources; internals not public (general behaviour below)
Web interface	Browser access to view components, download ZIP files and launch preconfigured jobs	First introduced in release 105, August 2025 (Novotek)
Image service	Integrates PC image tools so industrial PCs can be restored	Partners name Drive SnapShot and Acronis
Export APIs	Send data to other systems	REST export API (105); octovision Export API (107)

Deployment is mainly on-premises. AMDT does not clearly state a hosted SaaS option for octoplant as of October 2026. octovision, the intelligence layer that reads octoplant data, is on-premises today with cloud on the roadmap; see octovision.

How the pieces work together

1. An engineer checks out the approved version through the client, edits it in the native tool, downloads it and checks the new version in. The server records the change.
2. On schedule, a job runs. For devices the server can reach, the server uploads directly. For devices on a separated subnet, an agent in that subnet performs the upload (general behaviour; see below).
3. The upload is compared with the approved version. A match is logged; a difference raises an alert. See change detection.
4. Results flow outward. The web interface shows status to people without a client, and the export APIs pass data to a CMDB or ticketing system.

What agents do (general behaviour)

Public sources say octoplant uses agents to bridge separated subnets. AMDT does not publish how they work, so the following describes how agents behave in tools of this class, not confirmed octoplant specifics:

• They sit close to the devices, usually on a PC or server inside a cell or area subnet.
• They do the device communication that the central server cannot do across a firewall or a non-routed network, using the vendor’s protocols and engineering software libraries.
• They talk back to the server over a smaller number of connections, which is easier to allow through a firewall than direct access to every device.

Questions to settle with AMDT: which ports and protocols the agent uses, whether it initiates the connection or listens, how it authenticates, whether traffic is encrypted, what it needs installed locally (engineering software versions, licences), and what happens to scheduled jobs when the link to the server is down.

Network and security considerations for octoplant architecture

Keep device traffic inside OT. Uploading a PLC program uses the same protocols an engineer uses to download one. That traffic should not cross into IT. Place the server at Level 3 and the agents in the cell zones, and let only exports and browser sessions reach the DMZ. In ISA/IEC 62443 terms, each cell is a zone and each agent-to-server path is a conduit, so every agent you add is a conduit to document and approve. Our guide to OT network segmentation in brownfield plants covers how to build those zones where they do not yet exist.

Treat the server as a crown jewel. It holds a copy of every program in the plant, and it can write them back. An attacker with control of it could learn the process or restore a modified version. Restrict administrator rights, require named accounts, log access, patch the operating system, and keep it off general IT domains where you can.

Back up the backup. The repository and its PostgreSQL database must be backed up together, off the server, and restored in a test at least once. If ransomware encrypts the server, a tool built for recovery cannot help you. NIST recommends a “backup-in-depth” approach, with recent local copies for speed and secure copies held somewhere “the same incident that disrupts the primary data cannot modify or destroy” (NIST SP 800-82 Rev. 3). For octoplant, that means at least one copy of the repository off the OT network, or offline.

Plan for flat networks honestly. Many brownfield plants have one large Layer 2 network. octoplant will work there, but placing agents is then a convenience rather than a control. Segmentation is a separate project; see OT networks.

Separate the browser path. The web interface makes status visible to managers and IT without a client install. Decide who needs it, from which network, and with what rights, since it can launch preconfigured jobs.

Where it gets hard

Engineering software on the agent. Many device families can only be read through the vendor’s own libraries. If an agent needs a specific TIA Portal or Studio 5000 version installed, that PC becomes another engineering workstation to license, patch and keep compatible. Ask for the requirement per device family.

Firewall change control. Each new agent or cell zone means a firewall change. In plants where OT and IT own different firewalls, that is a ticket and a meeting each time. Agree the pattern once and template it.

Upgrades touch every component. Server, clients and agents generally need compatible versions, and release 105 changed the database to PostgreSQL 17. Plan upgrades as a coordinated change; see the release history.

Unnetworked machines. No architecture reaches a machine with no network. Those devices need a manual upload process, with a named owner, feeding the same repository.

Several sites, one design? Each campus carries its own licence, but AMDT does not publish whether one central server can serve several campuses over a WAN or whether each site runs its own. The answer changes the recovery plan: a central server is one place to protect, and also one dependency every site shares. Ask, and test what happens to a remote site’s jobs when the WAN link drops.

Who owns the server? IT owns servers, OT owns devices, and this server is both. Settle ownership, patching and monitoring before go-live. An IT/OT integration review is the place to agree it, and an OT network assessment shows whether the zones exist to place agents in.

For how architecture choices affect what you pay, see editions and licensing. Back to octoplant or the AMDT hub.