Privacy Policy

Last updated: October 15, 2026

1. Data Controller

The data controller is: Konfigomatik

Email: contact@konfigomatik.com

2. Data Collected

We collect strictly necessary technical data. What the plugin sends depends on what it is doing, so it is listed below by moment.

Account and licence

  • JetBrains user identifier (email or Marketplace ID)
  • License and subscription status
  • Technical logs (errors, diagnostics)
  • API usage data (requests, quotas)

When a workstation signs in

  • The one-time Device Access Token an administrator generated for that developer. The token returned in exchange stays in the password safe of the IDE.
  • A random installation identifier created on the workstation, the plugin version, the IDE version and the IDE product name.

Automatically, while a project is open

  • The plugin version, the IDE version and the IDE product name.
  • For each Git repository of the project: the host of its remote, for example gitlab.example.com, and its path, for example namespace/repository. The full remote URL and the location of the repository on the workstation are never sent.
  • The name of the branch a repository is on, only when an administrator declared a configuration for that branch. Any other branch name, such as a feature branch, never leaves the workstation.
  • For the shared rules block: the path of the repository and, for the block found in its file, the identity of the rules bundle it carries, the commit of the rules repository each of its layers was read at, its checksum, and whether it is intact or was edited. When the workstation could not read a layer of these rules from Git, the name and reference (branch or tag) of that layer and the reason: access refused, reference not found, document missing, directory missing, import missing, or Git server unreachable. That reason depends on the access of the workstation that reports it. When the workstation read that layer as far as a commit of the rules repository, that commit too, and up to 100 paths of the layer it could not find there: a document or a directory the layer declares, or an import written in its files. An import is sent as it is written in the rules, with the file of the rules repository that carries it and its line in that file; an import that points at an absolute path, for example in a home directory, may therefore contain the name of a user account. Apart from these imports, the content of the files is never sent.
  • How many changes the workstation applied, as a count per repository, per month, per family (settings, JDK, Maven, AI rules) and per nature (set up for the first time, put back after a change on the workstation, updated to a newly approved configuration or to a new text of the rules). The count itself names nobody, but it travels on an authenticated connection and can therefore be attributed to the developer account that sent it. The Service notes the day it receives each count, and adds it to a total per company, per day, per family and per nature, which names no repository.

When a developer publishes a configuration

  • The settings selected for the proposal and their values (code style, on-save actions, annotation processing, Prettier).
  • The repository, branch configuration or group it is proposed to, a hash of the configuration the Service already holds for that target, and the comment written for the administrator who reviews it.

Inventory of a Git server we cannot reach

Where your Git server answers your network but not ours, the Service can ask a signed-in workstation to list its projects. The workstation calls your own GitLab or GitHub server with a token we provide for the duration of that read only, which is never written to disk, and returns the identifier, the name and the path of each project. Nothing else is read from that server, and this happens only for a server an administrator registered with the Service.

Files read on the workstation. To keep the block of shared rules it manages up to date, the plugin reads CLAUDE.md and AGENTS.md at the root of your repositories, and writes that block into them. When it writes CLAUDE.md, it also writes the files of the shared rules into the .konfigomatik/rules/ directory of the repository, reads them back to tell whether they were edited, and removes from that directory what the rules no longer hold. Applying a configuration also writes .idea/prettier.xml in the project. These are the only files of your project the plugin reads or writes, and their content is never sent.

Rules read from your Git server. The Service neither stores the text of the shared rules nor sends it to the workstations. Each time it checks the block of a repository, the plugin asks your Git server, with the Git access of the developer, which commit the reference of each layer points at: a branch, a tag, or the default branch of the rules repository when the layer names none. It fetches that commit when it does not hold it yet, keeps that copy in its own directory on the workstation and reads there the documents the layer declares, the files they import, and the .md files of the directories the layer declares. Nothing it reads is sent, apart from the imports it could not resolve, as listed above.

Never collected: source code, file names other than the paths of the shared rules listed above, keystrokes, coding time, lines of code.

No sensitive personal data is collected.

3. Purpose of Processing

Data is processed to:

  • provide access to the SaaS Service
  • validate licenses
  • apply to each repository the configuration its administrators decided
  • show administrators what each repository applies, the state of its shared rules block, and how many changes the workstations applied
  • let developers propose a configuration and administrators review it
  • list the repositories of a Git server our infrastructure cannot reach
  • ensure security and prevent abuse
  • improve plugin stability and performance

4. Legal Basis

Processing is based on:

  • contract performance (Article 6(1)(b) GDPR)
  • legitimate interest (Article 6(1)(f) GDPR)

5. Data Retention

  • Account-related data: for the subscription duration
  • Repository data (configuration, state of the shared rules block, monthly counts of applied changes): for as long as the repository is registered in the Service
  • Daily totals of applied changes per company: for the subscription duration
  • Proposals and their comments: for the subscription duration
  • Technical logs: up to 90 days
  • Payment data: handled exclusively by JetBrains Marketplace

6. Data Processors

Data may be hosted by:

Hostinger (SaaS infrastructure provider)

JetBrains Marketplace may process subscription/license data as part of its platform services.

7. Your Rights

Under GDPR, you have the right to:

  • access, rectification
  • erasure
  • restriction or objection
  • data portability

To exercise your rights, contact contact@konfigomatik.com

8. Security

Konfigomatik implements reasonable technical and organizational measures to protect your data.

Success