Qodana 2025.3 Help

Configuration overview

You have the following configuration approaches:

  1. Configuring Qodana via a YAML-formatted file, typically named qodana.yaml, is suitable for settings that require lengthy commands, such as inspection configuration, bootstrap, and other settings that are not convenient to configure otherwise. Once a YAML configuration is saved, you can reuse it across different instances of Qodana.

  2. Using configuration capabilities of the tools that are running Qodana like Docker, Qodana CLI, IDEs, and CI/CD tools.

    Settings like linter or quality gate can be set up using both methods. In this case, tool configurations override configurations saved in a YAML-formatted file.

  3. Configuring inspection profiles lets you specify inspections and paths in your codebase that should be used for analysis by Qodana. You can configure and use the existing inspection profiles or create your custom profiles from scratch.

  4. Finally, you can override the default JDK versions shipped with Qodana, see the JDK configuration for details.

Performance optimization

To make Qodana work better during the project configuration stage, you can follow the recommendations below.

First of all, specify the --cache-dir option, the use-caches input argument in case of CI/CD integrations, or the /data/caches directory in the Docker container of a linter after the first linter analysis. Cache contains data related to project structure, indexes, dependencies, which makes subsequent analyses faster. However, in case of significant and disruptive changes of your project or Qodana version updates, it may be beneficial to reset cache.

You can also store your IntelliJ IDEA setting files in the .idea folder, for example:

  • The modules.xml file improves project structure parsing

  • The language-specific files like kotlinc.xml or php.xml provide information about compiler versions and options

  • The *.iml files contain information about directories

Make sure that your project is correctly configured by looking at the <results-dir-artifact>/projectStructure directory after the first analysis. Also, make sure that:

  • The project imports work correctly

  • The tooling that you use matches the configured versions

  • Project dependency pooling works correctly, as it should be done only once if you are using cache

  • Analyses do not show sanity problems because they are a key indicator of configuration issues

22 December 2025