System Architecture and Technical Requirements
- 1 Purpose of this Article
- 2 Deployment Models
- 3 Recommended Architecture
- 4 Infrastructure Design Principles
- 5 SQL Server Guidance
- 6 Minimum Infrastructure Recommendations
- 7 Platform Support Policy
- 8 Performance and Connectivity Guidance
- 9 Replication and Document Considerations
- 10 Adonis Components
- 11 Quick Decision Guide
- 12 FAQ
- 12.1 Can a Host Installation be deployed on a single all-in-one server?
- 12.2 Can a vessel run Adonis on a single server?
- 12.3 When is SQL Server Express acceptable?
- 12.4 When should a vessel use a Local Vessel Installation instead of an Online Vessel Installation?
- 12.5 Why is database proximity so important?
Purpose of this Article
This article provides planning guidance for deploying Adonis in host and vessel environments. It is intended to help customers choose the right deployment model, understand the recommended architecture, and size infrastructure for stable production use.
Deployment Models
Adonis can be deployed as a Host Installation, a Local Vessel Installation, or an Online Vessel Installation. The right model depends on where the environment is hosted, how users connect to it, and whether the vessel requires local operational continuity.
Host Installation (Main Office/Adonis Cloud)
A Host Installation is the standard model for central, shore-based production environments. It is typically used in customer datacenters, private cloud, or hosted platforms where Adonis is delivered as the main operational environment for office users and connected vessel operations.
Local Vessel Installation
A Local Vessel Installation is the standard vessel model when Adonis is self-hosted on customer-owned onboard hardware. This model is recommended when the vessel requires local system availability or where connectivity to shore is intermittent, bandwidth-limited, or not consistently low-latency.
Online Vessel Installation (Onshore Crew Portal)
An Online Vessel Installation is suitable only where the vessel has reliable broadband connectivity and consistently low response times to the central environment. In this model, the vessel connects directly to the hosted environment rather than maintaining a separate local onboard installation.
Vessel Deployment Rule
A vessel should be deployed either as a Local Vessel Installation or as an Online Vessel Installation. A single vessel should not use both models at the same time.
Recommended Architecture
The recommended Adonis architecture is based on one core principle: all major components should be deployed as close to the database as possible. SQL Server, web services, replication services, and user session delivery should remain within the same datacenter, region, or hosting location wherever possible. Splitting the solution across different datacenters can introduce latency, reduce performance, and increase operational complexity.
Recommended Host Architecture
For Host Installations, SQL Server should run on a separate dedicated server from the rest of the Adonis application stack. APP and AWR should run on the web tier, AR should run as a service on an appropriate server or virtual machine, and all components should be deployed within the same hosting environment as the database. Reference 6 server outline in diagram above.
Recommended Local Vessel Architecture
For Local Vessel Installations, the Adonis environment runs onboard on customer-provided vessel hardware. SQL Server should run locally on the vessel, and the onboard environment should be sized according to crew count, document volume, and replication needs. Reference 5 server outline in diagram above.
Recommended Online Vessel Architecture
For Online Vessel Installations, the vessel connects directly to the central hosted environment and does not maintain a separate local onboard installation. This model should only be used where connectivity quality is strong enough to support normal operational use without introducing unnecessary risk to performance or availability.
Infrastructure Design Principles
Adonis environments should be designed around a small number of practical infrastructure principles that improve performance, simplify support, and reduce avoidable deployment issues.
Keep All Components Close to the Database
The full solution performs best when all major components remain close to the database. It is not recommended to place SQL Server in one datacenter while hosting web services, replication services, or session hosts in another.
Separate SQL in Host Environments
For Host Installations, SQL Server should always be deployed separately from the rest of the application tier. This should be treated as a core production requirement for host environments.
All-in-One Is Vessel-Only
An all-in-one server deployment may be acceptable for some smaller Local Vessel Installations, depending on scale and operational requirements. It should not be used for a Host Installation.
Use Fast Storage for SQL
SQL Server should be deployed on SSD or NVMe storage in all environments. Fast storage is particularly important where document storage, replication activity, and backup-to-disk operations form part of normal day-to-day use.
Plan Backup Capacity
Host environments should include dedicated backup capacity for SQL Server. As a practical recommendation, host installations should include a separate 2 TB disk minimum for SQL backups as part of the production design.
SQL Server Guidance
SQL Server is a core part of every Adonis deployment and should be selected according to environment size, operational requirements, and expected growth. Customers should choose a SQL Server edition that fits both current usage and realistic future expansion.
Host Installations
For Host Installations, a full SQL Server edition should be used. This is the standard recommendation for central production environments.
Vessel Installations
For smaller vessel environments, SQL Server Express may be acceptable where expected database size, memory usage, and operational limits remain within a practical range. For larger vessel environments, or where crew numbers, scanned documents, or replication volume are expected to be significant, a full SQL Server edition is the better long-term choice. Keep in mind express versions limit the maximum database size, do not come with SQL Server Agent service, and limit RAM buffer pools to 1,410 MB.
Supported Version Direction
Customers should standardize on vendor-supported SQL Server editions for all new deployments. SQL Server 2019 and 2022 are supported, and SQL Server 2025 is expected to be supported for forward planning.
Minimum Infrastructure Recommendations
The recommendations below are intended as practical planning baselines for customers deploying Adonis in their own environment. Final sizing should always be confirmed against expected user load, document volume, integrations, retention requirements, and growth over time.
Host Installation Minimum Guidance
A Host Installation should be planned as a multi-tier environment, with SQL Server separated from the rest of the application stack. At minimum, customers should size SQL Server, the APP/AWR web tier, the AR service, and the user session-host tier as distinct roles rather than collapsing the environment into a single server.
Local Vessel Installation Minimum Guidance
A Local Vessel Installation should be sized according to the operational needs of the vessel, including crew count, replication scope, and expected document volume. Smaller vessels may be able to run a compact onboard deployment, while larger vessels should plan for stronger hardware and, where required, a full SQL Server edition instead of SQL Server Express.
Planning Baselines
For practical planning, customers should assume separate resources for SQL Server, web services, replication services, and user access delivery in host environments. As a starting point for self-hosted or customer-managed cloud platforms, a sensible baseline is 8 vCPU and 32 GB RAM for SQL in smaller environments, 4 vCPU and 16 GB RAM for the APP/AWR web tier, 4 vCPU and 16 GB RAM for AR, 4 vCPU and 16 GB RAM for File Server, and 4 vCPU and 16 GB RAM for each APM session host, with roughly one session host per 12 users where applicable. For customers attempting an All-in-one Vessel server a sensible baseline is 8 vCPU & 32 GB RAM. These should be treated as starting points only and adjusted for concurrency, integrations, document volume, and growth.
Storage Guidance
Storage planning should include space for the live database, backup-to-disk, restore operations, replicated files, and future growth. Customers should avoid sizing storage only for the initial database footprint.
Platform Support Policy
Adonis should be deployed only on vendor-supported editions of Microsoft operating systems, SQL Server, browsers, and related infrastructure components. Customers should use currently supported platforms for all new deployments and future upgrades.
Windows Server
For server workloads, Windows Server 2022 is the recommended baseline. Windows Server 2025 is expected to be supported for forward planning.
Web and Browser Platform
APP and AWR should run on Microsoft IIS or an equivalent supported hosting platform. Browser-based access should be standardized on supported versions of Microsoft Edge and Google Chrome.
Performance and Connectivity Guidance
Performance depends heavily on where solution components are deployed relative to the database. Customers should therefore make hosting and connectivity decisions with latency, bandwidth, and operational continuity in mind.
Keep the Full Solution in the Same Location
All major Adonis components should be deployed as close to the database as possible. SQL Server, web services, replication services, and user session delivery should remain in the same datacenter, region, or hosting environment wherever possible, because mixing datacenters introduces avoidable latency and additional support complexity.
Hosted Environments
In hosted or cloud-based environments, customers should avoid designs where users connect across long distances to components that are separated from the database. The preferred approach is to keep the full application stack together and deliver user access in a way that preserves low-latency communication with SQL Server.
Local Vessel vs Online Vessel
A Local Vessel Installation is generally the right choice where connectivity is inconsistent, bandwidth is limited, or the vessel requires local operational continuity. An Online Vessel Installation should only be used where connectivity quality is consistently strong enough to support day-to-day use without introducing unnecessary operational risk.
Replication and Document Considerations
Replication has a direct impact on infrastructure design, storage planning, and SQL edition choice, especially in vessel deployments. Customers should account for both data synchronization and document handling when deciding how to size and structure their environment.
Adonis Replicator
AR replicates only the data relevant to the vessel and supports scheduled synchronization between environments. Replication should be configured at regular intervals so that data packages remain smaller and easier to transfer and manage. Recommended every 5-10 minutes.
Bandwidth-Aware Replication
Where bandwidth is limited, replication can prioritize the most relevant metadata and defer scanned documents until conditions allow or replication is requested. This is an important consideration for vessel environments, particularly where document volume may affect both storage sizing and the practicality of SQL Server Express.
Document Volume and SQL Edition Choice
Customers planning to replicate significant volumes of scanned documents should account for the operational limits of SQL Server Express when sizing vessel deployments. As document volume, crew count, or growth expectations increase, a full SQL Server edition becomes the more suitable long-term choice.
Replication File Retention
The supported recommended retention range for replication files from the source server is 30–60 days. Customers should set the exact value within that range based on storage capacity, replication volume, and overall server performance.
Adonis Components
Adonis consists of four core application components that together support the full solution.
Adonis Personnel Manager (APM)
APM is the main Windows client application used in both host and vessel environments. Because it works closely with the database, its deployment should always be planned with database proximity and low-latency communication in mind. The application is generally installed on the file server and accessed by the client via a shortcut. The application is developed in Embarcadero Delphi 10.2 using 3rd party components for the user interface.
Adonis Personnel Portal (APP)
APP is the web-based portal component and can be used in both host and vessel environments. In vessel deployments, it can also function as the onboard crew portal where applicable. The application is developed in Microsoft .Net 4.7.
Adonis Web Recruitment (AWR)
AWR is part of the web-facing Adonis solution and is typically hosted alongside APP in the web tier. It should be treated as part of the overall application architecture and kept close to the database and the rest of the hosted components.
Adonis Replicator (AR)
AR runs as a service and supports replication between relevant environments. Its placement should be considered as part of the overall hosting design, especially where vessels, replicated documents, and bandwidth constraints are involved. It can installed in combination with the database server or the file server.
Quick Decision Guide
Choose a Host Installation for central production environments where Adonis is delivered from a shore-based or hosted platform. Choose a Local Vessel Installation where the vessel needs onboard autonomy or where connectivity is not consistently strong enough for direct online use. Choose an Online Vessel Installation only where reliable broadband and low response times can be sustained in normal day-to-day operation.
For SQL Server, use a full edition for all Host Installations and for vessel deployments with higher crew numbers, heavier document replication, or stronger growth expectations. SQL Server Express may be acceptable only for smaller vessel scenarios where those limits are clearly understood.
For infrastructure design, keep the full solution together and close to the database. Avoid mixing datacenters for SQL Server, web services, replication services, and user access delivery. Prefer a separate server for each component (SQL Server, Web Products(APP & AWR), AR, & APM) although consolidation may be acceptable only for smaller scenarios where those limits are clearly understood.
FAQ
Can a Host Installation be deployed on a single all-in-one server?
No. A Host Installation should be planned as a separated production design, with SQL Server deployed independently from the rest of the application stack.
Can a vessel run Adonis on a single server?
In some smaller Local Vessel Installations, an all-in-one deployment may be acceptable. This depends on the expected scale of the vessel environment, especially crew count, document volume, and growth expectations.
When is SQL Server Express acceptable?
SQL Server Express may be acceptable for smaller vessel deployments where the expected database size, memory usage, and document replication volume remain within a practical range. It should not be treated as the standard choice for host environments.
When should a vessel use a Local Vessel Installation instead of an Online Vessel Installation?
A Local Vessel Installation is the better choice when the vessel requires onboard continuity or where connectivity is intermittent, bandwidth-limited, or higher latency. An Online Vessel Installation should only be used where stable broadband and low response times are consistently available.
Why is database proximity so important?
Adonis performs best when the full solution remains close to the database. Separating core components across different datacenters or regions can introduce avoidable latency, reduce performance, and make the environment harder to support.