# akkadotnet-code-samples: runnable Akka.NET reference apps, not tutorials > This repository is a set of copy-and-pasteable Akka.NET applications covering sharding, RabbitMQ backpressure, CQRS with Akka.Persistence.Query, Autofac hosting, a cluster client and .NET Aspire bootstrap. It explicitly does not try to teach actor modelling, and its contribution rules are unusually strict about how a sample must be shaped. **petabridge/akkadotnet-code-samples** — Akka.NET professional reference code samples - Repository: https://github.com/petabridge/akkadotnet-code-samples - Website: http://petabridge.com/blog - Stars: 559 · Forks: 256 - Language: C# - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/petabridge-akkadotnet-code-samples ## Reference implementations instead of actor modelling lessons The stated purpose of this repository is to give Akka.NET developers a set of reference applications they can explore, and its own README is direct about what these samples are not. They are not designed to teach how to model complex domains with actors. What they are designed to do is demonstrate copy-and-pasteable approaches to running Akka.NET infrastructure correctly and succinctly. That distinction decides how you should use the code. If you arrive expecting a tour of actor concepts, you will find a set of running systems instead, each one solving an infrastructure problem. The problems are the familiar ones of distributed .NET: where does cluster sharding get its state, how do you keep a message broker from overwhelming a consumer, how do you separate the write model from the read model, how do you wire a dependency injection container into an actor system, how does a client outside the cluster talk to it, and how do you bring the whole thing up in a modern container platform. The audience is a developer who already knows the actor model and now needs a working reference for a specific piece of plumbing. That is a narrower and more useful audience than the one a tutorial series would serve. ## The six samples that are currently listed The README enumerates the current samples with links into the src folder of the repository: ```bash 1. [Akka.NET Cluster.Sharding with Akka.Persistence.SqlServer and Razor Pages](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/clustering/sharding-sqlserver) 2. [Akka.Streams.Amqp.RabbitMQ with Akka.Cluster.Sharding - Reliable Delivery + Backpressure Support](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/reliability/rabbitmq-backpressure) 3. [Event-Sourcing and CQRS with Akka.Persistence and Akka.Persistence.Query](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/cqrs/cqrs-sqlserver) 4. [Autofac And Akka.Hosting Integration](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/dependency-injection/AutofacIntegration) 5. [Akka.NET Cluster Client](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/clustering/cluster-client) 6. [Akka.NET Cluster Setup Using Microsoft .NET Aspire](https://github.com/petabridge/akkadotnet-code-samples/tree/master/src/clustering/cluster-bootstrap/Aspire) ``` Read as a list, the coverage is deliberate rather than accidental. Two samples touch cluster sharding, one of them pairing sharding with SQL Server persistence and Razor pages, which is the shape many line-of-business applications need. One sample covers the broker side, pairing Akka.Streams.Amqp.RabbitMQ with cluster sharding and framing the topic as reliable delivery with backpressure support. One covers event sourcing with CQRS through Akka.Persistence and Akka.Persistence.Query. One covers dependency injection with Autofac through Akka.Hosting. One is a cluster client for code running outside the cluster boundary. One covers cluster bootstrap using Microsoft .NET Aspire. Six entries is a small catalogue, and the README calls the list current, which reads as a curated set rather than an exhaustive one. ## The eight contribution rules that shape every sample The contribution section is the most opinionated part of the repository, and it tells you a great deal about what a sample here is expected to be. Pull requests are accepted for new samples or changes to existing ones, but the README states that a strict quality standard is maintained. The rules are explicit. Every sample should be framed as a self-hosted service and should rely on Akka.Hosting for management of the ActorSystem. Samples needing multiple nodes should ideally run inside Kubernetes or docker compose. Each sample needs a complete README.md explaining what it does, what a user needs to run it, and the steps to execute. If a sample requires Kubernetes or docker compose, a .cmd and a .sh script must be provided to set the infrastructure up and another pair to tear it down. Samples should not ship a full blown nuke build system, because that is called overkill. All samples should reference a single Directory.Build.props file, which already exists in the repository, and package versions are centrally managed through the root Directory.Packages.props file rather than hard-coded in individual projects. Samples should live in their own solution files instead of one giant solution, and they should be organised coherently by folder. Those rules are effectively a definition of what makes a sample reusable here, and a newcomer can infer the expected project shape from them without reading a single line of sample code. ## Central version pinning with Directory.Packages.props The mechanism that keeps a collection of samples building against the same stack is the two files at the repository root, Directory.Build.props and Directory.Packages.props. The contribution rules are explicit that Directory.Build.props determines the version of Akka.NET, Akka.Hosting, ASP.NET, the .NET runtime and the Microsoft.Extensions packages used, and that Directory.Packages.props is where package versions are centrally managed and should be referenced rather than hard-coded inside individual projects. The top level of the repository matches that story. Alongside those two files sit global.json, which pins the SDK the build expects, a build.ps1 build script, a RELEASE_NOTES.md, and directories for infrastructure, scripts, images and src. This is the part of the repository with real consequences for an adopter. A sample that hard-codes its own Akka.NET version would drift from the rest of the collection and stop being a fair reference, which is exactly why the rules forbid it. The flip side is that you cannot simply lift one project out of the folder and expect it to build on its own: the pinned versions and the shared props file are part of what makes the sample correct, so a copy taken outside the repository needs those files carried with it. ## Docker compose and Kubernetes scripts as a requirement Samples that need more than one node are expected to run inside Kubernetes or under docker compose, and the infrastructure requirement comes with a script requirement. If a sample needs one of those environments, the repository asks for a .cmd script and a .sh script to set the infrastructure up, and another to tear it down. That is a smaller ask than it sounds, and it is aimed at a specific failure. A distributed actor sample is close to useless if the reader cannot start the cluster, join a second node, watch a shard rebalance and then clean up afterwards. Requiring both a Windows shell and a Unix shell script for setup and teardown means the same two-step lifecycle works on a developer laptop regardless of platform, and it keeps the teardown step explicit, which matters when the sample has left containers, volumes and databases behind. The repository carries infrastructure and scripts directories at the top level, so the convention is visible from the root. The README does not document a single entry point command that runs every sample, and each sample is required to carry its own README.md with the steps to execute it, which means the run instructions live with the sample rather than in one central place. ## Licensing split between code and diagrams The licence arrangement is unusually precise, and it covers two different asset classes. All source code is licensed under Apache 2.0, with the details in the LICENSE file at the repository root. All of the visuals used to explain the samples are licensed under Creative Commons Attribution 4.0 International instead, and the README explains the condition: you are free to modify and use the diagrams in your own derivative works as long as you comply with the text of that licence. The practical reading is straightforward. If you lift sample code into a commercial product, Apache 2.0 applies, which permits use and modification with the usual notice and patent-grant conditions. If you lift a diagram into a slide deck or an internal document, the attribution requirement travels with it. The repository's stated licence is Apache 2.0, and the copyright line reads Copyright 2015 - 2026 Petabridge, LLC, which is a company described as dedicated to making it easier for .NET developers to build distributed applications and as a provider of Akka.NET support, consulting and training. The commercial relationship between the samples and the maintainer's consulting business is worth keeping in mind when you judge how a given sample is prioritised. ## Samples and documentation live in the same upstream project The repository does not stand alone in the Akka.NET ecosystem, and that matters when you are copying from it. The contribution rules require every sample to rely on Akka.Hosting, which lives in its own repository, and the samples themselves lean on Akka.Persistence, Akka.Persistence.SqlServer, Akka.Persistence.Query, Akka.Streams.Amqp.RabbitMQ, Akka.Cluster.Sharding and Autofac. Each of those has its own release cycle, and none of them is pinned by this repository alone, only coordinated through the central props files. The upstream sources of truth for the framework itself are the Akka.NET project and the Akka.Hosting project, and the project homepage points at the Petabridge blog rather than at a separate documentation site. That means deep questions about why a particular API behaves as it does will not be answered here; the samples are meant to show a shape, not to specify semantics. The last push to the repository was on 2026-10-18, and there are no GitHub releases for it, so the sample set changes by commit rather than by version. A RELEASE_NOTES.md exists at the root, but the sample list in the README is the thing to watch, since it is what tells you which references are currently considered current and which have been dropped. ## Conclusion Adopt this repository if you are standing up Akka.NET infrastructure and want a working shape to copy for sharding, event sourcing, messaging or hosting rather than a prose explanation of actor design. Do not adopt it as a learning path for actor modelling, since the README rules that out explicitly, and do not expect a curated catalogue, because the current sample list runs to six entries. Verify first that the versions pinned in Directory.Packages.props and Directory.Build.props match the Akka.NET release your own project targets, and read the README.md of the individual sample you intend to copy, since each sample is required to carry its own run instructions. ## FAQ ### What does the akkadotnet-code-samples repository contain? It holds runnable Akka.NET reference applications for cluster sharding with SQL Server persistence, RabbitMQ backpressure with Akka.Streams.Amqp, event sourcing and CQRS with Akka.Persistence and Akka.Persistence.Query, Autofac integration with Akka.Hosting, a cluster client, and cluster setup with Microsoft .NET Aspire. ### Do the akkadotnet-code-samples teach actor modelling? No. The README states the samples are not designed to teach how to model complex domains with actors. They are built to demonstrate copy-and-pasteable approaches to running Akka.NET infrastructure correctly and succinctly. ### How are package versions managed across the akkadotnet-code-samples? All samples reference the single Directory.Build.props file at the repository root, which determines the Akka.NET, Akka.Hosting, ASP.NET, .NET runtime and Microsoft.Extensions versions, and package versions themselves are centrally managed in the root Directory.Packages.props file rather than hard-coded per project. ### What must a new sample include to be accepted? It must be framed as a self-hosted service relying on Akka.Hosting, have a complete README.md explaining what it does and how to run it, sit in its own solution file organised by folder, and if it needs multiple nodes it should run under Kubernetes or docker compose with .cmd and .sh scripts to set up and tear down the infrastructure. ### What licence applies to the akkadotnet-code-samples code and diagrams? All source code is licensed under Apache 2.0, while the visuals explaining the samples are licensed under Creative Commons Attribution 4.0 International and may be reused in derivative works if you comply with that licence's conditions. ## Sources - [Issues](https://github.com/petabridge/akkadotnet-code-samples/issues) - [License: Apache-2.0](https://github.com/petabridge/akkadotnet-code-samples/blob/master/LICENSE) - [petabridge/akkadotnet-code-samples on GitHub](https://github.com/petabridge/akkadotnet-code-samples) - [Project website](http://petabridge.com/blog) - [README](https://github.com/petabridge/akkadotnet-code-samples/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/petabridge-akkadotnet-code-samples