Bloop: a build server that sits between your editor and the Scala compiler
Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.
At a glance
- What is it?
- Bloop is a Scala Center build server and CLI that compiles, tests and runs Scala code outside your build tool, exposing the toolchain over a socket so editors and other tools can drive it. The design is sound for editor-driven workflows and less obviously useful if you only ever build from the command line.
- Who is it for?
- Adopt Bloop if you use an editor integration that speaks its protocol and you want compilation to happen in a process that survives editor restarts. Do not adopt it if your workflow is a single build tool invoked from a terminal with no editor client, because you would be maintaining a second compilation path for no visible gain.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Scala, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Bloop targets: compilation as a service, not a side effect of your build tool
In a normal Scala setup, the compiler runs inside whatever process your build tool started. Close the editor, and the compiler state goes with it. Start a second tool that also wants to typecheck the project, and now two JVMs are compiling the same sources with no awareness of each other. Bloop takes the opposite position: compilation is a long-lived server process, and your build tool and editor are clients of it. The repository describes the project as "a build server and CLI tool to compile, test and run Scala fast from any editor or build tool", and the README frames the goal as providing "the best out-of-the-box experience to Scala developers and a solid platform for build tool authors to consume the Scala toolchain". That second half matters more than the first. Bloop is not trying to replace sbt or Mill. It is trying to be the layer underneath them, so that an editor, a test runner or a bespoke tool can ask for a compile without embedding the Scala compiler themselves. The audience is therefore two groups: Scala developers whose editors need a compilation backend, and tool authors who would otherwise reimplement incremental compilation, classpath assembly and test discovery. If you are neither, Bloop adds a process to your machine and an integration to maintain.
What the repository actually documents about the mechanism
The README is deliberately thin on architecture. It points outward: an Installation page for setup, the project website for learning how to use Bloop from a build tool and editor, and a separate Integration Guide aimed at tool authors. That split tells you something about where the design detail lives. The server-and-client shape is stated plainly in the description, and the topics list (build-system, compilation-server, developer-tools) confirms the positioning, but the README does not describe the wire protocol, the incremental compilation strategy, or how build state is persisted between runs. I cannot confirm those from the supplied material, and I am not going to guess. What can be confirmed is the interface surface: a CLI, a server, and integrations with editors and build tools. The practical consequence is that evaluating Bloop means evaluating it through a client. You will not get far reading the README alone; the Integration Guide is the document that matters if you are writing the client, and the website is the one that matters if you are configuring an existing one.
Getting it running: install first, then wire up a client
The README gives one instruction for installation, and it covers both developer machines and CI: follow the Installation page at scalacenter.github.io/bloop/setup. There is no install command in the README itself, no package name, no version pin, so the setup page is the only authoritative source for the command that matches your platform. What the README does supply is the direction of travel after installation. You either configure a build tool or editor that already knows about Bloop, or, if you are the one writing the tool, you read the Integration Guide at scalacenter.github.io/bloop/docs/integration. The README also points questions and use-case uncertainty at a Discord channel rather than at a documentation page, which is an honest signal that the fit between Bloop and a given workflow is not always answerable from the docs. Practically: install, then connect a client, then verify that a compile actually routes through the server rather than through your build tool's own compiler invocation. If you skip that last step you will not know which of the two compiled your code.
Where Bloop is the wrong tool
The clearest failure mode is a workflow with no client. If you build from a terminal with a single build tool and never open an editor that speaks to Bloop, you have added a server process, a lifecycle to manage, and a version to keep in step with your build tool, in exchange for nothing observable. The README's own framing supports this reading: the value proposition is stated in terms of editors, build tools and "bespoke integrations", not in terms of raw compile speed for a headless build. A second constraint is version alignment. Bloop had three releases in the space of roughly four months in 2026 (v2.1.0 in May, v2.1.1 in July, v2.1.2 in August), and its usefulness depends on the client on the other end of the socket agreeing with the server about the protocol. A build tool integration that lags the server release is a real coordination cost, and the README does not describe any compatibility policy. Third, and this one is structural rather than incidental: because Bloop is a platform for tool authors, its documentation is organised around integration rather than around troubleshooting a developer's daily compile. If something goes wrong in the middle of the stack, the README gives you a Discord link, not a diagnostic procedure.
The alternative: let the build tool own compilation
The obvious alternative is to do nothing and let sbt or Mill compile in-process, which is what most Scala projects do by default. The difference in approach is not speed, it is ownership of compiler state. In the default model, the build tool owns the compiler, the classpath and the incremental analysis, and every consumer of that project either goes through the build tool or duplicates its work. In Bloop's model, the server owns that state and the build tool becomes a client. That inversion is what makes multiple consumers possible: an editor and a test runner can both ask the same server for a compile instead of each maintaining their own compiler. It is also what makes Bloop optional in a way the build tool is not. You cannot remove sbt from an sbt project. You can remove Bloop, and if your editor falls back to invoking the build tool directly, your workflow still functions, just with the coupling the server was meant to remove. That asymmetry is the honest way to judge the trade: Bloop buys decoupling and pays for it with an extra process and an extra version to track.
Maintenance cost, and what the Apache-2.0 licence does and does not settle
Bloop is Apache-2.0 and the repository is not archived, with the last push dated 2026-09-07 and v2.1.2 released 2026-08-21. The release cadence across v2.1.0 through v2.1.2 suggests active maintenance on the 2.1 line, but the README does not state a support window, a deprecation policy, or which client versions are tested against which server versions. Treat that as unknown and verify it yourself before pinning Bloop in a CI image. Apache-2.0 permits commercial and private use and includes a patent grant; it also requires that you preserve licence and notice files when you redistribute. If you embed Bloop in a product you ship, read the licence text rather than a summary, and note that this article is not legal advice. The operational cost is the part that gets underestimated: a build server is a long-running process, so you inherit startup, shutdown, memory and log management that a short-lived compiler invocation did not impose. On a laptop that is a background service. In CI it is a process you start, wait for, and tear down on every job, and the README's Installation page is the only place that tells you how.
Who should adopt Bloop, and what to check before you do
Adopt it if an editor or tool you already use ships a Bloop integration and you want compilation to survive editor restarts and be shared between tools. Adopt it if you are writing a Scala tool and would rather consume a compilation server than embed the compiler yourself, in which case the Integration Guide is your starting document and the README is not. Do not adopt it if your only interface to the build is a terminal, or if the tools you depend on have no Bloop client, because the server has nothing to serve. Before you commit, three checks: confirm on the setup page which install path applies to your platform and whether it covers CI as well as a developer machine, confirm that your editor or build tool integration targets the v2.1.x protocol rather than an older line, and confirm what happens to the server when your build tool restarts, since that lifecycle is the thing you are taking on. If those three answers are clear, the design is worth the process. If any of them is not, the default in-process compiler is still there and requires no decision at all.
Editorial conclusion
Adopt Bloop if you use an editor integration that speaks its protocol and you want compilation to happen in a process that survives editor restarts. Do not adopt it if your workflow is a single build tool invoked from a terminal with no editor client, because you would be maintaining a second compilation path for no visible gain. Before committing, verify which of your tools already ship a Bloop integration, check the setup page for the install path that matches your platform, and confirm the Bloop version your client expects against the v2.1.x release line.
Community notes