Support for .NET 10, Blazor WebAssembly, Multi-Project Solutions, and WASM Tools in Dokploy

[sardar97]

What problem will this feature address?

Currently, Dokploy does not fully support modern .NET 10 and Blazor WebAssembly applications. Blazor WASM requires correct handling of static files, fingerprinted assets, Brotli/Gzip compression, and pre-build WASM tools.
Additionally, many .NET developers work with multi-project solutions inside a single GitHub repository (e.g., API + WASM + Shared libraries). Dokploy’s GitHub integration makes it difficult to specify which project inside the solution should be built and deployed, leading to limitations when working with Clean Architecture or multi-project monorepos.
Finally, Blazor WASM requires the wasm-tools workload before building, and there is currently no option in Dokploy to install it before running the build, which causes the build to fail.

Describe the solution you'd like

I would like to request first-class support for modern .NET and Blazor:

1. .NET 10 Support
   • Ability to build and deploy .NET 10 applications directly in Dokploy.

2. Blazor WebAssembly Static Hosting Support
   • Proper hosting of published Blazor WASM output from dotnet publish.
   • Serve fingerprinted/hashed files correctly (app.bundle..js, _framework assets, etc.).
   • Automatic Brotli (.br) and Gzip (.gz) file serving.
   • Correct MIME types for .dll, .wasm, .blat, .dat, .json, etc.
   • SPA fallback routing (index.html fallback).
   • Correct caching headers for Blazor’s immutable assets.

3. Support for Multi-Project .NET Solutions
   • Allow selecting which project inside a GitHub repository should be built and deployed.
   • Useful for solutions containing:
   • API
   • Blazor WASM
   • Background workers
   • Shared libraries
   • A configuration option like “Path to project file” would fully solve this.

4. WASM Tools Installation
   • Add an option to install .NET wasm-tools workload before building:

dotnet workload install wasm-tools

•	This is required for all Blazor WebAssembly builds.

Describe alternatives you've considered

•	Manually editing Dockerfiles to install workloads and configure static file hosting — but this defeats the purpose of using Dokploy’s built-in deployment system.
•	Splitting a multi-project solution into multiple repositories — not practical and breaks common .NET architecture patterns.
•	Using a custom Nginx container for static Blazor hosting — works, but requires too much manual configuration for Brotli/Gzip, routing, MIME types, and is not integrated with Dokploy build pipelines.

Additional context

No response

Will you send a PR to implement it?

No

[djsisson]

Dokploy doesn't have a built in deployment system.

It hands off to a 3rd party like railpack which creates a dockerfile for you, or just direct to docker using your own dockerfile

All of what you want has to and can be done in a dockerfile.

[sardar97]

yeh , i had to use custom docker file , but it would be a solution if we could configure nginx on dokploy and having different command , for example installing wasn-tool before it build the project