> For the complete documentation index, see [llms.txt](https://docs.konvu.com/konvu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konvu.com/konvu/get-started/connect-your-environment/source-code/self-hosted-analysis/prerequisites.md). # Prerequisites ## Universal Requirements For deploying Konvu on **any Kubernetes cluster**: ### Kubernetes Cluster * **Kubernetes v1.28+** (any distribution: AWS EKS, Google GKE, Azure AKS, OpenShift, on-premises, etc.) * **kubectl access** to the cluster with permissions to create namespaces, deployments, secrets * **Cluster requirements**: * Ability to pull images from private registry (`registry.konvu.com`) * Sufficient capacity for controller and analysis jobs (see Resource Planning below) * Outbound internet access to Konvu, GitHub, and your LLM provider (see [Network](#network) below) Verify cluster access: ```bash kubectl cluster-info kubectl get nodes ``` ### Network Konvu runs on **outbound connections only**. There is nothing to open on the way in. **Inbound: none.** No open ports, no inbound firewall rules, no VPN, and no Konvu-initiated access into your account or cluster. The controller and broker each poll the Konvu backend over outbound HTTPS and pull their work from it. **Outbound: HTTPS only, proxy-supported.** The cluster needs egress to these domains: | Domain | What it's used for | | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `sensors.konvu.com` | Konvu backend — job commands and analysis results. Metadata only (dependency names, vulnerabilities, triage assessments). Source code never leaves your cluster. | | `registry.konvu.com` | Konvu container images | | `github.com` and `api.github.com`, or your GitLab host | Repository and Dependabot access | | Your LLM provider, e.g. `api.openai.com` | AI triage with your key. Azure OpenAI, `api.anthropic.com`, or a private LLM endpoint are also supported. | | `docker.io`, `registry-1.docker.io`, `production.cloudflare.docker.com` | Git init image used by analysis jobs | | Your ecosystems' package registries, e.g. `repo.maven.apache.org`, `plugins.gradle.org`, `services.gradle.org`, `registry.npmjs.org`, `pypi.org` | Dependency resolution during analysis | | `download.konvu.com` | Konvu Helm repo — needed from the admin workstation only, not the cluster | All outbound traffic is HTTPS on port 443 and can be routed through an HTTP(S) forward proxy. Write firewall rules against hostnames, not IP addresses — the IPs rotate. If your cluster reaches the internet through a proxy, set the standard `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables on the controller and broker pods. ### Required Tools * **kubectl** (v1.28+) - Kubernetes cluster management * **Helm** (v3.12+) - Application deployment * **jq** (optional) - JSON parsing for verification ### Required Credentials You'll need these credentials to configure the broker and controller: 1. **Konvu company token** - Your organization's Konvu API token (contact Konvu support) 2. **GitHub App credentials** - For the broker to access your repositories: * **App ID**: Your GitHub App's numeric identifier * **Installation ID**: The installation ID for your organization * **Private Key**: The GitHub App's private key (PEM format) * See [Connecting GitHub](/konvu/get-started/connect-your-environment/source-code/self-hosted-analysis/connecting-github.md) for detailed setup instructions 3. **OpenAI or Anthropic API key** - Used for AI-powered triage assessments (Azure OpenAI is also supported via a custom base URL) ### Resource Planning Plan cluster capacity based on concurrent analysis jobs: **Controller pod** (one per deployment): * CPU: 25m request, 500m limit * Memory: 256Mi request, 512Mi limit **Broker pod** (one per deployment): * CPU: 25m request, 500m limit * Memory: 256Mi request, 512Mi limit **Analysis job pods** (per concurrent job): * CPU: plan \~1 CPU per job (Java/Gradle analyses reserve a full CPU) * Memory: 2Gi request and limit (a job OOMKilled at 2Gi is retried once at 4Gi, so leave headroom) **Example**: For 10 concurrent jobs: * Total CPU: \~10 cores (controller + 10 jobs) * Total Memory: \~21Gi (controller + 10 jobs) **Example**: For 50 concurrent jobs: * Total CPU: \~50 cores (controller + 50 jobs) * Total Memory: \~101Gi (controller + 50 jobs) *** ## AWS-Specific Prerequisites (Optional) **Only required if you want to provision infrastructure using our Terraform module.** Skip this section if you already have a Kubernetes cluster. ### AWS Account Requirements * Permissions to create VPC, EKS clusters, IAM roles, Secrets Manager * **AWS CLI** (v2.0+) configured with credentials * **Terraform** (v1.9+) or **OpenTofu** (v1.9+) Verify AWS credentials: ```bash aws sts get-caller-identity ``` ### Optional AWS Enhancements If deploying on AWS EKS, you can optionally use: * **AWS Secrets Manager** - For centralized secret storage (requires External Secrets Operator) * **IRSA** (IAM Roles for Service Accounts) - For AWS service access without long-lived credentials * **Karpenter** - For intelligent autoscaling of analysis job nodes --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.konvu.com/konvu/get-started/connect-your-environment/source-code/self-hosted-analysis/prerequisites.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.