FullStackHero: The Free, Open-Source .NET 10 Starter Kit

FullStackHero is a free, MIT-licensed .NET 10 starter kit for building multi-tenant SaaS and enterprise APIs. It is a modular monolith built with Vertical Slice Architecture that ships ten production modules - identity, multitenancy, billing, and more - plus two React frontends and one-command local orchestration. You get the full source, with no black-box NuGet runtime, so you own and can change everything. The point is simple: start on feature work, not plumbing.

I started FullStackHero back in 2021 because I was tired of rebuilding the same scaffolding on every new project. Auth, multitenancy, caching, jobs, file storage, API docs - the unglamorous 80% that every serious app needs before it does anything interesting. Over the years it grew into one of the more popular .NET starter kits on GitHub, sitting at around 6,400 stars.

The v10 release is a ground-up rebuild on .NET 10. This is not a version bump on the old code. The original FullStackHero was two separate repositories - a .NET 6 Clean Architecture Web API and a Blazor WebAssembly client. v10 collapses that into a single, cohesive modular monolith with two React apps, and rethinks how the whole thing fits together.

Here is the part that should make you sit up. You clone it, run one command, and a full multi-tenant SaaS is live on your machine: authentication, billing, real-time chat, file storage, two React apps, and interactive API docs, all wired together and seeded with demo data. No setup ritual, no config scavenger hunt. That is the experience I always wanted from a starter kit, and v10 finally delivers it. This article is the full tour: what it is, how it is built, the stack, the architecture, and how to run it yourself.

What Is FullStackHero?

FullStackHero is a copy-and-own starter kit, not a framework. When you scaffold a project, the entire source lands in your repository. There is no FullStackHero.Core NuGet package sitting between you and the runtime, no abstraction you cannot step into. If you do not like how multitenancy resolves, or how the outbox dispatches events, you open the file and change it. That is the whole philosophy.

It is aimed at teams that want to ship features on day one instead of spending the first sprint wiring identity, tenancy, auditing, caching, jobs, storage, observability, and API docs. Those decisions are already made, wired, and tested. You inherit a working, opinionated foundation and spend your time on the parts that are actually your product.

Concretely, that is ten production modules and eleven shared building blocks, wired into one deployable process and backed by more than 1,600 backend tests and 200+ end-to-end tests. It is the foundation that normally eats the first month of a new SaaS project, done and waiting for you.

It is genuinely free. MIT licensed, community driven, and developed in the open on GitHub. The full documentation lives at fullstackhero.net.

What’s New in v10

If you used the old FullStackHero, almost everything has changed. Here is the before and after:

The stable 10.0.0 release shipped on 2026-05-28, and as of 2026-06-20 the fsh CLI and the dotnet new template are both live on NuGet as stable 10.0.0. You can read the full history on the changelog.

The Stack

FullStackHero is deliberately built on mainstream, well-supported libraries - the ones you would reach for anyway. Nothing exotic, nothing you have to learn before you can read the code.

Both frontends are React 19 + Vite 7 + TypeScript, with TanStack Query v5, Tailwind v4, and SignalR/SSE for realtime. Testing leans on xUnit, Shouldly, NSubstitute, and Testcontainers for integration, with NetArchTest enforcing module boundaries.

Most of these I have written about on this blog already: Minimal APIs, HybridCache, JWT authentication, CQRS with Mediator, FluentValidation, rate limiting, and Scalar over Swagger. FullStackHero is, in a real sense, all of those articles assembled into one production codebase.

The Architecture: Modular Monolith + Vertical Slice

This is the heart of v10. FullStackHero is a modular monolith: ten modules live in one repository, build one set of containers, and deploy as one process. Each module is a bounded context with its own DbContext, its own feature folders, and a single one-way dependency channel through which the rest of the kit talks to it.

The boundary rule

Modules talk to each other only through their *.Contracts assemblies. A contracts project is a thin layer of commands, queries, events, and DTOs - the module’s public surface. The cardinal rule is that runtime modules never reference each other. If module A needs something from module B, it asks B’s contracts.

These are not conventions you have to remember. They are enforced by NetArchTest rules in src/Tests/Architecture.Tests. Break a boundary and the test suite goes red. That is the difference between an architecture you hope holds and one that actually does.

How modules talk

Cross-module communication is one-way and contract-only, in three patterns:

1. Service interfaces - some contracts expose interfaces like ITokenService that downstream modules resolve via dependency injection without referencing the runtime.
2. Domain events - private to a module’s aggregate, dispatched through Mediator after SaveChanges.
3. Integration events - the canonical cross-module pattern. A module writes an event to the outbox in the same transaction as its business write; the dispatcher publishes it asynchronously; any module implementing the handler receives a copy, with inbox-backed idempotency.

The receiver does not know the producer, and the producer does not know the receivers. When a module eventually needs to scale out, those same contract boundaries become the extraction seam - swap in-process Mediator and the in-memory event bus for HTTP or RabbitMQ, and consumers do not change. You do not have to commit to microservices on day one, and you do not get punished for it later. If you want the deeper trade-off, I wrote a whole piece on Clean Architecture in .NET 10 that pairs well with this mental model.

The Ten Modules

Every module is a ready-to-ship bounded context, not a stub. Read one as a worked example of how a feature should look, then build your own beside it.

Each module follows the same internal shape - a feature is one vertical slice. For registering a user in the Identity module, the slice is a single folder: the Minimal API endpoint, the Mediator handler, and the FluentValidation validator, sitting next to each other. No three-layer round trip to add an endpoint. You can read the per-module deep dives in the modules docs.

Cross-Cutting Concerns You Don’t Have to Build

This is where a starter kit earns its keep. Every one of these is wired, tenant-aware, and tested out of the box:

• Caching - HybridCache over Valkey with tenant-scoped invalidation.
• Background jobs - Hangfire with the tenant context preserved into the job.
• Idempotency - send an Idempotency-Key header and the kit replays the cached response.
• Feature flags - Microsoft.FeatureManagement with per-tenant overrides.
• Quotas - per-tenant request and resource limits.
• Rate limiting - built into the host pipeline.
• HTTP resilience - Polly v8 retry and circuit-breaker policies on outbound calls.
• Observability - OpenTelemetry traces, metrics, and logs plus Serilog structured logging and health checks.
• Error handling - a global exception handler that returns RFC 9457 ProblemDetails.
• Realtime - SignalR hubs with a Valkey backplane, plus Server-Sent Events for one-way streaming.

The composition root keeps all of this readable. Program.cs wires the platform in three calls - register the mediator, add the platform building blocks with feature toggles, then add the modules. The API never mutates the database on startup; migrations and demo seeding run through a dedicated DbMigrator.

A Tour of the Two React Frontends

FullStackHero ships two complete React apps in the repo, so you do not reinvent the auth flow, the permission UI, or the audit viewer.

The tenant dashboard is what your end users see. The overview greets each tenant with their plan, validity, recent audits, and a live event feed streaming over SSE.

Chat is real, not a mock. Channels and direct messages deliver live over SignalR, including mentions that push a notification to the recipient.

The Tickets module is a small but complete helpdesk, with a lifecycle, priorities, statuses, and assignment - a worked example of a CRUD-plus-workflow feature.

Security is first-class. Tenant users can set up two-factor authentication, manage active sessions, and control their profile from the dashboard.

The admin console is the operator surface. The overview gives the root operator a view across every tenant on the instance - tenants, plans, invoices, and outstanding balances.

Permissions are granular and editable. The role editor exposes the full permission catalog, grouped by module, and every nav surface in both apps is gated on the exact permission the API enforces.

User management, role assignment, and operator impersonation all live in the admin console too.

Prerequisites

The list is short, and fsh doctor (below) checks all of it for you. You need three things:

• .NET 10 SDK - from dotnet.microsoft.com/download. The repo pins SDK 10.0.100 via global.json, so anything 10.0.100 or newer works. If dotnet --version reports 9.x or older, install .NET 10 before continuing - the kit targets net10.0 and will not build on an earlier SDK.
• Docker - the whole stack runs in containers (Postgres, Valkey, MinIO), so Docker Desktop on Windows or macOS, or Docker Engine on Linux, needs to be running.
• Git - to clone or scaffold the repo.

Optionally, install Node 20+ if you want to run the two React frontends (the API runs fine without it).

One thing worth calling out, because people still ask: there is no separate .NET Aspire workload to install anymore. The AppHost pulls the Aspire SDK from NuGet during restore, so a working .NET 10 SDK plus Docker is genuinely all you need. A quick sanity check:

dotnet --version       # 10.x.x
docker info            # should print server info, not an error
git --version

Quick Install: Running It in One Command

There are four ways to get the kit. The recommended path is the fsh CLI - a dotnet tool that scaffolds a fresh, fully renamed project: it swaps in a unique JWT signing key, generates strong Docker secrets, runs npm install, and makes the first commit.

Start by checking your environment. fsh doctor verifies the .NET 10 SDK, Git, Docker, the installed template, and that the ports it needs are free:

dotnet tool install -g FullStackHero.CLI
fsh doctor

Then scaffold. fsh new is interactive - it asks whether to include the Aspire AppHost and the React apps, then renames everything to your project name:

fsh new MyApp

Prefer no CLI? The dotnet new template does the same thing and is handy for scripted or CI scaffolding. You can also clone the repo as-is, or use the GitHub template and Codespaces for a zero-install dev environment:

# Option 2 - dotnet new template
dotnet new install FullStackHero.NET.StarterKit
dotnet new fsh -n MyApp

# Option 3 - clone the source as-is
git clone https://github.com/fullstackhero/dotnet-starter-kit.git MyApp

The install guide covers all four paths in detail.

The Aspire Tour: The Whole Stack, One Command

Here is the part that genuinely changed how I demo this project. After scaffolding, you run a single command:

dotnet run --project src/Host/MyApp.AppHost

.NET Aspire brings up the entire stack in containers and wires it together - Postgres with pgAdmin, Valkey with RedisInsight, MinIO for object storage, the database migrator, the demo seeder, the API, and both React apps. Connection strings and OTLP export are all injected for you. No docker compose files to babysit, no manual connection-string juggling.

Once everything is green, the API and Scalar docs are at https://localhost:7030/scalar, the admin app at http://localhost:5173, and the dashboard at http://localhost:5174. The demo seeder provisions acme and globex tenants with sample data, so the seeded logins work the moment the apps load - no manual setup to see a populated app.

Built for AI Coding Agents

It is fair to ask why a starter kit matters now that a coding agent can generate an entire backend from a single prompt. It can, and Claude will happily hand you something that compiles, runs, and looks complete. What it will not reliably hand you is the hundred quiet architectural decisions that keep that code clean and scalable six months in: where the module boundaries sit, how tenancy threads through caching and jobs, when to reach for an integration event instead of a direct call, how to keep a feature a single vertical slice instead of a three-layer round trip. That judgment is the gap between a demo that works on Friday and a codebase a team can still move fast in next year.

That is exactly what FullStackHero adds on top of the model. The kit is those decisions, already made by someone who has shipped this shape before, and best industry practice baked into a clean, scalable architecture rather than improvised one prompt at a time. The agent gives you raw speed; the kit gives you the senior-engineer experience to point that speed at, so what you generate lands inside a proven foundation instead of a fresh guess every time.

This is the part I am most excited about, and it ties directly into how I build now. FullStackHero ships agent-ready. The conventions, footguns, and step-by-step recipes that normally live in a senior engineer’s head are written down in a form AI coding tools read on demand - so an agent scaffolds a feature, adds a module, or writes a migration the same way you would, without breaking the architecture.

Two pieces make this work. AGENTS.md is the single, tool-neutral guide at the repo root - CLAUDE.md and GEMINI.md are thin bridges that import it, so every tool reads the same source of truth. And the .agents/ folder holds rules (conventions, read on demand), skills (task recipes), and workflows (review and orchestration playbooks).

It is all plain Markdown keyed off the open AGENTS.md convention, so it works with Claude Code, Gemini CLI, Cursor, and Codex with no vendor lock-in. Point your agent at a FullStackHero repo and it already knows the boundary rules. The full setup is documented under AI-Driven Development.

How FullStackHero Compares to ABP, Clean Architecture, and BlazorPlate

FullStackHero is one of several ways to start a production .NET project. Here is how it lines up against the most common alternatives - ABP Framework, the Jason Taylor and Ardalis Clean Architecture templates, and BlazorPlate.

The honest summary: pick ABP if you want a heavyweight framework with vendor support contracts and an admin-UI generator; pick a Clean Architecture template if you want to learn or assemble the architecture from a clean slate; pick BlazorPlate if you are a Blazor team that wants a paid, finished product with built-in internationalization; pick FullStackHero if you want free, open-source, copy-and-own code with ten production modules and React frontends, and zero lock-in. FullStackHero maintains longer, fact-checked head-to-heads for each of these in the docs.

When to Use FullStackHero (and When Not To)

I will be honest about this, because a starter kit is the wrong tool as often as it is the right one. FullStackHero is opinionated and it ships a lot. That is a feature for some projects and a liability for others.

The short version: pick FullStackHero when the ten modules it ships are roughly the ten modules you were about to build anyway. If you only need one or two of them, the kit is more than you need, and a leaner starting point will serve you better. FullStackHero maintains honest, fact-checked comparisons against ABP Framework, the Clean Architecture templates, and BlazorPlate if you want to weigh the alternatives directly.

Testing and Production-Readiness

A starter kit you cannot trust in production is just a demo. FullStackHero v10 ships with 1,600+ backend tests (xUnit, Testcontainers, and NetArchTest boundary checks) and 200+ Playwright end-to-end tests across both React apps, with path-scoped CI and warnings treated as errors.

On the security side, the kit went through a module-by-module audit before 10.0.0: permission-gated endpoints, HMAC-signed webhooks with secrets encrypted at rest via ASP.NET Data Protection, cross-tenant isolation hardening, deactivated-tenant enforcement, and a production checklist to walk before you ship.

For deployment, you get a Docker Compose stack for self-hosting, a Dokploy config, and AWS Terraform for cloud. Because the API images build cleanly, you can also lean on SDK container publishing if you prefer no Dockerfile. Logging is Serilog plus OpenTelemetry from the first request.

Key Takeaways

• FullStackHero is a free, MIT-licensed .NET 10 starter kit for multi-tenant SaaS and enterprise APIs - copy-and-own source, no black-box runtime.
• v10 is a ground-up rebuild: a single modular monolith with Vertical Slice Architecture, replacing the old two-repo .NET 6 setup.
• Ten production modules and a dozen cross-cutting concerns are wired, tenant-aware, and tested - identity, multitenancy, billing, auditing, webhooks, caching, jobs, observability, and more.
• Two React 19 frontends ship in the repo - an operator admin console and a tenant dashboard.
• One command runs everything via .NET Aspire, and the fsh CLI scaffolds a fully renamed project in seconds.
• It is agent-ready through AGENTS.md and an .agents/ folder. AI can generate a backend, but FullStackHero supplies the architectural decisions and senior-engineer judgment it cannot, so what you generate lands inside a clean, scalable foundation instead of a fresh guess.

Frequently Asked Questions

Get Started

FullStackHero is the foundation I wish I had on every project I have started. v10 is the best version of it by a wide margin, and it is free. The fastest way to feel it is to run it - give it five minutes and watch a whole SaaS come up on your machine.

• Try it: dotnet tool install -g FullStackHero.CLI && fsh new MyApp
• Read the docs: fullstackhero.net
• Browse the source: github.com/fullstackhero/dotnet-starter-kit

Support the Project

FullStackHero is free and MIT licensed, and I plan to keep it that way. But free to use is not free to build. v10 was months of work, and keeping it current - tracking new .NET releases, running security audits, and the AI tooling and Claude usage that now goes into reviewing every module - costs real hours and real money out of my own pocket.

If the kit saves you a sprint of plumbing and you want to give something back, here are a few ways - none of them required, and no pressure either way:

• Star the repo. It is the single biggest signal that keeps the project visible and worth maintaining, and it costs you one click.
• Sponsor on Open Collective. Even a small recurring amount helps cover the tooling, the Claude bills, and the dev hours that keep v10 moving. Every contribution is transparent and goes straight back into the project: opencollective.com/fullstackhero.
• Contribute. Open an issue, fix a bug, sharpen the docs. Pull requests are genuinely welcome.

Honestly, using it, sharing it, and telling one other .NET developer about it already helps more than you would think.

If you want to go deeper on the pieces FullStackHero is built from, start here:

Happy Coding :)