Server Installation Requirements
Setting up the server is a critical first step in any KYP.ai implementation. Before starting, decide whether to proceed with a cloud-based or on-premise setup:
Cloud servers are deployed and maintained by KYP.ai or an authorized partner.
On-premise servers are installed and maintained by your internal IT team.
All system components run in Docker containers on a single machine. The specs below apply to virtualized environments. For physical (bare metal) setups, contact KYP.ai for tailored requirements.
Infrastructure Requirements
💡 Key Notes:
The setup assumes server virtualization.
Resource needs to depend on data volume, number of users, and enabled features.
For environments with 1000+ users, consult the KYP.ai Team.
🖥️ Configuration for OPS Monitoring (No Screenshot Processing)
Users | <350 | 350 – 700 | 700 – 1000 | 1000 – 2300 | 2300 - 5000 |
|---|---|---|---|---|---|
CPU | 4 vCPU | 8 vCPU | 12 vCPU | 20 vCPU | 44 vCPU |
Memory | 32 GB | 48 GB | 64 GB | 128 GB | 256 GB |
Storage* | 0,15 - 1 TB / IOPS ~1000** | 1,8 TB / IOPS ~1500** | 2,5 TB / IOPS ~3000** | 5,6 TB / IOPS ~3000** | 12 TB / IOPS ~3000** |
📸 Configuration for Process Discovery / PoC (With Screenshot Processing)
Users | < 200 | 200 – 550 | 550 – 1000 | 1000 – 2650 | 2650 - 5000 |
|---|---|---|---|---|---|
CPU | 4 vCPU | 8 vCPU | 16 vCPU | 28 vCPU | 52 vCPU |
Memory | 32 GB | 64 GB | 128 GB | 256 GB | 512 GB |
Storage* | 0,3 - 1,4 TB / IOPS ~3000** | 3,6 TB / IOPS ~4500** | 6 TB / IOPS ~6000** | 17 TB / IOPS ~6000** | 27 TB / IOPS ~6000** |
* Fast, attached disk as the additional partition. File system: ext4 or xfs with ftype=1 (d_type support enabled).
** Storage calculated based on: 30 days screenshots retention, 20% usage of screenshot apps by all users and a 12 month contract.
☁️ Public Cloud – Recommended Instance Types
The following tables provide cloud instance recommendations for different user ranges and use cases. Prices may vary depending on region and provider.
🔧 Operations Steering (Excluding Screenshot Processing)
Users | AWS | GCP | OVH | Azure | OCI |
|---|---|---|---|---|---|
< 350 | r5.xlarge (GP3) | n2-highmem-4 (SSD persistent disk) | r3-32 (high speed storage) | Standard_E4as_v5 (premium SSD) | VM.Standard3.Flex (2 OCPU, 32 GB) with balanced volume |
350 - 700 | r5.2xlarge (GP3) | n2-highmem-8 (SSD persistent disk) | r3-64 (high speed storage) | D16as v6 (premium SSD) | VM.Standard3.Flex (4 OCPU, 48 GB) with balanced volume |
700 - 1000 | m5.4xlarge (GP3) | n2-standard-16 (SSD persistent disk) | b3-64 (high speed storage) | D16as v6 (premium SSD) | VM.Standard3.Flex (6 OCPU, 64 GB) with balanced volume |
1000 - 2300 | m5.8xlarge (GP3) | n2-standard-32 (SSD persistent disk) | b3-128 (high speed storage) | D32as v6 (premium SSD) | VM.Standard3.Flex (10 OCPU, 128 GB) with balanced volume |
2300 - 5000 | m5a.16xlarge (GP3) | n2-standard-64 (SSD persistent disk) | b3-128 (high speed storage) | D64as v6 (premium SSD) | VM.Standard3.Flex (22 OCPU, 256 GB) with balanced volume |
📸 Process Discovery (Including Screenshot Processing)
Users | AWS | GCP | OVH | Azure | OCI |
|---|---|---|---|---|---|
< 200 | r5.xlarge (GP3) | n2-highmem-4 (SSD persistent disk) | r3-32 (high speed storage) | Standard E4as v5 (premium SSD) | VM.Standard3.Flex (2 OCPU, 32 GB) with high performance volume |
200 - 550 | r5.2xlarge (GP3) | n2-standard-16 (SSD persistent disk) | r3-64 (high speed storage) | D16as v6 (premium SSD) | VM.Standard3.Flex (4 OCPU, 64 GB) with high performance volume |
550 - 1000 | r5.4xlarge (GP3) | n2-standard-32 (SSD persistent disk) | r3-128 (high speed Gen2 storage) | D32as v6 (premium SSD) | VM.Standard3.Flex (8 OCPU, 128 GB) with high performance volume |
1000 - 2650 | r5.8xlarge (GP3) | n2-standard-64 (SSD persistent disk) | r3-256 (high speed Gen2 storage) | D64as v6 (premium SSD) | VM.Standard3.Flex (14 OCPU, 256 GB) with high performance volume |
2650 - 5000 | r5a.16xlarge (GP3) | n2-highmem-64 (SSD persistent disk) | r3-512 (high speed Gen2 storage) | D128as v7 (premium SSD) | VM.Standard3.Flex (26 OCPU, 512 GB) with high performance volume |
Network Requirements
🔓 Required Open Ports
80 – Redirects to 443
443 – Data transfer and frontend access (HTTPS)
22 – SSH access for maintenance
🌐 External Access
Allow traffic to:
CentOS repositories
Docker Hub (
https://download.docker.com)*.kyp.aifor installation & monitoring
Customer workstations → Server on port 443
Register DNS entry for the server and workstations
Generate Valid SSL certificate for the server domain name (FQDN) and provide to KYP.ai
HTTPS traffic cannot be filtered for specific phrases or conditions
Minimum bandwidth: 2 Mb/s per 50 users
OPTIONAL: If Concierge extension is enabled with Open AI LLM, then outbound traffic on port 443 is required for Concierge to work https://api.openai.com/v1
🔄 Optional Network Configurations
In case of Load Balancer usage:
Register DNS entry for the load balancer
SSL certificate generated for the load balancer in desired domain added to trusted certificates store
Load Balancer traffic on port 443 should be redirected to the server on port 80
Data collection monitoring outbound communication port to email server on port 587/465
LDAP/Active Directory communication to LDAP server on port 389/636
SSO (Azure AD):
Access
https://login.microsoftonline.comandhttps://graph.microsoft.com
Average daily traffic received for one user
If you want to check the average daily traffic generated by a single user, please refer to this article.
Backup Policy
Valuable data and configurations are encouraged to be backed up regularly of KYP.ai databases. While backups may take up some disk storage space, it will save you from future data loss. Protect your precious assets and ensure peace of mind.
Application backup is necessary to protect against data loss or corruption caused by hardware failure, software malfunction, cyber-attacks, or human error.
Losing applications and their data can result in downtime, financial losses, and reputational damage.
Regular backups allow businesses to recover quickly from disasters and minimize the impact of data loss.
Application backups help ensure compliance with regulatory requirements and avoid fines and legal penalties.
KYP.ai offers two methods for application backups: configuring backups in a specific directory or using customer-provided storage solutions like AWS S3.
Customers must specify the backup frequency and retention period from KYP.ai settings.
The best practice is to create automatic daily backups of the database and keep them stored for at least 7 days to enable easy restoration of functions in case of issues.
Software Requirements
🖥️ OS Compatibility
Recommended: Ubuntu 22.04.5+
Optional: RHEL 8.7+
🧰 Required Tools
Tool | Version |
|---|---|
| 1.21 |
| 7.81.0 |
| 3.0 / 6.0 |
| 3.0.5 / 0.7.5 |
| 4.8.27 |
| 29.1.2 |
| 5.0.0 |
| 3.19.0 |
| 8.2 |
| latest |
apache2-utils (for ubuntu) | latest |
jq | latest |
httpd-tools (for redhat) | latest |
KYP.ai packages are downloaded during installation from the official repository.
Access Requirements (Optional) - only if support is requested
HTTPS for KYP.ai Support Team for troubleshooting and support.
SSH (root) access for KYP.ai DevOps Team for installation and daily maintenance
HTTPS access for KYP.ai Customer Success Team for configuration and data analysis.
(Optional) Provision a Windows 11 VM for testing the KYP Connect App
FAQ
Should I choose a cloud or on-premise setup for KYP.ai?
It depends on your organization's preferences:
Cloud: Hosted and managed by KYP.ai or an Implementation Partner.
On-Premise: Installed and managed by your internal IT team.
Is a backup policy included in the default setup?
Yes. By default, the KYP.ai server:
Retains the last 6 days of database backups on local storage.
Backup location and retention policy can be changed and need to be agreed upon before deployment.
Best practice is to store backups on external storage (e.g., AWS S3).
Who maintains the server after installation?
Cloud installations: Fully maintained by KYP.ai.
On-premise installations: Maintained by your IT team, with KYP.ai providing support for updates, troubleshooting, and configuration via remote access.
How can I check the requirements if I can’t run the diagnostic script?
The diagnostic script includes all required checks and, after answering a few questions, will generate a report for both you and KYP. If you are unable to execute the script, example commands are provided below to assist you in manually verifying the requirements. The results are saved in the requirements_test.log file, which should be shared with KYP.ai.
Description | Command |
Shows all IP addresses of the host and resolves a hostname to IPv4/IPv6 addresses. | echo "Local IPs:" | tee -a requirements_test.log |
Displays OS identification details. | cat /etc/os-release | tee -a requirements_test.log |
Shows the number of available CPU cores. | nproc | tee -a requirements_test.log |
Shows memory usage in GB. | free -g | tee -a requirements_test.log |
Lists block devices: name, size, and type. | lsblk -ndo NAME,SIZE,TYPE | tee -a requirements_test.log |
Shows filesystem usage and mount points. | df -h --output=source,fstype,size,used,avail,pcent,target | tee -a requirements_test.log |
Writes a test file to measure disk write performance. | dd if=/dev/urandom of=/home/.disk_test bs=4096 count=5000 oflag=direct | tee -a requirements_test.log |
Reads the test file to measure disk read performance. | dd if=/home/.disk_test of=/dev/null bs=4096 count=5000 iflag=direct | tee -a requirements_test.log |
Tests internet connectivity over IPv4. | ping -c 2 -W 3 8.8.8.8 | tee -a requirements_test.log |
Tests internet connectivity over IPv6. | ping6 -c 2 -W 3 2001:4860:4860::8888 | tee -a requirements_test.log |
Shows the Docker version. | docker --version | tee -a requirements_test.log |
Checks whether the Docker service is active. | systemctl is-active docker | tee -a requirements_test.log |
Pulls a test Docker image. | docker pull hello-world:latest | tee -a requirements_test.log |
Runs a test container and removes it after exit. | docker run --rm hello-world:latest | tee -a requirements_test.log |
Downloads a test file from the repository. | wget -O /tmp/ctop-test https://repository.kyp.ai/repository/linux/ctop-0.7.7-linux-amd64 | tee -a requirements_test.log |
Checks whether port 22 (SSH) is listening. | ss -tuln | grep ':22 ' | tee -a requirements_test.log |
Shows processes using port 22. | lsof -i :22 | tee -a requirements_test.log |
Checks whether port 80 (HTTP) is listening. | ss -tuln | grep ':80 ' | tee -a requirements_test.log |
Shows processes using port 80. | lsof -i :80 | tee -a requirements_test.log |
Checks whether port 443 (HTTPS) is listening. | ss -tuln | grep ':443 ' | tee -a requirements_test.log |
Shows processes using port 443. | lsof -i :443 | tee -a requirements_test.log |
Lists system and regular user accounts. | awk -F: '$3>=1000 || $1~/^(root|nobody)$/{print}' /etc/passwd | tee -a requirements_test.log |
Checks the privileged user group. | getent group sudo || getent group wheel || getent group admin | tee -a requirements_test.log |
Dumps current iptables rules. | sudo iptables-save | tee -a requirements_test.log |
Dumps nftables ruleset. | sudo nft list ruleset | tee -a requirements_test.log |
Shows the X.509 certificate subject. | openssl x509 -noout -subject -in /path/to/cert.crt | tee -a requirements_test.log |
Hashes the RSA key modulus. | openssl rsa -noout -modulus -in /path/to/key.key | openssl sha256 | tee -a requirements_test.log |
Shows the certificate expiry date. | openssl x509 -enddate -noout -in /path/to/cert.crt | tee -a requirements_test.log |
Displays certificate details in text form. | openssl crl2pkcs7 -nocrl -certfile /path/to/cert.crt | openssl pkcs7 -print_certs -text -noout | tee -a requirements_test.log |