akka-core: thirty-five actor libraries in one Scala repository

A repository of thirty artifacts, not one library

The most useful thing about this repository is visible in the directory listing. Alongside `akka-actor/` and `akka-actor-typed/` there are `akka-remote/`, `akka-cluster/`, `akka-cluster-sharding/`, `akka-cluster-tools/`, `akka-persistence/`, `akka-persistence-typed/`, `akka-persistence-query/`, `akka-distributed-data/`, `akka-stream/`, `akka-discovery/`, `akka-coordination/` and `akka-serialization-jackson/`, among others. Every one of these is a separately versioned artifact.

That distinction matters more than the marketing does. You can depend on the actor model alone and take on no clustering, no remoting and no Akka Cluster dependency. The README makes a related argument in slightly different words, claiming a depth of integration you cannot achieve by picking libraries to solve individual problems and trying to piece them together. Both statements are true at once: the modules are separately consumable, and they are designed to share one concurrency and distribution model.

The build is a single `build.sbt` covering the whole set, with `artifact-bom/` in the tree for the bill of materials, `project/` and `plugins/` for the build definition, and `.scalafmt.conf`, `.editorconfig` and `.sbt-java-formatter.conf` for formatting. There is also a `kubernetes/` directory, which tells you deployment manifests ship alongside the code rather than being left to an operator.

What the classic and typed APIs actually give you

The README's account of the core library is worth reading closely, because it is specific about what you stop having to do. Three claims appear: multi-threaded behavior without low-level concurrency constructs like atomics or locks, transparent remote communication between systems and their components, and a clustered high-availability architecture that is elastic and scales on demand. The stated benefit of the first is that you avoid thinking about memory visibility issues, which is exactly the class of bug that is cheap to prevent with this model and expensive to debug without it.

The typed API exists alongside the classic one. `akka-actor-typed/` and its test counterpart `akka-actor-typed-tests/` sit next to `akka-actor/` and `akka-actor-tests/`, and the same split runs through persistence, sharding and streams. The typed variants express actor behavior as a message protocol, so the set of things an actor can be asked is visible in its signature rather than implied by which methods its body happens to call.

For resilience the README names the approach directly: let it crash, borrowed from the telecom industry, on the argument that a supervised process that fails is easier to reason about than a process that catches everything and limps on. Supervision hierarchies are where that idea lives, and `akka-stream/` is where it gets applied to backpressure and failure handling in data flows.

Sharding, persistence and the rest of the distributed vocabulary

The modules beyond the actor core map onto recognizable distributed systems problems, which makes them easier to evaluate than the platform framing suggests.

`akka-cluster-sharding/` and `akka-cluster-sharding-typed/` distribute entities across nodes, so a service does not have to decide which machine owns a given customer or device. `akka-cluster/` handles membership and the cluster's own view of itself, `akka-cluster-tools/` covers split brain resolver and the other operational pieces, and `akka-cluster-metrics/` exists to feed those decisions from real load data. `akka-discovery/` abstracts service lookup, which is how a node finds its peers without hardcoded addresses.

`akka-persistence/` is the event sourcing and state snapshot machinery, with `akka-persistence-query/` for reading the journal back out as a stream, `akka-persistence-shared/` for sharing journal space, and `akka-persistence-tck/` and `akka-persistence-testkit/` for conformance. `akka-distributed-data/` provides eventually consistent replicated data structures, which is a different guarantee from the sharding modules and should not be confused with them.

`akka-stream/` is the reactive streams layer, and the README ties the whole model to the Reactive Manifesto. `akka-stream-typed/` and the three stream test modules (`akka-stream-testkit`, `akka-stream-tests`, `akka-stream-tests-tck`) suggest that streaming behavior is verified through conformance suites rather than hand-written assertions.

Recent releases read like a hardening effort

The last three releases available here are point releases on the 2.x line, and their contents say something about where the maintainers are spending attention. Version 2.10.22, published 2026-09-09, includes rejecting negative frame sizes in artery, resolving the per-stream frame length bound up front in TCP framing, matching acknowledgement messages against a full unique address so a stale ack from a previous incarnation of a node is refused, and bounding the flush of outstanding offers in AeronSink so transport shutdown completes instead of hanging. Version 2.10.21, published 2026-08-12, fixes a stale remember entity message that could crash a typed sharding shard, and version 2.9.9, published 2026-08-11, backports that same crash fix to the 2.9 line.

Read as a group, that is a pattern of tightening the transport and sharding edges rather than adding features. Frame size validation, incarnation-aware acknowledgement, and a crash fix backported across two minor versions are the kinds of changes that only matter at scale, under partition, and during rolling restarts.

The last push to the default branch was 2026-09-21, so the 2.10 line is still moving. The repository is not archived, and at 13,279 stars with 3,532 forks it is one of the more widely embedded Scala projects in existence.

The Business Source License is the decision you have to make first

The README's license section is short and unambiguous: Akka is licensed under the Business Source License 1.1, with details in a linked license FAQ. Tests and documentation are under a separate license, with a LICENSE file in each documentation and test root directory. The license field on GitHub reads as unasserted, which is a classifier gap rather than a contradiction, since the README states the terms directly.

This is the first question to settle, because it changes the nature of the adoption. BSL 1.1 is source-available: you can read, build and run the code, and the license converts to an open source license after a change date that the release notes update per version. The release notes for 2.10.21 and 2.9.9 both include a chore commit whose subject is a license change date update, which tells you those dates are versioned rather than fixed at publication.

The wider context is in the README's opening. The platform is described in two commercial pieces, the Akka SDK with AI assistance and automatic clustering, and Akka Automated Operations, a managed offering running inside your VPC, both built on the libraries in this repository. The libraries are the part you can read and depend on directly. Reading the license FAQ before designing around the module set is a better use of an afternoon than discovering the constraint during procurement.

Eleven samples and the documentation split

The `samples/` directory is the most efficient way to understand the intended usage, and it is unusually complete. There are paired quickstarts for Java and Scala, then parallel implementations for cluster, distributed data, state machine, sharding and Kafka-to-sharding, which means every significant feature can be read in whichever language you prefer without hunting through two directories.

That Kafka sample is also the clearest evidence of how Akka relates to a streaming platform. It is named akka-sample-kafka-to-sharding-scala and its position in the list implies consumption from a topic feeding into sharded entities, which is the complementary pattern rather than a competitive one.

Documentation lives on doc.akka.io rather than in this repository, though `akka-docs/` is present in the tree. The README repeats the same pointer twice, once for general libraries and once for the core libraries, and notes that reference docs for the core are published separately for Scala and Java. Current versions across all libraries are listed on the Akka Dependencies page, and releases specific to this repository are tracked on the GitHub releases page, which is the distinction that matters when you are pinning versions across the whole Akka set.

For contributors, `CONTRIBUTING.md` and `RELEASING.md` are both in the tree, and the README asks for pull requests rather than just issue reports, with a dev chat offered for faster clarification.

Editorial conclusion

akka-core is best understood as the substrate rather than the product. The repository contains around thirty published modules, each one a separate artifact you can adopt on its own, and the parts most teams actually need are `akka-actor-typed`, `akka-stream`, `akka-cluster-sharding-typed` and `akka-persistence-typed`. The tree also shows how seriously the project takes correctness work, with `akka-actor-tests`, `akka-persistence-tck`, `akka-remote-tests` and `native-image-tests` sitting next to the code they verify. What the README does not settle is the licensing question that matters most to a new adopter: the code is available under the Business Source License 1.1, not a conventional open source license, and the terms change at a date recorded per version. Start at the akka-dependencies page to get a consistent BOM, then read the quickstart sample in the language you actually write.

Frequently asked questions

Official sources

1. akka/akka-core on GitHub
2. Issues
3. Project website
4. README
5. Releases