Deployment model

how is mantsu deployed? audience this page is written primarily for it architects and infrastructure teams who plan a mantsu deployment it explains which building blocks are deployed, how they are grouped, and which variants exist for small and large plants non technical readers, such as project stakeholders, can use it to understand the available options mantsu is deployed as a set of docker containers containers are logically grouped into nodes each node represents a specific functional layer of the mantsu application where operational scale and resilience requirements justify it, nodes are managed by kubernetes for lightweight edge deployments (small ot nodes), containers may be managed directly via docker or docker compose to avoid the overhead of a full kubernetes control plane the deployment follows the same start small philosophy as the rest of mantsu you begin with the nodes you need and scale up as the needs of the plant grow node overview mendix node groups the mendix services redpanda node is responsible for event streaming and agentic data plane accessibility data node groups the data & reporting services such as the reporting application and the prometheus server ot nodes is responsible for the mqtt data stream sizing note the specific node topology, clustering configuration, and enabled feature set are determined during the implementation phase based on your plant size, continuity requirements, and licensing scope which cross cutting concerns does the deployment cover? ot it network boundaries all ot nodes sit on the operational technology (ot) network, separated from the mantsu it platform by a firewall mqtt traffic from the ot edge crosses this boundary in a controlled, typically unidirectional manner this segmentation follows standard industrial cybersecurity practices (iec 62443) the ot/it firewall and the network segmentation architecture are the responsibility of the customer cold storage & data lake for mid to large deployments with iceberg topics enabled, redpanda (enterprise edition) automatically offloads topic data to a cold storage target in apache iceberg format this data is then directly queryable by business intelligence platforms cold storage infrastructure must be provided and managed by the customer common targets include microsoft azure (azure data lake storage, azure synapse analytics) databricks (delta lake / iceberg) snowflake (iceberg table support) which deployment variants exist? final architecture and deployment model are determined during the implementation project these are customized depending on the customer requirements the table below gives an indication of difference between the possibilities of a small to large deployment note the boundaries between small and large deployment are indicative the actual configuration is agreed with the customer based on their requirements regarding plant size, ot landscape, integrations, reliability & availability requirements node / feature small medium plant large plant mendix node (kubernetes) ✅ ✅ redpanda community ✅ ❌ redpanda enterprise ❌ ✅ redpanda clustering ❌ ✅ agentic data plane ❌ ✅ iceberg topics + cold storage ❌ ✅ ot node open source mqtt ✅ ❌ ot node enterprise mqtt ❌ ✅ data node report application ✅ ✅ data node metrics monitoring optional ✅ frequently asked questions when does a mantsu deployment use kubernetes versus docker compose? kubernetes manages the nodes where scale and resilience justify it; lightweight ot edge nodes can run on docker or docker compose what distinguishes mantsu's small and large deployment variants? the large variant adds redpanda enterprise features such as clustering, the agentic data plane, iceberg topics, and enterprise mqtt which parts of the deployment are the customer's responsibility? the ot/it firewall and network segmentation, and any cold storage or data lake infrastructure used for iceberg offloading can a mantsu deployment change after go live? yes nodes can be added, clustered, or omitted without architectural redesign summary mantsu runs as docker containers grouped into functional nodes (mendix, redpanda, data, ot), orchestrated by kubernetes where scale requires it deployment variants range from a minimal single plant setup to a fully clustered enterprise configuration