Common prerequisites for Kyvos Enterprise Deployment

Common prerequisites for Kyvos Enterprise Deployment

✅ Enterprise: AWS, Azure, GCP, and On-Premises


Overview

This section outlines the common prerequisites that must be verified and configured before deploying Kyvos Enterprise to ensure the environment is properly prepared for installation.

Common prerequisites for all clouds

  • Verify supported Operating Systems as per Kyvos release version.
    For details, check the Supported environments and applications section mentioned in Release Notes for each release.

  • Python version 3.6.8 must be installed.

  • User account and permissions:

    • Installation path: must have read and write permissions for the user’s account (non-root) that is being used for Kyvos deployment.

  • Free disk space is required on all the nodes of the cluster.

  • Required ports for Kyvos

  • Kyvos Manager uses SSH to connect with cluster nodes.
    As Kyvos Manager is a distributed cluster lifecycle management tool, SSH-based access to cluster nodes is required for various lifecycle management activities (such as upgrade, patch, rollback, configuration and services management, configuration syncing, etc.).

  • Kyvos Manager expects the scp command to be available as a prerequisite (with execute permissions) on all cluster nodes.
    This is required to copy files (such as application binary bundles for upgrade, patch, or license) from the Kyvos Manager node to the cluster nodes.

  • The Required OS commands must be installed. The OS commands are used by Kyvos Manager and Kyvos. Therefore, these commands must be present on all cluster nodes. 

  • Required permissions in role attached on machines for cloud-based deployments

    • AWS (IAM)

    • Azure

    • GCP

  • Increase max map count on all nodes on each Kyvos node (analytical server, Query Engine, and Kyvos Manager).

    • Execute the vi /proc/sys/vm/max_map_count command.

    • Update the value to 524288 in the /proc/sys/vm/max_map_count file.

  • Increase the limit of Kyvos user on all nodes using the command as root user:

    echo kyvos hard nofile 524288 >> /etc/security/limits.conf echo kyvos hard nofile 524288 >> /etc/security/limits.d/20-nproc.conf echo kyvos soft nofile 524288 >> /etc/security/limits.conf echo kyvos soft nofile 524288 >> /etc/security/limits.d/20-nproc.conf

Prerequisites for No Hadoop No-Spark Kyvos Deployment

  • Same Network File System (NFS) must be mounted on each compute node of cluster.

Prerequisites to install PostgreSQL 16 for wizard-based deployments

For performing wizard-based deployment using PostgreSQL 16 as an installed service, the following manual prerequisites must be completed prior to deployment.

  1. Install PostgreSQL 16 Service: Manually install the PostgreSQL 16 service on the Kyvos Manager (KM) node by executing the Kyvos-provided installation shell configure-postgres16.sh script.
    Note: This script must be executed using a sudo or root user.

  2. Update JDBC Properties: Before starting Kyvos Manager, update the jdbc.properties file to set the following property:

    installedRepo=true

To migrate from the bundled PostgreSQL 13 to the installed PostgreSQL 16 after upgrading to the 2025.10 release, see the Migrating PostgreSQL Repositories section.

Prerequisites for SNS-based deployment

  • Machines must have at least 32 GB memory.

Mandatory prerequisites for Subject Alternative Name (SAN)-Enabled TLS Certificates

From Kyvos release 2026.5 onwards, all clouds Enterprise, SaaS, and marketplace deployments running with JRE 17 must use SAN-enabled TLS certificates. The certificate's Subject Alternative Name (SAN) extension must include the IP addresses and/or hostnames of all Analytical Server, Web Portal, Query Engine, and Kyvos Manager nodes. Certificates that do not contain the required SAN entries are not supported. You must validate and update their certificates before upgrading to this release.

Platform

Deployment type

TLS (Yes/No)

JRE version

SAN Enabled TLS Certificates (Yes/No)

Platform

Deployment type

TLS (Yes/No)

JRE version

SAN Enabled TLS Certificates (Yes/No)

Clouds Enterprise (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

On premises

No-Spark

Yes

8

No

Marketplace (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

SaaS (AWS, Azure, and GCP)

No-Spark

Yes

17

Yes

Note

  • This is not applicable to on-premises or any cloud environment running with Java8 setup.  

  • When adding a node from Kyvos Manager, the TLS certificate must contain SAN entries for the IP addresses and/or hostnames of all Analytical Server, Web Portal, Query Engine, and Kyvos Manager nodes.

  • Post Disaster Recovery (DR), new SAN-enabled TLS certificates must be generated and configured.

To validate that a certificate contains the required Subject Alternative Name (SAN) entries, run the following command:

  1. Open a terminal on the system where OpenSSL is installed.

  2. Run one of the following commands based on your deployment type:

    • For existing TLS-enabled deployments:

      openssl s_client -connect SERVER.DOMAIN.COM:PORT -servername DOMAIN.COM </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
    • For new deployments:

      openssl x509 -in certificate.crt -noout -ext subjectAltName
  3. Review the command output and verify that the Subject Alternative Name (SAN) extension contains all required DNS names and/or IP addresses for the deployment.

    Example:

    DNS:kyvosinsights.zendesk.com or IPs or Both
  4. Ensure that the SAN extension includes the hostnames and IP addresses of all applicable Analytical Server, Web Portal, Query Engine, Compute Master (for Azure Kubernetes-based deployments with compute master only), and Kyvos Manager nodes.

  5. If any required DNS names or IP addresses are missing, update and reissue the certificate before proceeding with the deployment or upgrade.

Copyright Kyvos, Inc. 2026. All rights reserved.