ADOIT 21.0 Hardware/Software Requirements

Abstract

ADOIT Web Client	Web browser used to access the ADOIT web application. ADOIT supports the desktop browsers Microsoft Edge, Mozilla Firefox and Google Chrome on Windows and Safari on macOS and on the iPad.
ADOIT Web Server	Containerised web server component that exposes the ADOIT web application and handles HTTP(S) traffic from web clients. The web server runs as an OCI‑compliant container and is typically integrated with external components such as an Ingress controller, Gateway API or reverse proxy for HTTPS termination.
ADOIT Application Server	Containerised backend component that contains the core ADOIT application logic and provides access to the ADOIT database. The application server runs as an OCI‑compliant container and communicates with the web server over the internal deployment network.
ADOIT Database	External database server that stores all persistent ADOIT repository data. ADOIT supports Microsoft SQL Server and PostgreSQL. The database is operated independently from the ADOIT containers and is not deployed as part of the ADOIT runtime.

Architecture

The architecture of ADOIT is based on a containerised application model.

The application is delivered as a set of OCI‑compliant container images and consists of two core server components:

• the ADOIT Web Server
• the ADOIT Application Server

Each component is executed in a dedicated container and the components communicate with each other via an internal deployment network. The web server exposes the ADOIT web application to end users and processes incoming HTTP requests. The application server contains the core ADOIT application logic and provides access to the ADOIT database.

The ADOIT database is not part of the containerised runtime environment. It is operated as an external database server and stores all persistent ADOIT repository data. The database is managed independently from the ADOIT deployment.

ADOIT offers two options for container-based deployment:

• Kubernetes, using the supplied Helm chart
• Docker Compose, using the supplied Compose configuration

The fundamental application architecture remains the same across these environments; differences exist only at the level of orchestration and infrastructure integration.

Software Requirements

ADOIT Web Client

ADOIT is accessed exclusively via a web browser. No additional client‑side software or plugins are required.

Supported Browsers

Desktop Browser: Microsoft Edge (latest) on Windows Mozilla Firefox (latest) on Windows Google Chrome (latest) on Windows Safari (latest) on the Mac Mobile Browser: Safari (latest) on the iPad; graphical modelling is not supported on the iPad

Server Components

ADOIT is operated in a container-based server environment. All server-side components are provided as OCI‑compliant container images and are executed using a supported container runtime.

The following sections describe the required server-side software environment and infrastructure components that must be provided in order to operate ADOIT.

Container Runtime

ADOIT requires an OCI‑compliant container runtime on an x86_64 (AMD64) architecture. The following container platforms are fully validated and supported:

Platform	Status
Kubernetes (x86_64)	Supported
Docker and Docker Compose (x86_64)	Supported

Other OCI‑compliant container runtimes or Kubernetes‑compatible platforms are expected to be compatible, provided they conform to the respective standards. Such platforms are not individually tested.

Container Execution User and Pod Security Restrictions

ADOIT images are shipped with the requirement that the processes executed in the containers are owned by user 1100. In container orchestration environments with restrictions regarding the runAsUser settings this can result in the containers failing to run. The deployment settings need to be adapted allowing execution as user 1100. In OpenShift, for example, this can be achieved by setting the Security Context Constraint (SCC) on the associated service account to nonroot (see the Red Hat OpenShift Documentation. With this setting, it is still ensured that the actual user is not root, acknowledging that if multiple instances of BOC Group products exist on a node, they are executed with the same UID.

Operating System (Host Level)

ADOIT is designed to run on modern Linux-based operating systems capable of executing the required container runtime.

Examples of supported host operating systems include:

• Ubuntu
• Debian
• Red Hat Enterprise Linux (RHEL)
• SUSE Linux Enterprise Server (SLES)

In general, any current Linux distribution that is supported by the chosen container runtime and deployment platform can be used.

Kubernetes and Deployment Tooling

When operating ADOIT in a Kubernetes environment, the following requirements apply:

Component	Requirement
Kubernetes	Kubernetes version 1.32 and higher
Helm	Helm 3.x for deployment
Container Registry Access	HTTPS access to OCI registry (port 443)

The Kubernetes cluster must support standard resource types such as Services, Ingress or Gateway API resources, and Persistent Volume Claims, as required by the ADOIT deployment.

Persistent Storage

Persistent storage is required for the full-text search index and for application log files. Storage is typically provided using Kubernetes Persistent Volumes (PV) and Persistent Volume Claims (PVC), configured via the delivered Helm chart.

Storage component	PVC required	Backup required	Purpose	Notes
Full-text search index	Yes	No	Storage of the full-text search index used by the application server pod	Requires a dedicated PVC mounted to the application server pod. Storage may be backed by block storage such as Ceph RBD. The index can be recreated at any time.
Application logs	Yes	Optional	Storage of application log files and generation of the ADOIT Support Information Package (SIP)	Logs may be written to this persistent volume in addition to, or instead of, the standard container log stream via stdout/stderr.

Server-Side Software Scope

The ADOIT container images include all required application-level dependencies. In particular:

• No separate Java installation is required on the host system.
• No application server or web server software needs to be installed outside the containers.
• Configuration is performed via environment variables supplied at deployment time.

Additional infrastructure components (for example reverse proxies, ingress controllers, or certificate management solutions) are required depending on the chosen deployment environment and are described in the corresponding technical documentation.

Database Server

ADOIT requires an external database system to store all persistent repository and application data. The database is not part of the ADOIT container runtime and must be provided and operated independently.

Supported Database Management Systems

ADOIT supports the following database management systems:

Supported database management systems

Microsoft SQL Server: SQL Server 2016 SQL Server 2017 SQL Server 2019 SQL Server 2022 SQL Server 2025 (Enterprise Edition, Standard Edition, Workgroup Edition, Express Edition) Note: SQL Server Express edition is not recommended for production use. Note: ADOIT does not support SQL Server multi-subnet failover. Any interruption of the database connection causes a restart of database-dependent backend components. PostgreSQL PostgreSQL 12 to 17

Database Connectivity

• The database must be reachable from the ADOIT Application Server container via the network.
• Appropriate database drivers are included as part of the ADOIT container images; no additional database client software is required on the host system.
• Database connection parameters (host, port, database name, credentials) are provided via environment variables at deployment time.

Database Operation

• The database may be operated on physical or virtual machines or within managed database services, provided network access is ensured.
• Backup, recovery, high availability, and maintenance of the database are the responsibility of the customer.
• ADOIT does not impose specific requirements on database clustering or failover mechanisms beyond standard DBMS support.

Additional Optional Server Components

SMTP Server

ADOIT supports sending of email messages in specified scenarios. To use this functionality an SMTP server is required that can be accessed from the ADOIT web server. The address and port are configurable in the ADOIT Administration. SMTP Authentication and Transport Layer Security (TLS) are supported.

Network Requirements

Operating ADOIT requires reliable network connectivity between the involved components and infrastructure services.

Required Network Connectivity

The following network connections must be available:

ADOIT Web Client → ADOIT Web Server	End-user access via HTTP or HTTPS. Minimum: 2 Mbit/s Recommended: 10 Mbit/s
ADOIT Web Server → ADOIT Application Server	Internal communication within the deployment environment.
ADOIT Application Server → Database Server	Persistent database connectivity. Minimum: 100 Mbit/s Recommended: 1 Gbit/s LAN-like latency
Deployment environment → Container Registry	HTTPS access (typically TCP port 443) to retrieve container images.

Ports and Protocols

The following ports and protocols are required:

Port	Purpose
443	Access to container registry
80 / 443	HTTP / HTTPS for web access to ADOIT
Database-specific ports	Connection to external database; as required by the chosen DBMS

TLS termination is not performed inside the ADOIT containers. For encrypted access, HTTPS termination must be handled by external components such as an ingress controller, gateway, or reverse proxy.

Hardware Requirements

ADOIT Web Client

The hardware requirements for the ADOIT Web Client depend primarily on the requirements of the operating system and web browser in use.

As a general guideline:

• 4 GB RAM and a screen resolution of 1366 x 768 or higher is recommended for acceptable performance.
• Higher screen resolutions improve usability when working with models and reports.

Server Components

• The total workload size (number of concurrent users, repository size, modelling and reporting activity) is the primary sizing factor for server hardware sizing.
• Adequate resource headroom should be provided to account for peak usage, background processing, and operational overhead.
• When operating ADOIT in Kubernetes, resource requests and limits must be aligned with the available node capacity.

Typical Component Resources

The following values provide typical CPU and memory requirements for each ADOIT container.

Component	CPU	Memory
Web server container	2 CPUs or more	2 GB or higher (minimum) 4 GB or higher (recommended)
Application server container	3 CPUs or more	4 GB or higher (minimum) - 2 GB for the ADOIT application server process, with an additional 1 GB per configured aworker process 8 GB or higher (recommended) - 4 GB for the ADOIT application server process, with an additional 2 GB per configured aworker process An additional 6 GB RAM is required if at least 10 GB of external documents have been uploaded into the database.

Example Resource Configuration

The values below show how typical ADOIT sizing can be mapped to Kubernetes resource settings. They are based on the recommended values above and should be adjusted according to real workload.

Web Server Container

Parameter	Example Value
CPU request	2 CPUs
CPU limit	4 CPUs
Memory request	4 GB
Memory limit	8 GB

Application Server Container

Parameter	Example Value
CPU request	3 CPUs
CPU limit	6 CPUs
Memory request	8 GB
Memory limit	16 GB

Notes on Scaling and Availability

• ADOIT supports multiple Application Server instances for availability purposes, subject to architectural constraints documented separately.
• Horizontal autoscaling is not supported; scaling is primarily achieved by vertical scaling of available resources.
• When multiple nodes are used, the combined available resources across all nodes must meet the required workload capacity.

Database Server

Disk space	Minimum: According to the specifications of the DBMS manufacturer Recommended: 2 GB per ADOIT database instance. This value depends on the size of the stored data and may be higher.
CPU	According to the specifications of the DBMS manufacturer
Memory	Minimum: 500 MB are required for the first ADOIT database instance; another 500 MB are required for each additional database instance; Recommended: Depending on the amount of stored data it might be necessary to provide more memory for the database instance.

Authentication Mechanisms of ADOIT

This section describes the different authentication mechanisms of ADOIT. The authentication mechanisms can be used separately or in combination. Depending on the used authentication mechanisms, further installation-specific configuration steps may be necessary. Please consult your ADOIT consultant for further information.

Authentication Mechanisms

Standard ADOIT users	ADOIT users are created in the ADOIT Administration. Login to ADOIT requires input of username and password. These credentials are used to authenticate the user against the available data in the ADOIT database. The assignment of user attributes, rights and system roles is controlled in the ADOIT Administration.
LDAP Authentication	Users can either be imported from a directory service or mapped to ADOIT users. Login to ADOIT requires input of username and password. The provided credentials will be used to authenticate the user against the configured directory service. A precondition for this scenario is that the connection of ADOIT to the directory service in use (e.g. Active Directory) is established in the ADOIT Administration. The assignment of user attributes, rights and system roles may be controlled in the ADOIT Administration or synchronised with an external directory service. Specific configuration steps are necessary when setting up ADOIT for this authentication mechanism. Please consult your ADOIT consultant for further information about this authentication mechanism.
IDM Authentication	Users can either be imported from an external user management system or mapped to ADOIT users. Login to ADOIT via single sign-on is possible using an Identity Management System (IDM) A precondition for this scenario is the connection of ADOIT to an authentication server in the target environment which provides means for authentication with an external user management system. The assignment of user attributes, rights and system roles may be controlled in the ADOIT Administration or synchronised with an external user management system. Specific configuration steps are necessary when setting up ADOIT for this authentication mechanism. Please consult your ADOIT consultant for further information about this authentication mechanism.
SAML Authentication	Users can either be imported from an external user management system or mapped to ADOIT users. The external user management system must provide an Identity Provider (IdP) for SAML 2.0 (e.g. Active Directory Federation Services [AD FS] or Shibboleth). To log on to ADOIT, the user is redirected to the IdP. Depending on the configuration of the IdP, the authentication is carried out via single sign-on or by entering access data (username and password, certificates, etc.). No server-to-server communication is necessary for this authentication mechanism, since all data is transmitted via the browser. The assignment of user attributes, rights and system roles may be controlled in the ADOIT Administration or synchronised with an external user management system. Specific configuration steps are necessary when setting up ADOIT for this authentication mechanism. Please consult your ADOIT consultant for further information about this authentication mechanism.
OIDC Authentication	Users can either be imported from an external user management system or mapped to ADOIT users. A precondition for using OpenID Connect (OIDC) is the connection of ADOIT to an OpenID Connect provider (OP) that verifies the identity of the user as well as provides basic profile information about the user. To log on to ADOIT, the user is redirected to the OP. Login to ADOIT via single sign-on is possible using OIDC authentication. The assignment of user attributes, rights and system roles may be controlled in the ADOIT Administration or synchronised with an external user management system. Specific configuration steps are necessary when setting up ADOIT for this authentication mechanism. Please consult your ADOIT consultant for further information about this authentication mechanism.

LDAP Support

LDAP/LDAPS support for the providers AD (Active Directory) and eDirectory and comparable LDAP providers. Other LDAP providers are not tested. A specific evaluation can be done on request.

Feature Overview

This table contains a summary of the features of the different authentication mechanisms.

	Standard ADOIT Users	LDAP Authentication	IDM Authentication	SAML Authentication	OIDC Authentication
Login with username and password	Yes	Yes	Yes (depending on the IDM solution)	Yes (depending on the SAML IdP)	Yes (depending on the OP)
SSO	No	No	Yes (depending on the IDM solution)	Yes (depending on the SAML IdP)	Yes (depending on the OP)
On login, synchronize attributes, role and group assignment (with external user management system)	No	Yes	Yes	Yes	Yes
Periodically, synchronize attributes, role and group assignment (with external user management system)	No	Yes	Yes (with LDAP coupling)	Yes (with LDAP coupling)	Yes (with LDAP coupling)
Create users automatically	No	Yes	Yes	Yes	Yes