Apache Pekko: the Apache-licensed actor framework forked from Akka 2.6.x

A fork of Akka 2.6.x, taken before the licence changed

Apache Pekko exists because of a licensing decision made elsewhere. The project is a fork of Akka 2.6.x, taken prior to the Akka project's adoption of the Business Source License, and it has since picked up some features from Akka 2.7.0, which the project states is now Apache 2.0 licensed. The result is an actor framework that can be shipped inside a commercial product without the licence negotiation that a Business Source License imposes.

What sits on top of that fork is a substantial framework rather than a thin compatibility layer. The stated purpose is building applications that are concurrent, distributed, resilient and elastic, using the Actor Model to provide high-level abstractions for concurrency. On top of that core the project also provides libraries for persistence, streams, HTTP, and more.

The scale of the codebase is visible in the repository layout, which is worth reading before committing. Alongside the classic `actor/` and `actor-typed/` modules there are `cluster/`, `cluster-typed/`, `cluster-sharding/`, `cluster-sharding-typed/`, `cluster-tools/`, `cluster-metrics/`, `coordination/`, `discovery/`, `distributed-data/`, `persistence/`, `persistence-query/`, `persistence-shared/`, `persistence-typed/`, `stream-testkit/`, `remote/`, `multi-node-testkit/`, `kubernetes/`, `osgi/`, `pki/`, `slf4j/`, and two serialization modules, `serialization-jackson/` and `serialization-jackson3/`. There are also testing modules, `actor-testkit-typed/`, `actor-tests/`, `actor-typed-tests/`, `stream-testkit/`, and a `persistence-tck/` compliance kit.

That layout is the honest answer to the question of whether Pekko is a library or a platform. It is a platform, and every dependency you pull in comes with that scope attached.

The build starts with JDK 17 and sbt, nothing else

Pekko is built with sbt, and the documentation is unusually specific about the toolchain. The prerequisites are a Java Development Kit version 17 or later, sbt installed and using that same JDK, and Graphviz for the scaladoc generation build task, which is part of the release. IntelliJ IDEA users are told to set the project JDK, the Scala compiler server JDK, and the sbt JRE all to version 17.

There is a platform caveat stated up front. The CI build is Linux based on Ubuntu, most Pekko developers use Macs or Linux machines, and there have been reported issues when building with Windows, tracked as issue 829. On the IntelliJ side the documentation links a Q&A entry with a visual guide for the JDK 17 setup.

The build commands themselves are a normal sbt list, and each one has a stated purpose:

sbt compile

That compiles the main source for the default Scala version, 2.13, and the variant `sbt +compile` compiles for all supported Scala versions. Testing comes in three shapes:

sbt test

`sbt test` compiles and runs the unit tests, `sbt testQuick` is the same but in repeated shell mode runs only the failing tests, and `sbt testQuickUntilPassed` loops until the tests pass. Packaging and publishing are separate steps:

sbt package

sbt publishLocal

sbt publishM2

`sbt package` builds the jars into the target directories of the various modules, and for the actor module specifically the jar lands in `actor/target/scala-2.13/`. `sbt publishLocal` pushes to the local Apache Ivy repository and `sbt publishM2` pushes to the local Apache Maven repository.

Documentation has its own tasks, `sbt docs/paradox` for the module feature docs, with `sbt docs/paradoxBrowse` opening the result in a browser, and `sbt unidoc` for the Javadocs of all modules, which is the one that needs Graphviz.

Version numbers are derived from git, not from a release tag

This project has no GitHub releases, and the way versions are produced explains why. The version number that appears in filenames and documentation is derived by default. The derived version contains the most recent git commit id, or the date and time if the directory is not under git control.

That default is inconvenient when you want a stable coordinate, and the documentation offers two ways to set the version explicitly when running sbt commands. You can set it on the command line:

sbt "set ThisBuild / version := \"1.0.0\"; sourceDistGenerate"

Or you can add a file called `version.sbt` next to the `build.sbt` file containing the same assignment:

ThisBuild / version := "1.0.0"

The source release itself is generated by `sbt sourceDistGenerate`, which writes to `target/dist/`.

For a team that wants reproducible coordinates this is a real operational difference from a project that tags releases. There is no release list in the repository, no changelog entry that maps to a published artifact, and no way to point a dependency at a version without deciding which commit you mean. The repository does carry a CHANGELOG.md, and a `.scala-steward.conf` file for automated dependency updates, so the history of the code is tracked even though the release history is not.

Governance files show what an Apache incubation looks like

The repository root is a good indication of the project's stage. Beyond the usual build files it contains `.asf.yaml`, the Apache Software Foundation configuration file, along with `LICENSE`, `NOTICE`, `KEYS`, `COPYING.protobuf`, and a `legal/` directory. That legal and governance scaffolding is a signature of an ASF project and it matters for anyone who needs a licence and trademark story that a vendor cannot later change.

There is also a `SECURITY.md` and a `THREAT_MODEL.md` at the root, which is not a common thing to find in an actor framework and suggests the maintainers treat the cluster and remote modules as a security surface in their own right. The presence of `pki/`, `osgi/`, and `kubernetes/` modules points the same way: the framework ships pieces for certificate handling, OSGi packaging, and Kubernetes deployment.

Two files in the root are unusual enough to mention. `AGENTS.md` and `CLAUDE.md` sit alongside `CONTRIBUTING.md`, and the root also holds `.git-blame-ignore-revs` for large-scale reformatting commits, `.scalafmt.conf` and `.scalafix.conf` for formatting and lint rules, and `.sbt-java-formatter.conf`. A large Scala codebase that keeps a formatter configuration, a fix configuration, and a blame ignore list is a codebase with an enforced style.

The last push to the repository was on 2026-10-16, so the code is being worked on continuously even though no tagged releases exist.

The community channels are split by audience

The project documents four distinct places to ask questions, and the split is deliberate. GitHub discussions are for questions and general discussion. Two mailing lists exist, the Pekko dev list for Pekko development discussions and the Pekko users list for user discussions, both hosted at lists.apache.org under the pekko.apache.org domain. GitHub issues are for bug reports and feature requests.

The issue tracker carries an explicit instruction to search existing issues before creating new ones, and to consider asking in discussions or the mailing list first if you are unsure whether you have found a bug. That is a small but revealing detail about how a project of this size expects to be used: as a support surface that is actively curated rather than a queue that anyone can append to.

Contributions are described in CONTRIBUTING.md, which covers the development workflow and how to create a pull request, and the project states plainly that contributions are welcome with the invitation to open an issue or submit a pull request for any improvement idea. Code of conduct follows the Apache code of conduct, and participation means agreeing to its terms.

The nightly build badges at the top of the README, one for the general nightly builds workflow and one for nightly Aeron tests, are the only release signal the README offers besides the absence of releases.

Where Pekko is the wrong choice

The framework is large and the boundary cases are specific.

First, the licence advantage evaporates if your team is already committed elsewhere. The fork point is Akka 2.6.x, and Pekko carries some features from Akka 2.7.0. A team on the newest Akka line cannot move to Pekko by changing an import and keep every behaviour it relies on, and a team on Akka 2.6.x has the closest possible starting point. The question to ask is not which framework is better but which coordinate set your deployment already tracks.

Second, there is no released artifact list to point a build at. Versions are derived from git commit ids unless you set them yourself, and the documentation assumes you are building from source. Teams that consume libraries as published coordinates from a repository will need to run the publish steps into their own local Ivy or Maven repository and manage that pipeline themselves.

Third, the build story is not neutral. The CI is Linux, most developers are on Macs or Linux, and Windows builds have reported issues. There is a Graphviz dependency for the scaladoc task that is part of the release process, so the release toolchain itself has prerequisites beyond a JDK and sbt.

Finally, a team that does not want an actor model at all should not adopt Pekko to get one. The project is explicit that the Actor Model is the organising abstraction, with persistence, streams, HTTP, and the rest layered on top. If the requirement is concurrent tasks in one process, an actor framework with clustering, sharding, and remote modules is a large answer to a small question.

What the fork changes and what it does not

The honest comparison is against two options rather than one.

The first option is doing nothing and staying on the Akka line. The Pekko README states the fact that decides this comparison: Akka adopted the Business Source License, and Pekko was forked from 2.6.x before that point. An Apache 2.0 grant removes the question of when the licence changes, which for a framework embedded in a product distributed to customers is a question that has to be answered. The cost of that answer is owning the fork, including the parts you do not touch.

The second option is not using an actor framework and writing the concurrency directly on the JVM, with an executor and your own message handling. The difference in approach is architectural rather than incremental. Pekko gives you a runtime where actors own state, where messages are the only way to interact, and where supervision and restart are part of the model. A hand-rolled layer starts from threads and shared state, which is simpler to start and harder to keep correct as the system grows.

Between those, Pekko's specific draw is the breadth of the module set. A team that needs cluster sharding, typed actors, persistent event sourcing, or a stream engine finds all of it under one roof with one licence, rather than assembling separate libraries. The same breadth is the cost, and it is the reason the repository carries test kits, a persistence compliance kit, a multi-node test kit, and JMH benchmarks under `bench-jmh/`.

Editorial conclusion

Apache Pekko is a sound choice for a Scala or Java team that wants the Akka 2.6.x programming model under a licence it can ship and modify without a Business Source License conversation, and it is a poor fit for a team that has already standardized on Akka 2.7.0 and needs the newest upstream features on day one. Check three things before committing: that JDK 17 and sbt are available, since the build requires both and the CI is Linux based with reported Windows build issues, that the module set in the repository root covers what you need, from `persistence/` to `cluster-sharding-typed/`, and that your team is prepared to own the fork, because the project has no GitHub releases and the build outputs come from source rather than a published artifact list.

Frequently asked questions

Official sources

1. apache/pekko on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README