Getting started

This guide walks you through installing AtlasArc and running your first analysis. If you just installed it and want to know what you're looking at, you're in the right place.

Before you start

AtlasArc works on Java, Kotlin, and TypeScript projects in IntelliJ IDEA 2025.1 or later. It supports Community and Ultimate in 2025.1 and 2025.2, and unified IntelliJ IDEA from 2025.3 onward.

For Java and Kotlin, AtlasArc reads compiled class files directly. If you haven't built your project recently, do a build first. AtlasArc analyses the bytecode, so an up-to-date build gives you a more accurate graph. Stale class files aren't a blocker, but you may see packages that no longer exist or miss ones that were just added.

For TypeScript, AtlasArc reads dependency-cruiser artifacts generated by your project toolchain. The setup guidance in the IDE shows the expected files and commands when a TypeScript source needs artifacts.

Install

In IntelliJ IDEA, open Settings (or Preferences on macOS), then go to Plugins.
Switch to the Marketplace tab and search for AtlasArc.
Click Install, then Restart IDE when prompted.

Screenshot: IntelliJ IDEA Plugins Marketplace showing the AtlasArc search result and Install action

Install from inside the IDE. Search for AtlasArc in the Marketplace tab and use the Install action on its result.

Alternatively, find AtlasArc on the JetBrains Marketplace in your browser and use the Install to IDE button. It hands off to IntelliJ automatically.

Both paths install the permanent Free edition. JetBrains Marketplace also offers an optional 30-day trial of the full workspace, so the same install can evaluate deeper lenses, metric analysis, and full reports. See exactly what stays free.

Open the plugin

With your project open, go to Tools > AtlasArc. You can also click the AtlasArc icon in the right tool window stripe if it's there.

Already know which Java or Kotlin package you want to inspect? In IntelliJ's Project view, right-click the package and choose Analyze > Analyze with AtlasArc. AtlasArc opens on that package as Current Focus and immediately runs the selected Analysis Source. This is a focused entry into the resulting model; it does not turn the package into a different Analysis Source or change repository Analysis Scope.

Screenshot: IntelliJ Project view package context menu with Analyze > Analyze with AtlasArc highlighted

Start from a package you recognize. The package becomes Current Focus while AtlasArc runs the selected Analysis Source.

On the first run, choose an analysis source and run Analyze. JVM sources scan production class files by default; select Include tests beside the JVM source when you also want compiled test classes and test source roots in that analysis. TypeScript sources read generated artifacts, whose contents define whether tests are included. For a medium-sized project this takes a few seconds. Give it a moment on very large codebases.

Screenshot: AtlasArc first-run analysis source selector with Analyze and Include tests visible

Choose what AtlasArc reads. Select a source, decide whether the JVM analysis should include tests, then start the analysis.

Your first graph

The view that opens is the Topology Graph. Each box is a package. The arrows show usage dependencies, pointing from the package using code to the package being used.

If you've worked in this codebase for a while, there's a decent chance the graph looks somewhat different from the mental model you had. That's not a bug. The graph reflects the actual usage structure, not the intended architecture. The gap between those two things is usually where the interesting work starts.

Screenshot: Topology Graph after the first successful analysis, with packages and dependency arrows visible

Start with the structure that exists. Packages are nodes; arrows point from the package using code to the package being used.

A few things to try straight away:

Expand a package inline by clicking the expand icon on the node. Child packages appear in place without changing the rest of the graph.
Filter by package or source-folder prefix to reduce a large model while keeping the underlying analysis unchanged.
Right-click any package to navigate directly to it in the Project tree in the IDE.

Read the cycles already visible in Topology

Dependency cycles are highlighted in the Topology Graph by default, including in Free. Select a highlighted package to inspect its ordinary structural and dependency evidence. During a trial of the full workspace, the dedicated Cycles section adds Cycles Only, cycle-group navigation, and persistent Cycle View when you want to isolate one loop at a time.

Screenshot: Topology Graph with the Cycles section open, cycles-only enabled, and one cycle group selected

Isolate one loop. Cycles Only removes clean structure from the view; selecting a group keeps its members and evidence together.

In that dedicated investigation, click any highlighted package to select the full cycle group. The sidebar shows all the members, the depth of the cycle path, and the dependency edges that form it. The cycle-group navigator lets you step through groups one at a time if you have more than one.

If nothing lights up, your package structure is clean on that front. That's genuinely worth noting before you start any refactoring.

Where to go next

The Topology Graph page explains the default view and what to look for first. From there, use the Lenses section in the left-hand menu to open Package Matrix, Composition, Subsystems, or Hotspots.

The Find cyclic dependencies workflow is the task-based companion to these docs if you want a concrete first investigation. Other workflow pages cover reviewing package boundaries, finding coupling pressure, and identifying hotspots.

The Fan-in and fan-out page explains the first coupling numbers most teams inspect. The Metrics section in the left-hand menu covers instability, abstractness, cycles, coverage, size, and the rest.