Finbuckle version numbers now match .NET, and the licence has a revenue clause

Three capabilities stacked on tenant resolution

Finbuckle.MultiTenant is described in one line as enabling tenant resolution, per-tenant app behaviour and per-tenant data isolation. That is the whole scope, and each part is documented separately.

Tenant resolution is the base layer: identifying which tenant a request belongs to. Everything else assumes a resolved tenant is in scope.

Per-tenant options means configuration that varies by tenant without redeploying. The README links a dedicated page for per-tenant options as one of the features built on top of basic multi-tenant functionality, alongside per-tenant authentication, so a tenant's authentication scheme can differ from the application's default.

Per-tenant data isolation is the EF Core story, with a separate documentation page for EF Core isolation and another for ASP.NET Core Identity data isolation.

The library's stated design goal is to follow standard.NET conventions as much as possible, which is a claim about ergonomics: if you already write ASP.NET Core middleware and options patterns, the shape should be familiar. The Quick Start is not in the README at all, it points at the Getting Started page on the vendor documentation site, so the first-run experience lives outside the repository.

One package version per .NET major version, maintained in parallel

The versioning policy is the clearest thing in the README and it changes how you plan upgrades.

From MultiTenant v10 onward, major version releases align with.NET major version releases. The current release supports.NET 10, and the guidance is explicit: in general, target the MultiTenant version that matches your.NET version.

That produces three maintained lines, visible in the release tags on the same day. v10.1.4 was released on 2026-09-10, v9.4.13 on 2026-09-10 and v8.1.18 on 2026-09-10. Three lines, one release day, which is what parallel maintenance looks like in practice.

The maintenance policy is spelled out too: new development focuses on the latest MultiTenant release, while critical security and severe bug fixes are released for prior versions that target.NET versions Microsoft still supports. The tail is decided by Microsoft's support window, not by the library.

The consequence for a team is that upgrading.NET and upgrading MultiTenant become one decision, and staying on an old line means accepting that you only get critical security and severe bug fixes. For a library sitting in the data isolation path of a product, that is the right default.

The maintenance fee sits on top of Apache 2.0

This is the part that deserves a lawyer rather than a skim, and it is unusual enough to lead with.

The project states that the source code is freely available under the terms of the LICENSE, which is Apache 2.0. It then states that this project participates in the Open Source Maintenance Fee, effective November 10th, 20026 as written in the README, and that use of the project's official releases in revenue-generating activities requires adherence to the Open Source Maintenance Fee terms in OSMFEULA.txt.

In short, as the README puts it: if you use the project as part of generating revenue, the Maintenance Fee applies, and the fee directly supports the people maintaining the project. Payment is arranged by becoming a sponsor on GitHub.

So the Apache 2.0 grant and the fee are two documents, and the second one adds conditions to commercial use of the official releases. The precise interaction between them, and what counts as revenue-generating, is defined in a EULA rather than in the licence, which is precisely why the two files should both be read before you adopt the package in a commercial product.

Additional support is credited to DigitalOcean, GitHub and JetBrains, which is context for who pays for the maintenance that keeps three version lines alive.

Building it, and running its tests

Working on the library itself needs the standard .NET toolchain. Clone and build:

git clone https://github.com/Finbuckle/Finbuckle.MultiTenant.git
cd Finbuckle.MultiTenant
dotnet build

The test suite runs from the solution directory:

dotnet test

The solution file is Finbuckle.MultiTenant.slnx, the newer XML-based format, and the repository also carries AGENTS.md, CONTRIBUTING.md, a code of conduct based on the Contributor Covenant, SECURITY.md, FUNDING.yml, docs/, samples/, src/ and test/.

Samples are the fastest way to see the intended usage before you commit to the architecture. The repository carries samples/IdentityAppSample/ and samples/WebApiSample/, which between them cover the two documentation areas most teams need: Identity data isolation and a plain web API with tenant resolution.

CI status is published as a badge for the ci.yml workflow, and the release notes for each version are generated into the README, with a pointer to CHANGELOG.md for the full history. The visible v10.1.3 notes show the level of detail: dependency updates, a fix ensuring a created service scope gets disposed, and a refactor adding a typed IsMultiTenant for per-tenant EF Core functionality. Those are the kinds of fixes that tell you the library is iterated on at the level of API shape, not only patches.

Where it stops, and the EF Core constraint that follows

Multi-tenancy is a cross-cutting concern and Finbuckle's scope is deliberately the ASP.NET Core and EF Core path only.

There is no story for non-web hosts. Tenant resolution happens in the HTTP pipeline, so a background worker or a queue consumer has no request to resolve a tenant from, and nothing in the documentation describes how that case is handled. In a product with scheduled jobs, that is a design question you answer yourself.

Data isolation is likewise scoped. The EF Core and Identity pages describe per-tenant data isolation inside EF Core, which means isolation follows the DbContext and the query filter path. Anything that bypasses EF Core, raw SQL against a shared schema, or a reporting replica, is outside that guarantee. Whether isolation is implemented as separate schemas or separate databases, and how existing data is partitioned into it, is not summarised in the README.

Version pressure is the other honest limit. Aligning major versions with.NET is good practice, but it means a.NET 8 application that cannot move to.NET 10 stays on the 8.x line and receives critical security and severe bug fixes. Given the library sits in the tenant isolation path, that is a schedule item rather than a blocker.

The alternative approach to weigh is doing it yourself with a tenant resolution middleware, an EF Core global query filter and a per-tenant options pattern. That is a few hundred lines you own outright, with no licence question attached.

Editorial conclusion

Finbuckle suits a SaaS team on ASP.NET Core that wants tenant resolution, per-tenant options and Identity isolation delivered as a library rather than hand-rolled middleware, and that can match its package version to its .NET version. It is a poor fit for a revenue-generating product that will not accept a maintenance fee, since the project requires adherence to the Open Source Maintenance Fee terms when official releases are used commercially. Verify first which .NET major version you target and take the matching MultiTenant line, then read OSMFEULA.txt against the Apache 2.0 LICENSE before you put it in a product.

Frequently asked questions

Official sources

1. Finbuckle/Finbuckle.MultiTenant on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases