- DEMO: Coming soon
- Release-driven Fedora deployment workflow
- Add badges
Dahln.Stack is am Opinionated .NET 10 + React starter template using a decoupled proxy architecture. The API and frontend run as independent processes during development and are deployed as separate applications behind Nginx in production.
With the latest updates, I have decided to refocus this template project on React. Working with Blazor WASM is fun, and I'm passionate about Blazor. However, over the past 2 years the only Blazor work I have done has been my own 'passion projects', and even some of those projects are now in React. I'm rebranding the project to 'Dahln.Stack', emphasizing that this is my preferred stack choice, at the moment. This rename will make future technology pivots more fluid. I have branched the current Blazor version and will keep that, and other archived branches, as a reference. Until recently my changes have been in another branch, and in order to finish the template restructuring I must now bring them into the master branch - your patience is appreciated while I finalize my current changes.
Dahln.Stack.API: ASP.NET Core Web API, controllers, and Identity endpointsDahln.Stack.App: React + Vite frontendDahln.Stack.Service: business logic and database orchestrationDahln.Stack.Database: EF Core DbContext, entities, and migrationsDahln.Stack.Dto: shared DTOs and enumsDahln.Stack.Test: unit tests for service logic
- .NET 10
- ASP.NET Core Web API
- React + Vite
- ASP.NET Core Identity with cookie auth and 2FA support
- Entity Framework Core + SQLite
- Bootstrap + Bootstrap Icons
- Scalar/OpenAPI in development
Two terminals are required.
dotnet run --project Dahln.Stack.API\Dahln.Stack.API.csproj --launch-profile https
API runs at: https://localhost:7001
Scalar API docs (dev only): https://localhost:7001/scalar
cd Dahln.Stack.App
npm install # first time only
npm run dev
Frontend runs at: https://localhost:5173
All /api/* requests from the frontend are proxied to https://localhost:7001 by Vite - no CORS configuration needed.
dotnet dev-certs https --trust
Navigate to https://localhost:5173
The SQLite database is created and migrations are applied automatically on first API startup.
Authentication uses ASP.NET Core Identity and stores user data in your database.
SMTP2GO is optional but recommended if you want email-driven flows such as:
- email confirmation
- password recovery
- email/username changes
Without SMTP configuration, the application still runs, but email-dependent account flows are limited.
Run these from the solution root:
dotnet ef migrations add InitialCreate --project Dahln.Stack.Database --startup-project Dahln.Stack.API
dotnet ef database update --project Dahln.Stack.Database --startup-project Dahln.Stack.API
If you want to keep local configuration changes out of git:
git update-index --assume-unchanged .\Dahln.Stack.API\appsettings.json
To reverse it:
git update-index --no-assume-unchanged .\Dahln.Stack.API\appsettings.json
Deployment runs through the Deployment.yml GitHub Actions workflow. It deploys automatically when a GitHub Release is published, and it also runs after Build and Release Packages completes successfully. You can still run it manually with workflow_dispatch: provide a release_tag to deploy a specific release, or leave release_tag empty to deploy the latest release.
The workflow targets Fedora x64, downloads the release assets on the GitHub runner with the built-in GITHUB_TOKEN, uploads the packages to the server over SSH, and configures the server in place. No GitHub login or token is left on the server.
Before the first deployment:
- Create the Fedora server.
- Point your DNS record at the server IP and allow it to propagate.
- Configure these repository secrets:
SERVERADDRESSSERVERPORTSERVERUSERNAMESERVERKEYAPPLICATIONDOMAINAPPLICATIONNAMEAPPLICATIONUSERAPPLICATIONAPIPORT
The workflow derives the rest from APPLICATIONNAME and the standard deployment layout:
- Deploy root:
/opt/${APPLICATIONNAME,,} - API deploy path:
/opt/${APPLICATIONNAME,,}/api - App deploy path:
/opt/${APPLICATIONNAME,,}/app - systemd service:
kestrel-${APPLICATIONNAME,,} - Nginx site name:
${APPLICATIONNAME,,} - API executable:
${APPLICATIONNAME}.API - API release asset:
${APPLICATIONNAME}.API-{tag}-linux-x64.zip - App release asset:
${APPLICATIONNAME}.App-{tag}.zip - API route prefix:
/api
The deployment workflow then:
- updates Fedora packages with
dnf - installs the required dependencies from the former Fedora installer
- configures
firewalld - creates the application system user when missing
- deploys the API and app packages with
rsync - verifies that
index.htmlexists after app deployment - creates or updates the systemd service
- creates or updates the Nginx site configuration
- enables SELinux proxy access for Nginx and labels the static app files for Nginx access
- provisions a Let's Encrypt certificate the first time
APPLICATIONDOMAINis set and SSL is not already configured
Subsequent releases update the deployed files and restart the service stack. Certificate setup is skipped after SSL is already configured.
The SSH user must be root or have passwordless sudo, because the workflow installs packages and writes system files non-interactively.
This project uses the Unlicense. See LICENSE for the full text.