Requirements
Qodana license
Reach out to our support team to request a license that can be used by Qodana Self-Hosted.
System and network requirements
Dockerized version
Below are the requirements grouped in categories.
Attribute | Value |
|---|---|
CPU Architecture | AMD64_86, ARM64 |
Number of cores | >= 4 |
RAM | >= 16GB |
HDD | >= 100GB |
Operating system | Any Linux distribution that supports a compatible CPU Architecture |
Docker version | 20.10.23 or later |
qodana-installer-cli references container images from the quay.io Docker registry. Make sure that quay.io is a trusted address in the network. For offline installations, mirror to an internal trusted Docker registry the tags available in the https://quay.io/repository/jetbrains/qodana-installer-cli-dependencies Docker registry.
For usage statistics dynamic configuration, download the configuration from the JetBrains website. Also, the following FQDNs must be accessible if you wish to share analytics with the Qodana team:
https://analytics.services.jetbrains.comhttps://resources.jetbrains.com
Qodana Self-Hosted supports MinIO starting from version RELEASE.2025-01-20T14-49-07Z onwards.
Kubernetes version
Below are the requirements grouped in categories.
Environment | CPU (cores) | RAM (GB) | Storage (GB) | Notes |
|---|---|---|---|---|
Demo/PoC (small team) | 6-8 | 8 | 40-60 | Single-node possible, not HA |
Small prod | 8-16 | 16-32 | 100-200 | 3+ nodes, HA with only multi nodes |
Medium-to-large prod | 16+ | 32+ | 200+ | Scale per workload, more for large codebases |
In case of a single-node configuration, limited resources are not sufficient for the Kubernetes Scheduler and Kubelet for deployments that mutate the configuration state of Self-Hosted (SH) pods. In such a case, proceed with two-step deployment: with the first step apply the configuration change and set the replicaCount of SH pods to 0, wait for the deployment to succeed and proceed with the second step where you set the replicaCount from 0 to 1. Another alternative that avoids this is to provision a multi-node Kubernetes cluster such that pods are distributed cross nodes and are not limited by the limitation of a one node cluster.
Attribute | Value(s) |
|---|---|
Operating system | Any Linux distribution that satisfies Kubernetes requirements |
Container runtime | Any container runtime that satisfies Kubernetes requirements |
Ingress controller | Any Ingress Controller that is deployed in the Kubernetes cluster as a cluster service and can resolve service URLs |
Storage controller | Any Storage Controller that allows volumes to migrate cross nodes based on pod locations |
For any ingress controller, you must configure redirect behavior, client identity propagation, and size/buffering limits.
First, decide where TLS terminates and who performs HTTP to HTTPS redirects; if your edge LB/CDN already enforces HTTPS, disable redirects at the ingress to avoid loops and double hops.
Second, ensure your apps see the real client IP, scheme, and host: choose the appropriate mechanism your controller supports (X-Forwarded-* headers, Forwarded header, or PROXY protocol) and restrict trust to known upstream CIDRs so users can’t spoof IPs.
Third, right-size limits for request headers, request bodies, and response buffering to match your workloads (SSO cookies, many Set-Cookie headers, file uploads, streaming).
Each controller exposes different knobs and names for these concepts, but they map to the same concerns: header buffer sizes, large-header buffers, max body size, proxy buffer sizes, forwarded header handling, and optional proxy protocol. Review your controller’s documentation for the exact settings, mirror the intent of the examples shown for NGINX, and validate under load tests to confirm no 400/413 responses, no misreported client IPs, and consistent redirect behavior.
Below is an example configuration for Kubernetes nginx ingress controller.
Name | Value(s) |
|---|---|
| Helm CLI installed latest version |
| Kubernetes CLI (kubectl) installed and configured |
| OpenSSL CLI for generating secret |
Attribute | Value(s) |
|---|---|
DNS top-level domain | Allocate a DNS zone for Qodana Self-Hosted so that it can identify assets on the network starting from the zone name. Example: |
Base URLs | Qodana Self-Hosted is composed of several components. Almost each of these components requires a dedicated base URL. Example: given that the top-level domain is
|
Docker registry | The Helm Chart and Docker images are hosted at |
Other URLs | JetBrains resources:
Third-party resources:
|
Qodana Self-Hosted supports S3 in AWS or Minio starting from version RELEASE.2025-01-20T14-49-07Z onwards.