Server Deployment

Installers can elect how this instance of Pyramid will be installed - either to a single server or across two or more servers.

  • Single Server - quick and simple; perfect for personal or small deployments, testing and POC's.
  • Multi Server - more advanced for more complex, larger multi-user deployments where performance, load balancing, and fail over are considerations

Single Server Deployments

This is the quickest and simplest option where all components of Pyramid are installed onto a single machine (including virtual). This includes:

  • Internal Web server
  • Router service
  • Run Time Engine
  • Task Engine
  • DS-ML Server
  • Natural Language Processing Server
  • Solve Server
  • Windows Connector Service (Windows only)
  • Data Repository
  • In-memory database

Everything is installed to run without any other considerations and acts as a self-contained unit.

Multi Server Deployments

This approach allows users to hand-pick which tiers in the solution are installed on any given machine. Ultimately, this provides for a more sophisticated roll-out, where different servers with different hardware profiles can be used for the different application servers and services as appropriate.

Enabling Multi-Server

To enable a multi-server deployment, users can simply choose the "multi-server" option during the installation process. This both indicates to the host machine that the servers and services will be installed on a custom basis and allows the user to pick from a list of components to install.

The different tiers can be deployed on separate machines, or in any combination on several machines as needed. Importantly, each server needs to be installed on at least one machine in the cluster to enable the platform.

Prior to a multi-server installation make sure your servers can communicate with each other.

If you have firewalls setup, either temporarily turn them off, or open specific ports to enable the Pyramid services to communicate with each other.

These are the default Ports the product uses for each service - if any of them is already in use, the installation will try to look for an available one instead:

  • 8181 - Web server
    • 8282 - Web server
  • 12100 - Run Time Engine
    • 12101 - Run Time Engine
  • 12110 - Task engine
  • 12120 - Router
  • 12130 - PostgreSQL
  • 12140 - Windows Connector ("DNC")
    • 12141 - Windows Connector
  • 12150 - File Server
  • 12170 - In-memory Database ("IMDB")
  • 12200 - DS-ML Server ("AI")
  • 12190 - Agent
  • 12300 - Natural Language Processing server ("NLP")
  • 12400 - Solve server ("Solve")

Get the Password

You will need to enter a password for IMDB, and for PostgreSQL if using the built-in PostgreSQL option. The default password for IMDB is "pyramid."

Prior to version 2020.15, the password for the internal PostgreSQL instance is "pyramid". From version 2020.15 and above, the password for the internal PostgreSQL instance will be the name of the database (which is "pyramid" followed by an alphanumeric sequence) with an exclamation mark "!" after the word "pyramid".

To get the password, you need to open the config.ini file and find the database name. The password will then be "pyramid!alphanumericsequence". For instance, if the database name is "pyramid123blt", the password will be "pyramid!123blt".

Change the Password


To change the PostgreSQL password via CMD, enter the following command:

cd C:\Program Files\Pyramid\postgres\pgsql\bin

set PGPASSWORD=CurrentPassowrd

psql -h localhost -d DB name -U pyramid -p 12130 -c "ALTER USER pyramid WITH PASSWORD 'NewPassword';"

This command must be run on the server running the Pyramid PostgreSQL service.

Update Repository Credentials

For instructions on how to update the password in the Pyramid config.ini., use the following link (only relevant for versions prior to 2020.20):

Run Tool

If you are using 2020.20 and above, there is a maintenance tool named "run" that can change the password. The path to this tool is C:\Program Files\Pyramid\core\maintenance.

Subsequent Adding and Removing of Services

There are 2 entry points for subsequently adding or removing services in a multi-server deployment:

  • Services can be added by rerunning the installer - which will trigger the upgrade engine and offer the user an opportunity to add new services to an existing host.
  • Services can be removed by running the uninstaller - which will allow users to either uninstall the entire product on a host or select specific services to remove.

More details on these steps can be found here.

Adding the In-Memory Database (IMDB) Server

When installing Pyramid as a multi-server install, you will need to manually add the IMDB server to your list of servers:

  • Server name: the name of the sever on which the In Memory server was installed.
  • Port: 12170
  • Username: default
  • Password: pyramid
Built-In PostgreSQL Database

Users can select the built-in PostgreSQL database when installing Pyramid as a multi server deployment. Both the username and password to connect to the PostgreSQL database is "pyramid", which must be entered when adding the second (and successive) server(s) to your deployment.

Note regarding Pulse: For the Pulse client to work, it needs to be able to connect to your Pyramid website. If your internet is restricted, please allow access to your Pyramid website.

Multiple Service Instances

All tiers in the platform "stack" can be installed multiple times across multiple servers to provide horizontal load balancing and fail over. In almost all cases, the servers will act in active-active mode, with the platform self-balancing requests as needed, with only these exceptions:

  • Web Servers - these are not load balanced by the application. Multi web servers need to be load balanced by an external load balancing technology.

Note: The Pyramid platform is designed to eliminate the need for 'sticky' sessions or persistence in the web load balancing strategy

  • Router Services - these servers act in active-passive mode, where only a single router is actively managing all the tiers in the cluster at any given time. Secondary routers will assume control if the primary router becomes inoperable.

Data Repository

When installing the services on different machines, they must all use a common database repository. Without this, the services will not be able to join the cluster and act as a single platform. See here for more.