# Bloop: the Scala build server whose repository is mostly tooling, clients and generated docs

> A build server for Scala, run from any editor or build tool, maintained by the Scala Center. What the tree reveals is a project with more moving parts than its front page suggests: separate frontend and backend halves, a bridge per integration, a rifle tool, a docs generator and a repository formatted aggressively enough to keep a blame-ignore list.

**scalacenter/bloop** — Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.

- Repository: https://github.com/scalacenter/bloop
- Website: https://scalacenter.github.io/bloop/
- Stars: 942 · Forks: 213
- Language: Scala
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/scalacenter-bloop

## The stated goal is compile speed, the stated audience is two

The front page is short and makes two claims. The first is that Bloop is a build server for the Scala programming language and aspires to give Scala developers the best out-of-the-box experience, compiling, testing or running Scala code. The second is that it aims to be a solid platform for build tool authors to consume the Scala toolchain.

Those two audiences pull in different directions and the second one is the more unusual. A speed-focused build server is a normal tool. A toolchain others build on top of is a compatibility surface: once sbt plugins or editor plugins depend on it, changing behaviour costs other people's releases. The integration guide linked from the front page exists for exactly that audience, and the discord channel is offered to anyone still deciding whether Bloop is useful for their case.

The word in the description matters too. It says compile, test and run, not just compile. A build server that keeps a JVM warm across all three is a different operating assumption from a compiler wrapper, and it is also why the tool is described as a server rather than a command.

The homepage is scalacenter.github.io/bloop, and the project sits under the Scala Center rather than an individual account, which is the reason to expect it to outlive any single maintainer's interest.

## The tree splits into a frontend, a backend, and a bridge per client

The repository root tells you more about the architecture than the front page does. There is a frontend directory and a backend directory, plus a cli directory, a shared directory, and then a cluster of integration modules: integrations, bridges, and a separate benchmark-bridge.

That layout is a client-server split with a protocol in the middle. The backend owns the long-lived JVM state that makes compilation fast, the frontend is what a user sees, and each bridge is the adapter for one specific editor or build tool. The existence of a dedicated bridge for benchmarking is a small detail that says the project treats measurement as a first-class client rather than an afterthought.

The rest of the root is build and release infrastructure. There is build.sbt at the top, a project directory for sbt build definitions, a .sbtopts file and a .java-version file that pin the toolchain expectations, and a .jvmopts file. There is also a git-blame-ignore-revisions file, which is unusual at the top level of a repository and is worth explaining on its own.

A submodules file is present too, so at least one dependency lives outside this repository and is pinned by commit rather than by version.

## A blame-ignore list and two formatter configs, which tells you about churn

The top-level files describe how the code is kept consistent rather than what it does.

A .git-blame-ignore-revisions file lists commits that should be skipped when computing blame. That file exists because a commit that reformats an entire file makes every line look newly written, destroying the history that blame is for. The convention is to mark pure formatting commits as ignorable and never to mix reformatting with logic changes, which is exactly what the presence of the file implies is happening here.

Two more files handle the code itself. A scalafmt configuration fixes formatting, and a scalafix configuration governs lint rules and automated rewrites, and Scalafix in particular is the tool Scala projects use for code migrations across a whole codebase. Having both is a common pairing: Scalafmt for shape, Scalafix for meaning.

A separate .scala-steward.conf points at Scala Steward, which opens dependency bump pull requests automatically. Given a dependency surface as large as a build server's, that automation is close to mandatory, and it is a reasonable signal about how the project absorbs upgrades.

Together those four files are a maintenance policy expressed in configuration: format automatically, lint automatically, bump automatically, and keep blame readable across the automated commits.

## An npm manifest with one dependency, for contributor credits only

There is a package.json at the repository root, and it is worth reading closely because it does not mean what it usually means.

The entire devDependencies block contains one entry, the all-contributors CLI at a caret range. This is not a JavaScript project, and the file is not there to build a frontend. It is there because that CLI generates the contributor table from the git history and writes the section into the README.

So the JavaScript tooling in this repository is used exactly once, for attribution. That is a small and pleasant piece of engineering hygiene: the credit table is regenerated rather than hand-maintained, and regenerating it needs no permanent Node setup beyond that one package.

It also tells you something about what is not here. A build server with a web interface, and a project with a website directory, would both plausibly carry a larger JavaScript toolchain. Their absence in the manifest suggests the interface is rendered elsewhere, by whichever client is running, rather than shipped from this repository as assets.

For a reader trying to work out where to start in a codebase this size, that is a useful negative result: there is no build step for the web side hiding in the root manifest.

## docs-gen and website are separate, so the documentation is generated

Documentation gets more repository surface than a project of this size usually needs, and the split tells you how it is produced.

There is a website directory and a docs directory, and then a docs-gen directory. A generator with its own module usually means the docs are produced from the source rather than written twice, which is the only approach that survives a rename of a CLI flag or a change to an integration's name.

There is also a buildpress directory and a buildpress-config directory. Buildpress is the release tool for Scala itself, which is a notable dependency to see vendored or referenced in a separate project: it points to shared release conventions across the Scala toolchain rather than a bespoke publishing script.

And there is a bloop-rifle directory, the author's other tool for inspecting compiled artifacts, alongside an etc directory that likely holds shared resources and a notes directory that looks like working material rather than shipped content.

The Apache licence is present as both LICENSE.md and a separate NOTICE.md. Apache 2.0 requires the NOTICE file to be preserved when redistributing, so carrying one at all means the project has taken that obligation seriously, and the two-file arrangement is the standard way to do it in a repository that is not distributed as a single archive.

## Three patch releases in one year, and a branch that moved past them

The release history is a steady patch cadence rather than feature waves. v2.1.0 shipped on 28 May 2026, v2.1.1 on 7 July 2026, and v2.1.2 on 21 August 2026. Three releases inside three months, all on the 2.1 line, which is the shape of a project being maintained rather than rewritten.

The last push to the default branch is 2 October 2026, roughly six weeks after v2.1.2. For a tool with an integration surface, that is the ordinary state of things: fixes land on main and get batched into the next patch. It also means the default branch and the newest tag will disagree, and anyone who reports a bug against main has to say which commit they were on.

Nothing in the visible history tells you whether a 2.2 line is planned, and the front page does not claim a roadmap. Treat the tag list as the only version information you can rely on.

For build tooling specifically, that cadence is a genuine factor in adoption decisions. A build server that sits in everyone's compile path is easy to adopt and expensive to upgrade badly, so a predictable patch rhythm and visible tags matter more here than they would for a library.

## Four links, then nothing: the setup instructions live on the website

The front page is a pointer table rather than a document. Four rows, each one an emoji and a link: install it locally or on a CI server via the installation page, read more on the website, integrate your tool via the integration guide, or ask questions in discord.

There is no install command, no configuration example, no flag list and no sample output on the page itself. Every operational detail a new user wants is one click away, and the click goes to scalacenter.github.io/bloop.

That is a defensible choice for a project with a documentation site, and it keeps one copy of the instructions rather than two that drift. The cost is that the repository, which is where a lot of people meet a project first, tells you almost nothing about how the thing runs.

The one piece of local documentation worth knowing about is the contributing guide, and the code of conduct points at the Scala language's own conduct page rather than hosting its own.

So the honest way to evaluate Bloop is to read the site, not the readme: check what the install actually does to your machine, how the daemon is started and stopped, and whether the integration you need is maintained before you point your IDE at it.

## Conclusion

Bloop fits a Scala team that compiles and tests often enough that repeated JVM and compiler startup dominates the edit loop, and that has someone willing to own the integration layer. It does not fit a mixed-language shop that only needs an occasional Scala build, and it does not fit anyone who wants a self-contained install with no daemon to manage. Before adopting, read the installation page rather than the front page, because the visible documentation stops at four links and the setup instructions live on the site, and check which integration you actually need since bridges are separate modules per tool. Expect the version you read about to be behind the tag: the newest release is v2.1.2 from August 2026 while the branch has moved since.

## FAQ

### What is the Bloop build server used for?

Bloop compiles, tests and runs Scala code from any editor or build tool, keeping compiler state warm between invocations. It is also positioned as a platform for build tool authors who want to consume the Scala toolchain.

### How do I install the Bloop Scala build server?

The repository does not carry an install command. The front page points to the installation page at scalacenter.github.io/bloop/setup, which covers installing Bloop on a developer machine or a CI server.

### Who maintains Bloop and what licence does it use?

The repository sits under the Scala Center and is licensed under Apache 2.0, with both a LICENSE.md and a NOTICE.md at the root. Releases v2.1.0 through v2.1.2 shipped between May and August 2026.

### Can I integrate my own editor or build tool with Bloop?

That is an explicit goal, with a dedicated integration guide for tool authors and separate bridge modules in the repository for each client. The bridges directory and the frontend and backend split show the tool is designed as a server that clients connect to.

### Why does the Bloop repository contain a package.json?

The manifest has a single dev dependency, the all-contributors CLI, which regenerates the contributor table in the README from git history. No JavaScript build step is involved in Bloop itself, which is a Scala project built with sbt.

## Sources

- [License: Apache-2.0](https://github.com/scalacenter/bloop/blob/main/LICENSE)
- [Project website](https://scalacenter.github.io/bloop/)
- [README](https://github.com/scalacenter/bloop/blob/main/README.md)
- [Releases](https://github.com/scalacenter/bloop/releases)
- [scalacenter/bloop on GitHub](https://github.com/scalacenter/bloop)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scalacenter-bloop