One toolchain, one build server, one developer experience

Build and test Scala code of any size quickly, from any editor, from any build tool

Why Bloop?

Tighter developer workflow

Be more productive in Scala and reduce your compile-edit-test workflow. Use Bloop to enjoy an optimized developer experience that provides features from incremental to batch compilation, from running and debugging on the JVM to building Scala.js or Scala Native applications.

One tool, multiple editors and IDEs

Bloop integrates with IDEs and text editors to provide a short feedback cycle and reliable compiler diagnostics. Use Bloop with IntelliJ or Metals, an LSP server to code with editors such as Visual Studio Code, Sublime Text, Vim, Emacs, etc.

Compatible with many build tools

Export your project build to Bloop even if your build tool lacks Bloop support. Everything in Bloop has been thought to be build-tool-agnostic and bring you the best Scala developer experience, no matter what tool you use.

	Supported
sbt	✅
Maven	✅
Gradle	✅
mill	✅
Pants	✅

Extensible to your custom needs

Customize Bloop to serve your personal needs or those of your company. Use the CLI to write custom scripts, write your own build tool on top of bloop or leverage the Build Server Protocol implementation to control and extend Bloop with your own build client, in any language.

Reimagining what a build server is with Bloop

Bloop is a build server that runs in the backgroud of your machine and serves build requests for a specific workspace. As it knows how your build workspace is being built by every client, it can optimize and provide guarantees that conventional build tools cannot. Bloop has taken the concept of build server and stepped it up a notch, enabling you to use it in ways that haven't yet been fully explored.

Run multiple build tasks, concurrently, from any clients

Have you ever wanted to test your code from your IDE and run a main class on your terminal whenever there are changes? Bloop allows you to have multiple build clients (IDEs, build tools, custom scripts, scheduled jobs) triggering build commands at the same time, while the build server makes sure all build commands produce independent outputs, reuse as much state and resources as they can and don't block each other.

Maintained by a rich community of contributors

Developed initially at the Scala Center —a non-profit organization established at EPFL with the goals of promoting, supporting, and advancing the Scala language— the project has grown to be adopted by many industry leaders and it is now maintained by a dedicated network of contributors across the world.