Repository navigation
DashboardDocker
The DotNetWorkQueue Dashboard is available as a pre-built Docker image that runs the API and Blazor Server UI in a single self-contained process. You do not need a separate API deployment.
| Property | Value |
|---|---|
| Image | blehnen74/dotnetworkqueue-dashboard |
| Base | mcr.microsoft.com/dotnet/aspnet:10.0 |
| Port |
8080 (HTTP) |
Quick start:
docker run -p 8080:8080 blehnen74/dotnetworkqueue-dashboardThen open http://localhost:8080 in your browser.
The Docker image runs DotNetWorkQueue.Dashboard.Ui.dll, which hosts both the REST API endpoints and the Blazor Server UI inside a single ASP.NET Core process. You do not need to deploy the API separately when using the Docker image.
The dashboard automatically registers the in-process API as a "Local" source. The UI resolves the actual listen address at startup via IServer, so you do not need to add a DashboardApi:Sources entry for the local API. To customize the display name, set DashboardApi:LocalSourceName in your config (the default is "Local").
You can add more remote sources next to the auto-registered local source. See Multi-Source below.
The ASPNETCORE_URLS environment variable sets the port. In the image, it defaults to http://+:8080.
The dashboard reads configuration from a Dashboard section in your appsettings.json. The IConfiguration overload AddDotNetWorkQueueDashboard(IServiceCollection, IConfiguration) binds this section automatically.
Example appsettings.json:
{
"Dashboard": {
"EnableSwagger": true,
"ApiKey": "",
"AssemblyPaths": ["/app/plugins"],
"Connections": [
{
"Transport": "SqlServer",
"ConnectionString": "Server=myserver;Database=mydb;User Id=sa;Password=secret;",
"DisplayName": "Production SQL",
"Queues": ["orders", "notifications"]
}
]
}
}| Property | Type | Description |
|---|---|---|
Transport |
string |
Transport name. Valid values: SqlServer, PostgreSql, SQLite, LiteDb, Redis
|
ConnectionString |
string |
Connection string for the transport |
DisplayName |
string |
Optional label shown in the UI (defaults to transport name) |
Queues |
string[] |
Queue names to display |
| Property | Type | Default | Description |
|---|---|---|---|
EnableSwagger |
bool |
true |
Enables the Swagger UI at /swagger
|
ApiKey |
string |
"" |
If set, all API requests require X-Api-Key: <value> header |
AssemblyPaths |
string[] |
[] |
Paths scanned for plugin assemblies at startup |
Mount a custom config file:
docker run \
-v ./appsettings.json:/app/appsettings.json \
-p 8080:8080 \
blehnen74/dotnetworkqueue-dashboardThe dashboard deserializes message bodies for display in the UI. To show the actual content of your messages, it needs the POCO type assemblies that your producers used to create them.
The official Docker image creates /app/plugins by default. At startup, the dashboard loads the assemblies in that directory with Assembly.LoadFrom(). Then it can deserialize any types that they define.
Volume mount (for local DLLs):
docker run \
-v ./my-types:/app/plugins \
-p 8080:8080 \
blehnen74/dotnetworkqueue-dashboardAlternative (extend the image):
FROM blehnen74/dotnetworkqueue-dashboard
COPY ./publish/MyApp.Contracts.dll /app/plugins/DashboardOptions.AssemblyPaths (or Dashboard:AssemblyPaths in JSON) controls which directories the dashboard scans. The base image sets the /app/plugins default.
The auto-registered "Local" source covers the in-process API. To also monitor remote Dashboard API instances, add them to DashboardApi:Sources in your appsettings.json:
{
"Dashboard": {
"EnableSwagger": true,
"Connections": [ ... ]
},
"DashboardApi": {
"Sources": [
{
"Name": "Remote Production",
"BaseUrl": "https://dashboard-api.prod.example.com",
"ApiKey": "prod-key"
}
]
}
}The dashboard adds the local source automatically, so it does not need to appear in the Sources array. The home page shows both "Local" and any configured remote sources in collapsible panels with health status.
See Dashboard UI: Multi-Source for URL routing and health monitoring details.
Note: The container serves HTTP on port 8080. For production deployments, put the container behind a reverse proxy (nginx, Traefik, Caddy, etc.) that terminates HTTPS.
- Set
Dashboard:ApiKeyto require an API key on all requests. See DashboardConfiguration for details. - For the Blazor UI authentication options, see DashboardUi.
- For a working Docker Compose example, see DotNetWorkQueue.Samples.
The official Docker image includes libsqlite3-0 and a libdl.so symlink required for System.Data.SQLite.Core compatibility on Linux. The image handles this automatically, so you do not need to do anything. If you build a custom image, add these packages in your Dockerfile:
RUN apt-get update && apt-get install -y libsqlite3-0 && \
ln -s /usr/lib/x86_64-linux-gnu/libdl.so.2 /usr/lib/x86_64-linux-gnu/libdl.soFor any issues please use the GitHub issues