JetBrains/intellij-community: Building IntelliJ IDEA and PyCharm from Source

What intellij-community actually is, and who it is not for

This repository is the open source part of the JetBrains IDEs codebase, and the README states that it also serves as the basis for IntelliJ Platform development. That single sentence defines the audience. If you write plugins, debug platform internals, or assemble a custom IDE distribution, this is the upstream you work against. If you want a Java editor on your laptop, it is not.

The distinction matters because the repository is frequently confused with the product. The README describes the master branch as the source code used to create the next major version of all JetBrains IDEs, and it points to the Build Number Ranges page for the branch names and build numbers of older releases. There is no supported path from this checkout to a daily-use IDE that is easier than downloading the prebuilt Community Edition. The repository is a build system and a source tree, not a distribution channel.

The licensing is the other reason to read carefully before treating this as a free product. GitHub records the license as NOASSERTION, and the repository carries both LICENSE.txt and NOTICE.txt at its root. The README says nothing about what those files permit, so anyone planning to redistribute a build should read them directly rather than assume an Apache or MIT grant.

How the build works: Bazel, .bazelproject and the migration in progress

The most consequential fact about the current state of the repository is that the IntelliJ IDEA project is being migrated to Bazel, and the README says the migration is still in progress, so rough edges and temporary issues are expected, mostly around IDE integration. That warning is not boilerplate. It changes what tooling you need before you can open the project at all.

The README states plainly that building the project using only IDE built-in capabilities is no longer supported. Instead, the Bazel plugin must be installed and enabled. The repository layout reflects this: MODULE.bazel, MODULE.bazel.lock, BUILD.bazel, .bazelrc, common.bazelrc, .bazelversion, .bazeliskrc and .bazeliskversion all sit at the root, alongside the older build.xml and the .iml module files that the pre-Bazel workflow used. The presence of both is the clearest sign of a project mid-transition.

Data flow for a build is short. Bazel reads MODULE.bazel and the BUILD.bazel files, pulls dependencies through the lockfile, and produces the IDE application or installers. The scripts at the root wrap that: bazel.cmd downloads bazelisk, bazel-build-all-community.cmd builds the community application, and installers.cmd produces installation packages. The README notes that all *.cmd scripts work on both Windows and Unix systems, which is why a Windows-suffixed script appears in Unix instructions.

Cloning intellij-community and getting the Android modules

The README's own setup path starts with Git. On Windows it asks for two global settings before cloning, to avoid long path and line ending problems. Run these in a terminal:

git config --global core.longpaths true
git config --global core.autocrlf input

Then clone the repository into the directory the README calls <IDEA_HOME>. If you do not need the full history, the README suggests a shallow clone with --depth 1 after clone:

git clone https://github.com/JetBrains/intellij-community.git
cd intellij-community

IntelliJ IDEA requires additional Android modules from separate repositories. The README provides a script for this, run from the project root, with a Windows equivalent:

./getPlugins.sh

The README adds an important constraint in a callout: always git checkout the intellij-community and android repositories to the same branches or tags. Mismatched branches between the two are a setup failure the documentation explicitly warns about, and it is easy to hit if you switch branches in one repository only.

Opening the source in IntelliJ IDEA and building installers

Opening the project has prerequisites the README lists explicitly: IntelliJ IDEA 2026.1 or newer, the Bazel plugin installed from Settings | Plugins | Marketplace, and, if the Maven plugin is disabled, a path variable named MAVEN_REPOSITORY pointing at <USER_HOME>/.m2/repository. With those in place, you use File | Open and select the .bazelproject file at the repository root, not the directory. If IntelliJ IDEA reports a missing or out-of-date required plugin such as Kotlin, the README says to enable, upgrade or install it and restart.

From the command line, the community application build is driven by a single script in <IDEA_HOME>. To produce installation packages instead, run installers.cmd. Options are passed as system properties, and the README points to BuildOptions.kt for the full list. One documented example builds installers only for the current operating system:

./installers.cmd -Dintellij.build.target.os=current

For debugging, passing --debug suspends the build and waits for a debugger to attach on port 5005. The README notes that installers.cmd runs OpenSourceCommunityInstallersBuildTarget, and that the same target can be invoked from IDEA through the run configuration named Build IntelliJ IDEA Installers (current OS).

The Docker build environment and the user ID detail

The repository ships a Dockerfile that defines a build environment target, and the README gives a two-command workflow for using it. The first command builds the image from the repository root, the second runs a container with the checkout mounted at /community. On Windows the README says to use PowerShell.

docker build . --target intellij_idea --tag intellij_idea_env
docker run --rm --user "$(id -u)" --volume "${PWD}:/community" intellij_idea_env

The README carries a note about the --user "$(id -u)" argument: it makes the container user match the host user, which prevents permission problems on the checked-out repository and on build output. This is not cosmetic. The Dockerfile creates a user named ide_builder with a home directory, sets HOME to /home/ide_builder, and marks /community and /home/ide_builder/.cache as volumes. The image also installs git, and the Dockerfile comments explain why: to retrieve the git revision the IDE was built from, with a TODO to switch to jgit or external stamping later. That comment is a useful signal about how much of the build still depends on a real git binary being present.

Where the Bazel migration bites: tests and IDE integration

The clearest limitation is stated in the README itself. Some tests are not yet possible to run with Bazel. The documented fallback is the tests.cmd script, referenced in the section on running IntelliJ IDEA in a CI/CD environment. If your work depends on a test suite that has not been migrated, your local loop is split between two systems, and that split is the migration's real cost rather than any single broken command.

The second limitation is tooling lock-in. Because IDE-only builds are no longer supported, the Bazel plugin is mandatory, and the README warns that the rough edges are mostly related to IDE integration. In practice this means the failure mode you are most likely to hit is not a compile error but an IDE that cannot resolve the project correctly after a plugin or version mismatch. The README's own remedy is to check for a missing or out-of-date required plugin and restart.

A third constraint is version coupling. The master branch targets the next major version of all JetBrains IDEs, so building it does not give you the release you are currently running. If you need to match a shipped IDE, the README directs you to the Build Number Ranges page to find the branch and build number for that older release, and you clone that branch instead.

intellij-community against the prebuilt Community Edition, and against Gradle

The realistic alternative for most readers is not another source repository but the prebuilt IntelliJ IDEA Community Edition, distributed from the JetBrains download page that the README links for the IDE prerequisite. The difference in approach is total: the prebuilt edition is an installed application you update through the IDE, while intellij-community is a source tree you compile with Bazel and whose output is installers you build yourself. Choosing the source tree buys you the ability to change platform behaviour, debug internals and produce a custom distribution. It costs you a Bazel toolchain, a multi-repository checkout with branch alignment, and a build measured in installers rather than seconds.

For plugin developers there is a second comparison worth making. The IntelliJ Platform Gradle plugin workflow targets a published platform artifact and lets you build a plugin without checking out the IDE source at all. That is the right default for most plugins. Working inside intellij-community makes sense when you need to change platform code itself, or to test against a platform build that has not been published. The repository's own contribution guide, CONTRIBUTING.md, is the entry point the README recommends for people who want to contribute code rather than consume the platform.

Maintenance, releases and what the licence files leave open

The repository is not archived, and the last push was on 2026-09-20. Recent releases listed for it include pycharm/2026.2.3 on 2026-09-18 and idea/2026.2.3 on 2026-09-16, so the source tree tracks shipping products closely rather than lagging behind them. The GitHub Actions workflows referenced in the README build IntelliJ IDEA and PyCharm on the master branch, which gives a public signal of whether the tree currently compiles.

Upgrade cost is dominated by the Bazel migration rather than by version bumps. While the migration is in progress, the README warns of temporary issues, and the tests.cmd fallback means part of your workflow may not move to Bazel when the rest does. Budget for that split rather than assuming a single clean transition.

On licensing, the honest position is that this article cannot tell you what you may do with a build. GitHub reports the license as NOASSERTION, and the repository ships LICENSE.txt and NOTICE.txt at its root. The README does not summarise either file. Read them, and treat any redistribution or commercial packaging decision as something to check against those texts rather than against the repository's public description.

Editorial conclusion

Adopt intellij-community if you are building a plugin against the IntelliJ Platform, debugging IDE internals, or packaging a custom IDE distribution; cloning it to get a Java editor is the wrong move, because the prebuilt Community Edition is the intended route and the repository README points users to the download page. Before committing, verify two things: that your IDE is IntelliJ IDEA 2026.1 or newer with the Bazel plugin installed, and that the tests you depend on can run under the Bazel migration, since the README states some tests cannot yet be run with Bazel and directs you to tests.cmd instead.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/intellij-community on GitHub
3. Project website
4. README
5. Releases