Infrastructure Requirements

This guide covers all prerequisites and planning considerations before deploying Kindo in a self-managed environment (on-premises or any Kubernetes platform).

Table of Contents

1. Overview

2. Infrastructure Requirements

3. Kubernetes Cluster Requirements

4. Database Requirements

5. Storage Requirements

6. External Service Requirements

7. Network and DNS Requirements

8. Security Requirements

9. Required Tools and Software

10. Pre-Deployment Checklist

Overview

Kindo can be deployed on any Kubernetes cluster (on-premises, AWS, GCP, Azure, or other cloud providers) using pure Helm charts. This guide outlines what you need to prepare before installation.

Infrastructure Requirements

Minimum Infrastructure Components

You must provide these infrastructure services before deploying Kindo:

Deployment Sizing

Choose based on your expected usage:

Kubernetes Cluster Requirements

Cluster Specifications

Minimum Requirements:

• Kubernetes Version: 1.32 or greater (required)

• Node Count: 3 minimum (for HA)

• Node Resources:

• CPU: 8 vCPU per node minimum

• Memory: 16GB RAM per node minimum

• Disk: 100GB per node (SSD recommended)

• Network Plugin: Calico, Cilium, or Flannel

• Storage Class: Dynamic provisioning enabled (for persistent volumes)

Recommended Configuration:

• Use node pools/groups for workload isolation

• Enable auto-scaling if available

• Use SSD/NVMe storage for nodes

• Configure node affinity

GPU Node Requirements (for Self-Hosted AI Models):

If planning to run self-hosted LLMs or embedding models, you’ll need dedicated GPU nodes:

• GPU Driver: NVIDIA drivers installed on nodes

• Container Runtime: nvidia-container-runtime configured

• Kubernetes Device Plugin: NVIDIA device plugin or GPU Operator installed

• Node Labels: Label GPU nodes for workload targeting

  kubectl label nodes <gpu-node-name> nvidia.com/gpu=true
  kubectl label nodes <gpu-node-name> accelerator=nvidia-h100  # Example
  

Required Kubernetes Features

• Storage:

  • Dynamic volume provisioning

  • Default storage class configured

  • Support for ReadWriteOnce (RWO) volumes

• Networking:

  • LoadBalancer service type support (or NodePort)

  • Network policies support (recommended)

  • Ingress controller installed

• RBAC: Enabled (required for security)

Pre-installed Kubernetes Components

These must be installed before deploying Kindo:

Optional but recommended:

Database Requirements

PostgreSQL (Required)

Version: PostgreSQL 17.0 or higher (17.4 recommended)

Specifications (minimum for production):

• CPU: 4 vCPU

• Memory: 8GB RAM

• Storage: 100GB SSD (with auto-scaling/expansion)

• Connections: 200 concurrent connections minimum

Required Databases: You need to create these databases:

CREATE DATABASE kindo;      -- Main application database
CREATE DATABASE unleash;    -- Feature flags
CREATE DATABASE litellm;    -- AI model proxy
CREATE DATABASE ssoready;   -- SSO authentication

Required Users: Create dedicated users for each service:

-- Main application userCREATE USER kindo WITH PASSWORD 'secure-password-1';
GRANT ALL PRIVILEGES ON DATABASE kindo TO kindo;
-- Unleash userCREATE USER unleash WITH PASSWORD 'secure-password-2';
GRANT ALL PRIVILEGES ON DATABASE unleash TO unleash;
-- LiteLLM userCREATE USER litellm WITH PASSWORD 'secure-password-3';
GRANT ALL PRIVILEGES ON DATABASE litellm TO litellm;
-- SSOready userCREATE USER ssoready WITH PASSWORD 'secure-password-4';
GRANT ALL PRIVILEGES ON DATABASE ssoready TO ssoready;

Connection URLs: You’ll need connection strings in this format:

postgresql://username:password@hostname:5432/database_name

High Availability (Recommended for Production):

• Use PostgreSQL streaming replication or logical replication

• Or use managed PostgreSQL service (AWS RDS, Google Cloud SQL, Azure Database)

• Configure automatic failover

• Set up regular backups (daily minimum)

Redis (Required)

Version: Redis 7.0 or higher

Specifications (minimum):

• Memory: 2GB minimum

• Persistence: RDB or AOF enabled

• Connections: 100 concurrent connections

Configuration Requirements:

# Recommended redis.conf settings
maxmemory-policy allkeys-lru
timeout 300
tcp-keepalive 60

Connection URL Format:

redis://hostname:6379
# Or with password:
redis://:password@hostname:6379
# Or with TLS:
rediss://:password@hostname:6380

High Availability (Recommended for Production):

• Redis Sentinel (3+ sentinel nodes)

• Or Redis Cluster mode

• Or managed Redis service (AWS ElastiCache, Google Memorystore, Azure Cache)

RabbitMQ (Required)

Version: RabbitMQ 3.13 or higher

Specifications (minimum):

• CPU: 2 vCPU

• Memory: 2GB RAM

• Disk: 20GB for queues

Required Configuration:

• Management plugin enabled

• Federation plugin (if using HA setup)

• Virtual host: / (default) or custom

Connection URL Format:

amqp://username:password@hostname:5672
# Or with TLS:
amqps://username:password@hostname:5671

High Availability (Recommended for Production):

• RabbitMQ cluster (3+ nodes)

• Quorum queues for durability

• Or managed RabbitMQ service (AWS MQ, CloudAMQP)

Storage Requirements

S3-Compatible Object Storage (Required)

Options:

• AWS S3

• MinIO (self-hosted)

• Google Cloud Storage (with S3 compatibility)

• Azure Blob Storage (with S3 compatibility)

• Ceph with S3 gateway

• Any S3-compatible storage

Specifications:

• Capacity: 100GB minimum (grows with user uploads)

• Durability: 99.99% or higher

• Availability: 99.9% or higher

Required Buckets: Create these buckets:

Access Requirements:

• Access Key ID and Secret Access Key

• Permissions: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket

Example MinIO Configuration:

# Create MinIO bucketsmc mb minio/kindo-uploads
mc mb minio/kindo-audit-logs
mc mb minio/kindo-backups
# Create access credentialsmc admin user add minio kindo-user secure-password
mc admin policy attach minio readwrite --user kindo-user

External Service Requirements

Vector Database (Required - Choose One)

Vector database is required for semantic search and RAG (Retrieval Augmented Generation) features.

Option 1: Pinecone (Managed Service)

Why: Managed, scalable, minimal operational overhead

Setup Requirements:

• Create account at https://pinecone.io

• Create a pod-based (non-serverless) index:

• Metric: cosine

• Dimensions: 1536 (for OpenAI embeddings)

• Pod Type: p1.x1 or higher

⚠️ Important: Serverless Pinecone is NOT supported. You must use pod-based indexes.

Credentials Needed:

• PINECONE_API_KEY: API key from Pinecone dashboard

• PINECONE_ENVIRONMENT: Your Pinecone environment/region

• PINECONE_INDEX_NAME: Name of your index

Option 2: Qdrant (Self-Hosted)

Why: Open-source, self-hosted, full data control

Setup Requirements:

• Deploy Qdrant in your infrastructure (can be in same Kubernetes cluster)

• Create collection with configuration:

• Distance metric: Cosine

• Vector size: 1536 (for OpenAI embeddings)

• On-disk payload: Recommended for large datasets

Deployment Options:

Option A: Qdrant in Kubernetes (Recommended)

# Add Qdrant Helm repositoryhelm repo add qdrant <https://qdrant.github.io/qdrant-helm>
helm repo update
# Install Qdranthelm install qdrant qdrant/qdrant \\  --namespace qdrant \\  --create-namespace \\  --set replicaCount=3 \\  --set persistence.size=100Gi

Option B: Qdrant on separate servers

# Install via Dockerdocker run -p 6333:6333 -p 6334:6334 \\  -v $(pwd)/qdrant_storage:/qdrant/storage:z \\  qdrant/qdrant

Credentials/Configuration Needed:

• QDRANT_URL: http://qdrant.qdrant.svc.cluster.local:6333 (if in-cluster) or external URL

• QDRANT_API_KEY: API key if authentication is enabled (optional)

• QDRANT_COLLECTION_NAME: Name of your collection (e.g., kindo-embeddings)

Resources Required (for Qdrant in Kubernetes):

• CPU: 2-4 vCPU per replica

• Memory: 4-8GB RAM per replica (depends on dataset size)

• Storage: 100GB+ SSD (grows with vector data)

High Availability:

• Deploy 3+ replicas for HA

• Use persistent volumes for data durability

• Configure health checks and readiness probes

AI/LLM Services (At Least One Required)

You need at least ONE AI provider configured - either external API providers or self-hosted models.

Option 1: External API Providers

Multiple providers recommended for redundancy and cost optimization.

Option 2: Self-Hosted LLMs (Requires GPUs)

If you want to run models internally for data privacy, cost control, or customization:

GPU Requirements for Self-Hosted Models:

If you want to run LLMs or embedding models internally (instead of using external APIs), you’ll need GPU-enabled infrastructure:

Kubernetes GPU Setup:

• Install NVIDIA GPU Operator for GPU support in Kubernetes

• Configure GPU node pools/taints

• Use GPU-enabled nodes with CUDA drivers installed

• Resource requests: nvidia.com/gpu: 1 in pod specs

Self-Hosted Model Examples:

• Embeddings:

• Managed: OpenAI text-embedding-3-large, Amazon Titan Embeddings v2 (Bedrock)

• Self-hosted: BGE-large-en-v1.5, BGE-M3

• Small LLMs (7B-20B params): GPT-OSS-20B

• Large LLMs (70B-120B+ params): GPT-OSS-120B

Note: Running self-hosted models requires significant GPU infrastructure. Most deployments use external API providers (OpenAI, Anthropic) for cost-effectiveness.

Audit Logging (Required)

Syslog Server

Requirements:

• Syslog server supporting RFC3164 protocol

• Network accessible from Kubernetes cluster

• TCP port 514 or UDP port 514

• Log retention: 1+ years (compliance requirement)

Deployment Options:

1. Existing Syslog Server: Use your current logging infrastructure

2. Deploy New: Consider rsyslog, syslog-ng, or Fluentd

3. Cloud Service: Use cloud provider’s logging service

Configuration Needed:

• SYSLOG_HOST: Hostname or IP address

• SYSLOG_PORT: Usually 514

• SYSLOG_PROTOCOL: TCP or UDP

Email Service (Required)

Choose one email provider:

Network and DNS Requirements

DNS Requirements

Required:

• Control over a domain or subdomain

• Ability to create DNS A/CNAME records

• SSL certificate for your domain

Subdomain Strategy:

SSL/TLS Certificates

Options:

1. cert-manager with Let’s Encrypt (Recommended for most)

   # Install cert-managerkubectl apply -f <https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml>
   # Configure Let's Encrypt issuerkubectl apply -f letsencrypt-issuer.yaml
   

2. Bring Your Own Certificates

   • Obtain wildcard certificate for .kindo.company.com

   • Create Kubernetes secret with certificate and key

3. Cloud Provider Certificate Manager

   • AWS ACM

   • Google Cloud Certificate Manager

   • Azure Key Vault Certificates

Network Accessibility

• Ingress: Expose Kubernetes services via LoadBalancer or NodePort

• Egress: Allow outbound HTTPS (443) for:

  • AI service APIs (OpenAI, Anthropic, etc.)

  • Container registry (registry.kindo.ai)

  • External integrations (Merge, Pinecone, etc.)

Firewall Rules

Inbound (to Kubernetes cluster):

• Port 443 (HTTPS) - from internet to ingress

• Port 80 (HTTP) - from internet to ingress (redirect to 443)

• Port 514 (Syslog) - from cluster to syslog server (outbound)

Outbound (from Kubernetes cluster):

• Port 443 (HTTPS) - to external services

• Port 5432 (PostgreSQL) - to database server

• Port 6379 (Redis) - to Redis server

• Port 5672/5671 (RabbitMQ) - to RabbitMQ server

Security Requirements

Encryption

Data at Rest:

• PostgreSQL: Enable encryption (disk-level or database-level)

• Redis: Configure encryption if available

• S3 storage: Enable server-side encryption

• Kubernetes secrets: Consider using encryption at rest

Data in Transit:

• Force HTTPS for all web traffic

• Use TLS for database connections (recommended)

• Enable TLS for Redis connections (recommended)

• Use AMQPS for RabbitMQ (recommended)

Secret Management

Recommended Approach: Use External Secrets Operator to sync from a secret backend:

• AWS Secrets Manager

• HashiCorp Vault

• Google Secret Manager

• Azure Key Vault

Alternative: Manually create Kubernetes secrets (less secure, harder to rotate)

Access Control

• Kubernetes RBAC: Configure role-based access

• Network Policies: Restrict pod-to-pod communication

• Pod Security Standards: Enforce restricted policies

• Image Security: Only use signed/scanned images from registry.kindo.ai

Required Tools and Software

Local Development Tools

Install these on your deployment machine:

Helm

Required Version: >= 3.8.0 (for OCI registry support)

# macOSbrew install helm
# Linux
curl <https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3> | bash
# Verify
helm version  # Should show >= 3.8.0

kubectl

Required Version: >= 1.32 (match your cluster version ±1)

# macOS
brew install kubectl
# Linux
curl -LO "<https://dl.k8s.io/release/$>(curl -L -s <https://dl.k8s.io/release/stable.txt>)/bin/linux/amd64/kubectl"sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
# Verify
kubectl version --client

Additional Tools

# jq (JSON processing)
brew install jq          # macOS
apt-get install jq       # Debian/Ubuntu
yum install jq           # RHEL/CentOS# 
# yq (YAML processing)
brew install yq          # macOS
wget <https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64> -O /usr/bin/yq && chmod +x /usr/bin/yq # Linux

Verification Script

#!/bin/bash
echo "Checking required tools..."
# Check Helm
if command -v helm &> /dev/null; then
    helm_version=$(helm version --short)
    echo "✓ Helm: $helm_version"
else
    echo "✗ Helm: Not installed"
fi
# Check kubectl
if command -v kubectl &> /dev/null; then
    kubectl_version=$(kubectl version --client --short)
    echo "✓ kubectl: $kubectl_version"
    # Check Kubernetes version
    server_version=$(kubectl version -o json 2>/dev/null | jq -r '.serverVersion.gitVersion' | sed 's/v//')
    if [[ ! -z "$server_version" ]]; then
        echo "  Server version: v$server_version"
        # Check if >= 1.32
        if [[ "$server_version" < "1.32" ]]; then
            echo "  ⚠ Warning: Kubernetes version should be >= 1.32"
        fi
    fi
else
    echo "✗ kubectl: Not installed"
fi
# Check cluster access
if kubectl cluster-info &> /dev/null; then
    echo "✓ Kubernetes cluster: Accessible"
    kubectl get nodes
    # Check for GPU nodes
    gpu_nodes=$(kubectl get nodes -o json | jq -r '.items[] | select(.status.capacity."nvidia.com/gpu" != null) | .metadata.name' | wc -l)
    if [ "$gpu_nodes" -gt 0 ]; then
        echo "  ✓ GPU nodes found: $gpu_nodes"
    else
        echo "  ℹ No GPU nodes (required only for self-hosted LLMs)"
    fi
else
    echo "✗ Kubernetes cluster: Not accessible"
fi
# Check jq
if command -v jq &> /dev/null; then
    echo "✓ jq: $(jq --version)"
else
    echo "✗ jq: Not installed"
fi
# Check yq
if command -v yq &> /dev/null; then
    echo "✓ yq: $(yq --version)"
else
    echo "✗ yq: Not installed"
fi
# Check for ingress controller
if kubectl get ingressclass &> /dev/null 2>&1; then
    echo "✓ Ingress controller: Installed"
    kubectl get ingressclass
else
    echo "⚠ Ingress controller: Not found"
fi
# Check for cert-manager
if kubectl get pods -n cert-manager &> /dev/null 2>&1; then
    echo "✓ cert-manager: Installed"
else
    echo "ℹ cert-manager: Not installed (optional)"
fi

Pre-Deployment Checklist

Infrastructure

• [ ]  Kubernetes cluster provisioned and accessible

  • [ ]  Cluster version >= 1.32 (required)

  • [ ]  Minimum 3 nodes with adequate resources

  • [ ]  Storage class configured

  • [ ]  Ingress controller installed

  • [ ]  cert-manager installed

  • [ ]  GPU nodes with NVIDIA drivers (if running self-hosted LLMs/embeddings)

  • [ ]  NVIDIA GPU Operator installed (if using GPUs)

• [ ]  PostgreSQL provisioned

  • [ ]  Version >= 17.0 (17.4 recommended)

  • [ ]  All required databases created (kindo, unleash, litellm, ssoready)

  • [ ]  All required users created with passwords

  • [ ]  Connection strings documented

  • [ ]  Backups configured

• [ ]  Redis provisioned

  • [ ]  Version >= 7.0

  • [ ]  Accessible from Kubernetes cluster

  • [ ]  Connection string documented

• [ ]  RabbitMQ provisioned

  • [ ]  Version >= 3.13

  • [ ]  Management plugin enabled

  • [ ]  Connection string documented

• [ ]  S3-Compatible Storage configured

  • [ ]  Buckets created (kindo-uploads, kindo-audit-logs, kindo-backups)

  • [ ]  Access credentials generated

  • [ ]  Endpoint URL documented

External Services

• [ ]  Authentication:

  • [ ]  SSOready: Database created (ssoready), admin credentials planned

• [ ]  Vector Database (choose one):

  • [ ]  Pinecone: Account created, pod-based index created, API key obtained

  • [ ]  Qdrant: Deployed and configured, collection created, endpoint documented

• [ ]  AI Services (at least one):

  • External API providers (at least one):

    • [ ]  OpenAI: API key obtained

    • [ ]  Anthropic: API key obtained

    • [ ]  Azure OpenAI: Endpoint and key configured

    • [ ]  Other providers: API keys obtained

  • OR Self-hosted models:

    • [ ]  GPU infrastructure: Provisioned with NVIDIA GPUs

    • [ ]  GPU Operator: Installed in Kubernetes

    • [ ]  Model serving: Inference endpoint planned

    • [ ]  Model files: Downloaded and ready to deploy

• [ ]  Email Service (choose one):

  • [ ]  SMTP credentials obtained

  • [ ]  Amazon SES configured

  • [ ]  SendGrid API key obtained

  • [ ]  Mailgun API key obtained

• [ ]  Audit Logging:

  • [ ]  Syslog server endpoint documented

  • [ ]  Syslog server accessible from cluster

DNS and Certificates

• [ ]  Domain/subdomain available

• [ ]  DNS provider accessible (can create records)

• [ ]  SSL certificate strategy decided:

  • [ ]  cert-manager with Let’s Encrypt

  • [ ]  Manual certificates

  • [ ]  Cloud provider certificate manager

Tools and Access

• [ ]  Helm >= 3.8.0 installed

• [ ]  kubectl >= 1.24 installed

• [ ]  kubectl configured with cluster access

• [ ]  jq and yq installed

• [ ]  Kindo registry credentials received:

  • [ ]  Registry username

  • [ ]  Registry password

Security and Credentials

• [ ]  All database passwords generated and stored securely

• [ ]  All API keys obtained and stored securely

• [ ]  Service account credentials prepared

• [ ]  Encryption keys generated (if needed)

• [ ]  Access control policies defined

Documentation

• [ ]  Infrastructure connection details documented

• [ ]  Database connection strings documented

• [ ]  All API keys securely stored (password manager, vault)

• [ ]  Network architecture diagram created

• [ ]  Subdomain mapping documented

Credential Collection Worksheet

Use this template to collect all required credentials:

# ============================================================================
# KINDO SELF-MANAGED CREDENTIALS WORKSHEET
# ============================================================================
# Store this file securely (use a password manager or secrets vault)
# DO NOT commit to version control
# ============================================================================
# INFRASTRUCTURE SERVICES
infrastructure:
  kubernetes:
    cluster_name: ""
    cluster_endpoint: ""
    cluster_ca_cert: ""  # Base64 encoded
  postgresql:
    main_connection_string: "postgresql://kindo:PASSWORD@HOST:5432/kindo"
    unleash_connection_string: "postgresql://unleash:PASSWORD@HOST:5432/unleash"
    litellm_connection_string: "postgresql://litellm:PASSWORD@HOST:5432/litellm"
    ssoready_connection_string: "postgresql://ssoready:PASSWORD@HOST:5432/ssoready"
  redis:
    connection_string: "redis://:PASSWORD@HOST:6379"
  rabbitmq:
    connection_string: "amqp://USER:PASSWORD@HOST:5672"
  storage:
    s3_endpoint: "<https://s3.amazonaws.com>"  # or MinIO endpoint
    s3_access_key_id: ""
    s3_secret_access_key: ""
    s3_region: "us-west-2"
    s3_uploads_bucket: "kindo-uploads"
    s3_audit_bucket: "kindo-audit-logs"
    s3_backups_bucket: "kindo-backups"
# EXTERNAL SERVICES
external_services:
  authentication:
    ssoready:
      # SSOready is self-hosted, no external API keys needed
      # Admin credentials configured during deployment
      admin_email: "[email protected]"
      admin_password: ""  # Set during deployment
  vector_database:
    # Choose ONE
    pinecone:
      enabled: true  # Set to true if using Pinecone
      api_key: ""
      environment: "us-east-1-aws"
      index_name: "kindo-embeddings"
    # OR
    qdrant:
      enabled: false  # Set to true if using Qdrant
      url: "<http://qdrant.qdrant.svc.cluster.local:6333>"
      api_key: ""  # Optional, if authentication enabled
      collection_name: "kindo-embeddings"
  ai_providers:
    # At least ONE required (or use self-hosted)
    openai:
      api_key: ""
    anthropic:
      api_key: ""
    azure_openai:
      api_key: ""
      endpoint: ""
      deployment: ""
    # Self-hosted LLMs (if using GPU infrastructure)
    self_hosted:
      enabled: false  # Set to true if using self-hosted models
      inference_endpoint: "<http://inference.kindo-apps.svc.cluster.local:8000>"
      # GPU nodes required - see GPU Requirements section
  email:
    # Choose ONE
    smtp:
      host: ""
      port: "587"
      username: ""
      password: ""
      from_address: "[email protected]"
    # OR
    ses:
      region: "us-west-2"
      access_key_id: ""
      secret_access_key: ""
      from_address: "[email protected]"
  logging:
    syslog:
      host: ""
      port: "514"
      protocol: "udp"  # or "tcp"
# KINDO REGISTRY
registry:
  url: "registry.kindo.ai"
  username: ""  # Provided by Kindo
  password: ""  # Provided by Kindo
# DNS AND DOMAINS
dns:
  base_domain: "kindo.company.com"
  subdomains:
    app: "app.kindo.company.com"
    api: "api.kindo.company.com"
    sso: "sso.kindo.company.com"
    litellm: "litellm.kindo.company.com"  # Optional, can be internal-only
    unleash: "unleash.kindo.company.com"
# AUTO-GENERATED SECRETS (will be generated during deployment)
generated_secrets:
  nextauth_secret: ""  # Generated: openssl rand -base64 32
  key_encryption_key: ""  # Generated: openssl rand -base64 32
  um_internal_api_key: ""  # Generated: uuidgen or openssl rand -hex 32
  litellm_master_key: ""  # Generated: openssl rand -hex 32
  unleash_admin_token: ""  # Generated: openssl rand -hex 32
  unleash_client_token: ""  # Generated: openssl rand -hex 32

Resource Planning

Kubernetes Node Requirements by Size

Storage Planning

Next Steps

Once all prerequisites are met, proceed to:

1. [Deployment Runbook] - Step-by-step deployment instructions

2. Gather all credentials using the worksheet above

3. Prepare your Kubernetes cluster

4. Set up infrastructure services (PostgreSQL, Redis, RabbitMQ, S3)