IDE settings and AI rules, per Git repository

Your team’s IDE settings, applied per Git repository.

One dashboard holds the code style, the actions on save, Prettier, the JDK — and the rules your AI agents follow. Every IDE applies them to the repository you have open, and puts them back when they move. No shared .idea folder, nothing to commit.

Start free trial — 30 days

No credit card required · Set up in under 5 minutes

Built for

IntelliJ IDEA WebStorm PyCharm GoLand PhpStorm Rider and more

The problem

What is IDE configuration drift?

Every engineering team starts aligned — same IDE, same standards, same setup. Alignment does not maintain itself.

The drift spiral

A developer tweaks a setting

An SDK version changes locally

Actions on save are disabled

Inspections differ between machines

A new joiner misses part of the setup

None of this looks critical, until it is.

What it costs, week to week

Formatting noise: Code reviews filled with style changes.
CI reformats: Unexpected file changes during builds.
Inconsistent warnings: Issues appear on one machine and not another.
Legacy friction: “Works on my machine” creeping back.

It creates Git noise and subtle inconsistencies — not because developers are careless, but because nothing puts a setting back once it has moved. And it gets worse as the team grows.

The solution

One configuration, applied where the work happens

Most teams rely on documentation, .editorconfig , shared .idea folders and CI checks. Each covers a slice: none of them writes a setting inside the IDE, and none of them puts it back when it moves.

Decided once

One dashboard holds the configuration of a repository, or of a whole group of them.

Applied per repository

The repository of the file you have open decides which settings your IDE carries.

Put back, not policed

A governed setting changed by hand is re-applied at the next pass, and your change is kept as a draft.

Rules for AI agents

A marked block in CLAUDE.md and AGENTS.md, written by the plugin and followed on the dashboard.

See it in action

One setting, from the dashboard to every IDE

Three short loops, the same ones the JetBrains Marketplace listing shows: a setting decided for a group and applied per repository, a developer’s change proposed and reviewed, then the rules the AI agents of the team follow.

An administrator switches Rearrange code on in the dashboard and saves; a developer’s IDE announces the configuration, lists it in the Status tab, and shows it written into Actions on Save. — 21 s · loops

A developer ticks Rearrange code in the IDE settings, the plugin re-applies the team value and keeps a draft, the Publish tab sends it with a comment, an administrator approves it on the dashboard. — 26 s · loops

Rules composed on the dashboard, written by the IDE into a marked block of CLAUDE.md on project open, reported as edited by hand in the Status tab, and followed per repository on the dashboard. — 23 s · loops

Architecture

Git-based configuration

Configuration is tied to your Git repository, not to your IDE project. Your settings follow your code.

Binding settings to the .idea folder

Merge conflicts

Local overrides

Fragile synchronization

Noise in version control

Binding settings to the Git project

One IDE window, several repositories, the right settings

Applied as you switch to a file of another repository

Nothing to commit, nothing to merge

No .idea folder to share

A governed setting put back when it moves

How it works

The road a team setting travels

From the dashboard to every IDE, and back — a developer who disagrees proposes instead of drifting.

1 An administrator decides
Code style, actions on save, Prettier, annotation processing, Maven settings and JDK — for one repository, or for a group.
2 Every IDE applies it
On project open, when you switch to a file of another repository, on Refresh from Server, and when a ten-minute check finds a change.
3 A change made by hand is put back
At the next pass, and what you changed is kept as a draft instead of being discarded.
4 A developer proposes
The Publish tab captures the settings of the IDE: tick what you propose, add a comment for the reviewer.
5 An administrator reviews
Every proposal waits for a review. Approved, it reaches every repository of the target; rejected, it comes back with a reason.
6 The AI rules travel the same road
Composed on the dashboard, written into CLAUDE.md and AGENTS.md on project open — never over a block you edited by hand.

Trust

What leaves the workstation, named

Your source code never leaves your machine. What does leave it is listed here, and in full in the privacy policy.

What never leaves your machine

Your source code is never sent

No file name, no keystroke, no coding time

Your personal IDE preferences stay yours

Tokens live in the password safe of the IDE

What the dashboard sees

Your repositories: The host and the path of each Git remote, so a configuration can be attached to a repository.
Your workstation: The plugin version, the IDE version and product, and how many changes this workstation set up, put back or updated, per month. The Service also adds them up per day for the whole company, naming no repository.
The state of the rules block: Which bundle CLAUDE.md and AGENTS.md carry, and whether the block was edited — never the content of the files.

Who it’s for

Teams that ship at scale

Not for hobby projects. Konfigomatik is built for engineering teams that care about consistency — whether they run Java, Kotlin, JS, PHP, Go, Python or Rust.

Scale beyond 10 developers
Care about consistency
Want instant onboarding
Avoid configuration chaos
Give their AI agents the same rules

Questions

Frequently asked questions

Isn’t this overkill for a small team?

For teams under 5 developers, manual configuration can work. Konfigomatik becomes valuable once configuration drift becomes systemic — typically around 10+ developers.

How is this different from sharing a .idea folder?

Nothing to commit, no merge conflicts, no local override that survives unnoticed — and a governed setting that moves comes back on its own.

What happens if a developer changes a setting manually?

Konfigomatik re-applies the team’s setting at the next pass — on project open, when you switch to a file of another repository, or on Refresh from Server — and keeps what you changed as a draft. The Publish tab turns that draft into a proposal for the team.

What data is sent to the dashboard?

The host and path of each Git remote, the plugin and IDE versions, the state of the shared rules block, and how many changes the workstation set up, put back or updated, per repository and per month. The Service also adds them up per day for the whole company, naming no repository. A published proposal adds the settings it carries and its comment. Never the source code, the file names, the keystrokes or the coding time. Everything travels over HTTPS, and the privacy policy lists it flow by flow.

Is this a “bossware” or tracking tool?

What the dashboard shows is attached to a repository, not to a person: which configuration it applies, whether its rules block is up to date, how many changes were set up, put back or updated this month. We don’t track keystrokes, active hours or lines of code, and no screen ranks developers.

Can developers override project settings?

Konfigomatik applies only the settings your team governs; personal preferences outside that scope are untouched. A governed one you change comes back at the next pass — and what you wanted is kept as a draft, so the way to make it stick is to publish it and have it approved.

What does the plugin write in my repository?

The marked block of shared rules in CLAUDE.md and AGENTS.md, and .idea/prettier.xml when your team governs Prettier. Nothing else: every other setting lives in your IDE. The block is never written over a file with uncommitted changes, nor over a block you edited by hand.

Does it work with offline development?

Your IDE keeps the last successfully applied settings. You can continue working without any interruption; the plugin resumes syncing once back online.

Is this comparable to JetBrains IDE Provisioner?

They answer different questions, and JetBrains documents theirs best. Konfigomatik ties a configuration to a Git repository, applies it as you work and lets a developer propose a change back — for teams of ten as well as for teams of five hundred.

How does it handle multi-repo projects?

The repository of the file you have open decides; failing that, the one holding the project root; failing that, the first in alphabetical order. Switch to a file of another repository and its configuration is applied, one repository at a time.

Stop configuration drift before it slows your team down.

Bring consistency to your IDE configuration.