Other Platforms

warning

Cortex version 2.0 (and beyond) require a read-write connection to a Cortex-specific data store. This can be the same database, a completely separate database, or a completely separate database server/service.

You can find more information about how to configure this on the Connection Strings page.

Pre-requisites

• Something that reverse-proxies web traffic: nginx, an AWS ALB, an Azure App Gateway, a Kubernetes ingress, etc. (configuring this is outside of the scope of this document)
• Something you can run the app on. Windows, Linux, Mac, another platform that can run a .NET 7 app
• Your Cherwell database, restored to a Microsoft SQL Server instance (with Full Text Indexing installed)

Install

Pick the appropriate build for your system.

• win-x64 - Self-contained build for Windows (does not require an installed .NET runtime)
• linux-x64 - Self-contained build for Linux (does not require an installed .NET runtime)
• net7 - Runtime-dependent build for any OS (requires an installed .NET 7 runtime)

Download from the download site (registration required).

IIS

1. Install the ASP.NET Core Module/Hosting Bundle
2. Unzip either the win-x64 or the net7 build into a directory IIS has access to.
3. Set up an "application" pointing at the unzipped assemblies.
4. Configure using config files (see below).

As a standalone binary

1. Unzip the appropriate binaries for your system (Windows vs. Linux, whether you have a .NET 7 runtime installed or not).
2. Configure using configuration files or set the appropriate environment variables (see below).
3. Run the binary Cortex.exe (Windows) or Cortex (Linux or Mac) from a Terminal.
4. For production, run this behind a reverse proxy like nginx; with a container orchestrator like Amazon ECS, Azure Container Apps, or Kubernetes; or host with IIS (see above).

Configuration

Two items need to be configured:

• Database connection to a previously installed Cherwell database (See here for details on creating a connection string)
• Your Cortex License "company name" and License code (NOTE: These are different from your Cherwell license)

If you don't have a Cortex License, the software will run with result sets limited to 10 records.

Environment Variables

Best for container-based deployments. Set the following environment variables:

• CUSTOMCONNSTR_Default - a .NET Connection String pointing to a MS SQL database
• Licensing:CompanyName (Windows) or Licensing__CompanyName (Linux/Mac) - the company name specified with your license
• Licensing:LicenseCode (Windows) or Licensing__LicenseCode (Linux/Mac) - your license code, e.g. (XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX)

Configuration Files

Edit the file appsettings.json to fill in the values below:

{
  // ...
  "ConnectionStrings": {
    "Cherwell": "READ (WRITE OPTIONAL) CONNECTION STRING FOR CHERWELL DATA",
    "Cortex": "READ/WRITE CONNECTION STRING FOR CORTEX DATA"
  },
  "Licensing": {
    "CompanyName": "YOUR COMPANY'S NAME HERE",
    "LicenseCode": "YOUR LICENSE CODE"
  },
  "Authentication": {
    "Type": "ONE OF: none, saml, keycloak",
    // ...
  }
}

After modifying this file, restart the application to apply the configuration.

Next Steps

HTTPS/SSL

warning

If you are using SAML for authentication, HTTPS/SSL may be required (it is certainly recommended). If you add HTTPS later, you may have to change your SAML configuration.

It is highly recommended that you configure HTTPS/SSL for the server running the Cortex application. How to do this is outside the scope of this documentation, because it is highly environment and infrastructure dependent. For instance, you might choose to use a self-signed certificate installed in IIS. Or a fully-signed cert from a local certificate authority. Or a full cert from a third-party CA. Or you might run a reverse proxy in front of either IIS or a container, that handles HTTPS in yet another way.

We might be able to provide guidance if we have familiarity with your specific technology, but the most knowledgeable people will undoubtedly be your own infrastructure team.

Authentication

In most cases, we start with using the authentication type none so we can verify connectivity to your database without adding extra variables to the mix.

However, Authentication:Type none is not recommended for production. You should instead configure your desired authentication type (SAML or OpenID Connect).

Leaving Authentication:Type set to none means that all of your data is accessible to anyone who can visit the HTTP site on the system running Cortex and is extremely insecure. This mode is meant solely for initial setup and verification.