Created by James Hurrell, last modified on Feb 19, 2024

Summary: information to help you plan your AIP for Imaging installation.

Typical communication between CAST components

The following diagram shows the interaction between AIP Console and the main CAST Components. It also shows the flow from the source code delivery to the CAST Imaging data consumption:


Required components

Package/ComponentDescription
CAST Imaging

CAST Imaging is the component used to display and investigate the analysis results:

  • This component can be installed on Windows (directly or via Docker) or Linux (via Docker).
  • Only one instance can be "fed" with analysis results.
AIP Core

AIP Core is the "backbone" analysis engine:

  • This component can be installed on Windows servers only.
  • Can only be installed once per instance of Windows.
CAST Storage Service / PostgreSQL

This component provides the storage (i.e. database schemas) for the analysis result data. It can be installed:

  • on Windows (use the prepackaged CAST Storage Service installer or run PostgreSQL via Docker) or Linux (install PostgreSQL directly or run PostgreSQL via Docker)
  • multiple times, i.e. you can use multiple CAST Storage Service/PostgreSQL instances
  • BEFORE you install the AIP Console and AIP Nodes packages - in v.1.x details of the instance are required during installation and initial setup (this is no longer the case in v. 2.x)
CAST highly recommends the use of PostgreSQL on a Linux instance as this consistently gives the best performance.
AIP Node service (back end)


The AIP Node "back end" service contains the RESTful APIs that interact with AIP Core on the same host server and the remote CAST Storage Service/PostgreSQL, AIP Console and CAST Imaging instances. This package:

  • should be installed on all servers where AIP Core is already installed.
  • is provided in the AIP Console ZIP file, as an installable .JAR file together with the AIP Console (front end).
  • can be installed on Windows servers only.
  • Can only be installed once per instance of Windows.
AIP Console service (front end)

The AIP Console "front end" service connects and manages all the AIP Node(s). Users will connect (using a browser) directly to this package to manage the analyses of their Applications. This package:

  • should only be installed once.
  • can be installed on Windows or Linux servers.
  • is provided as Docker containers (v. 2.x only), or in the AIP Console ZIP file as installable .JAR files, together with the AIP Node (back end).
  • contains the Health and Engineering Dashboards

Optional components

Package/ComponentDescription
CAST Extend Offline or CAST Extend local server

These components are only required if (due to security concerns) your organization/AIP Console cannot interact over the public internet with CAST's Extend system for Extension management. The components provide CAST's Extend system as an "offline" on-premises component:

  • should only be installed once
  • can be installed only on Windows servers
  • should ideally be installed BEFORE you install the AIP Console and AIP Nodes packages. This is so that when running the initial start-up wizard for AIP Console, you already have all the details that are required.
  • All AIP Nodes require access to CAST Extend Offline/Proxy.
  • If the AIP Node accessing CAST Extend Offline/proxy is configured to pass all outgoing connections through a proxy (via the Windows proxy settings or via the AIP Console settings), then you may need to whitelist the IP address/host name of the server running CAST Extend Offline/Proxy in order to route connections correctly.
  • CAST Extend Proxy can be configured in offline or online mode (CAST Extend Offline is always offline):
    • When in offline mode, functionality is the same as CAST Extend Offline and extensions must be added manually to CAST Extend Proxy.
    • When in online mode, CAST Extend Proxy is configured to connect with CAST's Extend system for Extension management over the public internet.

Storage considerations

As shown in the above diagram, there are five main storage folders (marked in yellow). All AIP nodes must have access to these folders:

FolderLocation in v. 2.xLocation in v. 1.x
deliveryCommon shared folder (obligatory)AIP Node (default) or Common shared folder if necessaryUsed for storing successive and compressed versions of an application's source code produced during the source code delivery phase. This folder contains all the versions of the source that have been delivered. This folder is usually the largest of all storage folders.
deployCommon shared folder (obligatory)

Used in Standard delivery mode for storing an application's source code in uncompressed format - this is the code that is analyzed. When the delivery is accepted and imported, the deploy folder is cleaned and the current version of the source code is deployed in the deploy folder.

common-dataCommon shared folder (obligatory)N/AA common location used for AIP Node related data (backup, sherlock, upload and other folders used by the AIP Node).
logsAIP Node (default) or Common shared folder if necessaryAIP Node (default) or Common shared folder if necessaryUsed for storing all logs produced by the AIP Node with regard to code delivery/analysis/snapshot activities. One sub-folder folder will be created per Application onboarded in AIP Console. The log files will contain the path and the name of the source file. For some warning messages (e.g.: syntax error), the path of the source code involved in the warning is shown in the log.
LISA / LTSA

Location to store temporary files generated during the analysis/snapshot process on each AIP Node:

  • Large Intermediate Storage Area (LISA) - cleaned on completion of each analysis.
  • Large Temporary Storage Area (LTSA) - is permanent and contains preprocessed source code files, archive files for analysis etc.
Note that some analyzers/extensions, need to preprocess the source code before performing the analysis. In this case, the source code that will be analyzed is stored in the LISA folder, not in the Deploy folder.
extensionsUsed for storing AIP extensions. Must always be located on the node.

When an analysis is run, the analyzed source code files are uploaded into the Analysis schema (local).

Storage folder distribution strategy

This section explains the different ways that can be used to distribute the required storage folders:

  • Local distribution only (v. 1.x only, in 2.x a shared folder is required for delivery/deploy/common-data (except where using an all on one machine deployment for demos and POCs))
  • Local and network distribution
  • Network distribution only

We also describe the relationship between performance and scalability depending on the way you choose to deploy the storage folders. In addition, we suggest some required disk space recommendations (minimum recommendations and advised configuration for a large number of applications) depending on the chosen storage folder distribution strategy.


  • This icon depicts the server on which the AIP Node service and AIP Core are installed.
  • CAST Storage Service / PostgreSQL can be installed on the AIP Node instance or on a separate and dedicated server (recommended).

Local distribution: better performance / lower scalability - v. 1.x only

Note that in a 2.x deployment, a shared folder is required for delivery/deploy/common-data, therefore this strategy is not possible (except where using an all on one machine deployment for demos and POCs).

All the storage folders are on the local server - i.e. the AIP Node:

The limiting factor for this deployment is that all these folders can grow very quickly during an analysis, therefore, they can potentially overload the local disks on the server.

Disk space recommendations

Minimum recommendationLocal storage (all folders)256GB
Run multiple applications in parallel (minimum)Local storage (all folders)1TB

Balance between storage and performance: medium performance / medium scalability

The Delivery/Deploy/Common-data and the Logs folders are located on a shared network drive. Other folders are located on the local server - i.e. the AIP Node instance:

The aim of using a shared network folder for the Delivery/Deploy/Common-data and Logs folders is to accommodate the potentially large amount of storage that is required. The size of these folders can grow very quickly during an analysis (in particular the Delivery folder which stores multiple versions of a given Application's source code).

This configuration reduces the risk of overloading the local server's disk space, however, performance during analysis will be slightly reduced since the log file is located on a shared network drive, and an analyzer will require slightly more time to write to it during an analysis.

Disk space recommendations

Minimum recommendationLocal storage (LISA and LTSA and Extensions folders)86GB
Network storage (Delivery/Deploy/Common-data and Log folders)170GB
Run multiple applications in parallel (minimum)Local storage (LISA and LTSA and Extensions folders)300GB
Network storage (Delivery/Deploy/Common-data and Log folders)700GB

Network distribution: lower performance / better scalability

All the storage folders, except "extensions" (which must always be located on the node), are located on a shared network drive:

This configuration will never overload the local disk space, however, performance during analysis is slower compared to the first deployment scenario for the following reasons:

  1. The time required to load the source code in to memory from a network drive is inevitably longer.
  2. Slower log file updates
  3. Temporary files will be generated more slowly.

Disk space recommendations

Minimum recommendationLocal storage (Extensions folders)50 GB
Network storage (All other folders)256GB
Run multiple applications in parallel (minimum)

Local storage (Extensions folders)50GB
Network storage (All other folders)1TB

Note that to analyze .NET applications with assemblies stored in a remote network location, you will need to alter the machine configuration by proceeding as described in the .NET Analyzer in the section Prerequisites.

Source code replication

The following diagram shows how your source code is replicated among the various different storage locations during the onboarding and analysis process:

RAM considerations for AIP Console (front-end) and AIP Nodes

See Configuring RAM for AIP Console front-end and AIP Nodes for more information.

Windows Services user account considerations - Microsoft Windows only

Both the AIP Console front-end and the AIP Node back-ends are run as Windows Services on the relevant Windows machine. CAST highly recommends that the Local System account is not used to run these Windows Service. This is particularly true if:

In both these situations, the user running the Windows Service will be used to access the proxy/shared network resources.

Instead, CAST recommends using the login credentials that match the log in used to install AIP Console/AIP Node/AIP Core/set system proxy settings etc. - for example, this could be a specific "service account" that is created specifically for installing and running AIP Console/AIP Nodes/AIP Core/setting system proxy settings. This service account would also therefore have access to the shared network resources and would be able to use the system proxy settings.

Proxy considerations

If your organization requires the use of a proxy, please take the following into account:

Extension Downloader limitation

At the current time, the Extension Downloader (a tool present on each AIP Node which is used by AIP Console to download extensions) cannot be configured to obey a manual proxy configuration defined in AIP Console. Instead, if your organization uses a proxy, CAST recommends that:

  • you define the required proxy configuration at system level (i.e. operating system level) on all AIP Nodes
  • define a manual proxy configuration using the settings described below - this ensures that everything else will connect through the proxy

Windows Services

AIP Console and the AIP Nodes packages are configured to run through Windows Services, therefore it is important to ensure that the user login configured to run the Windows Services has permission to access any proxy that you define. If the user running the Windows Services cannot access the proxy, then AIP Console/AIP Nodes will not be able to access the required resources. See the sections regarding the configuration of the Windows Services in:

Which deployment architecture should you use?

Deployment scenarioComponentServer TypeOSRecommended deployment architecture
Multi-node (Large/Enterprise)CAST ImagingPhysical / VirtualMicrosoft Windows or LinuxInstallation CAST Imaging on a dedicated dedicated Windows or Linux server.
AIP CorePhysical / VirtualMicrosoft Windows

AIP Core/AIP Node package

  • installation of AIP Core once per dedicated Windows server.
  • installation of the AIP Node package once on all Windows servers where AIP Core is already installed.
  • together both packages form an "AIP Node": multiple AIP Nodes can be managed through AIP Console.
AIP Node (back end)
AIP Console (front end)

Physical / Virtual

Microsoft Windows or Linux

Installation of the "front-end" AIP Console package on a dedicated Windows or Linux server to manage all the AIP Nodes.

CAST Storage Service (CSS) / PostgreSQLPhysical / VirtualMicrosoft Windows or Linux

Details of the CAST Storage Service/PostgreSQL instance will be required during the installation of each AIP Node package: all that is required is that the AIP Console installer can access all required CAST Storage Services/PostgreSQL. How you choose to deploy the CAST Storage Service/PostgreSQL generally depends on the types of Application you are onboarding using the AIP Console, however, CAST recommends the following as a minimum:

  • 1 x CSS/PostgreSQL (on a dedicated Windows (CSS) or Linux (PostgreSQL) server) for all small and average sized Applications (i.e. multiple AIP Nodes per CSS/PostgreSQL instance)
  • 1 x CSS/PostgreSQL (on a dedicated Windows (CSS) or Linux (PostgreSQL) server) per Application for all large Applications (i.e. one dedicated AIP Node + dedicated CSS/PostgreSQL instance per large Application)
  • 1 x CSS/PostgreSQL (on a dedicated Windows (CSS) or Linux (PostgreSQL) server) for the MEASUREMENT schema
CAST Extend Offline or CAST Extend local server

Physical / Virtual

Microsoft Windows

If you need to deploy the CAST Extend Offline or CAST Extend local server, details of this service will be required during the initial start up of AIP Console: all that is required is that the wizard can access CAST Extend Offline/Proxy. CAST recommends using either:

  • a dedicated Windows server to host the service
  • re-use one of the existing servers dedicated to the CAST RESTAPI or AIP Node, providing that this is a Windows server
  • If the AIP Node accessing the CAST Extend Service is configured to pass all outgoing connections through a proxy (via the Windows proxy settings or via the AIP Console settings), then you may need to whitelist the IP address/host name of the server running CAST Extend Service in order to route connections correctly.
Single server (Small/Simple)CAST ImagingPhysical / VirtualMicrosoft Windows

If you have one single AIP Core installation that you would like to manage with the AIP Console, choose this option, which involves the installation of all packages/components on one single Windows server.

Note that:

  • Although it is possible to run all required packages and components from one single high spec Windows server (for example in very small deployments or for testing purposes), CAST does not recommend this approach for "production" environments.
  • Details of the CAST Storage Service/PostgreSQL and CAST Imaging will be required during the installation: all that is required is that the AIP Console installer can access it.
  • Details of CAST Extend Offline/Proxy (should you wish to deploy it) will will be required during the installation: all that is required is that the AIP Console installer can access it.
AIP Core
AIP Node (back end)
AIP Console (front end)
CAST Storage Service (CSS) / PostgreSQL
CAST Extend Offline or CAST Extend local server

Type of Applications being onboarded

The method and hardware chosen to deploy CAST components and packages depends on the type of the Application(s) you intend to onboard with AIP Console. Various factors related to the Application(s) you are analyzing must be considered:

  • Number of lines of code (LOC) in the Application (in general, CAST considers an Application with over 3 million lines of code to be "large", however, this figure is not set in stone and smaller Applications may require dedicated resources).
  • Number of objects after analysis
  • Number of violations after analysis
  • Technologies used
  • Number of users accessing results

When onboarding "large" applications you should carefully consider how you deploy the required components and packages - particular attention should be paid to:

  • AIP Core/AIP Node - dedicate one server for each large Application - or if this is not possible, run analyses of one single large application one at a time
  • CAST Storage Service / PostgreSQL - dedicate one server and CAST Storage Service/PostgreSQL instance for each large Application - use Linux/PostgreSQL to improve performance