Getting started
Install AtlasArc, open the tool window, and turn built project evidence into your first architecture graph.
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, build first: AtlasArc reads compiled bytecode. For TypeScript, generate the dependency-cruiser artifact with your own project toolchain. AtlasArc shows the expected path and setup command when that artifact is missing.
Install the approved preview
AtlasArc 1.0.0 is approved by JetBrains. While the listing is still hidden from ordinary Marketplace and IDE search, use its direct version page:
- Open AtlasArc 1.0.0 on JetBrains Marketplace.
- Use the Marketplace install action to hand the plugin to IntelliJ IDEA.
- Restart the IDE if IntelliJ asks you to.
This installs the permanent Free edition. Marketplace search and Full Workspace trial activation are not live yet, so this guide does not depend on either one. See what stays free.
Open the plugin
Click AtlasArc in the right tool window stripe. If the stripe entry is hidden, use View > Tool Windows > AtlasArc.
Choose an Analysis Source, then run Analyze. A JVM source can be the whole project or one module; Include tests adds compiled test evidence for that run. A TypeScript source reads its configured artifact root. Java and Kotlin can share one JVM graph; TypeScript remains a separate artifact-backed graph.
Start from project context
Analyze > Analyze with AtlasArc is the shortcut when you already know where to begin. From a Java or Kotlin package or file, it selects the owning JVM source and focuses the containing package. From a TypeScript file or folder, it selects the containing artifact source and focuses the nearest source folder. Other items inside a JVM module start at that module; items outside a supported source start at the model root.
The focus is applied after the new analysis is loaded. If the exact unit has no current evidence, AtlasArc uses its nearest available parent and tells you. If there is no project context at all, choose Keep Current Focus or Start at Root; closing that choice cancels. None of these choices changes committed repository Analysis Scope.
Your first graph
The view that opens is the Topology Graph. Boxes are JVM packages or TypeScript source folders, with module roots where JVM ownership needs to stay explicit. Arrows point from the unit using code to the unit 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.
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.
A leaf package or source folder chosen as Current Focus stays visible even when Hide isolated is on. When it contains implementation units, Topology shows one closed Classes or Files group. Opening that package-local detail is part of the Full Workspace; the package-level graph remains available in Free.
Know the result you got
- Ready means the selected source has runnable evidence.
- Setup needed or Unavailable points to missing build output, artifacts, or configuration rather than presenting an empty graph as success.
- A graph with no highlighted cycles is a successful result with no cycle finding in that evidence.
- Highlighted units are cycle findings already visible in Topology; no extra cycle filter is required to detect them.
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.
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.