Server + workers with Docker Compose

Instead of embedding the runtime, run the generic UKBatch.Server as the orchestrator + dashboard and join microservices as workers. The server image is published on GitHub Container Registry (linux/amd64 + linux/arm64):

docker run -p 8080:8080 -e UKBATCH_DEV_AUTH=true ghcr.io/nspukcode-hub/ukbatch-server:0.1.4-alpha

That single container serves the dashboard at http://localhost:8080/dashboard with in-memory state — enough for a first look. For the full demo topology, build and run the Compose stack from the repo root:

docker compose up --build

This brings up PostgreSQL (host port 5433), RabbitMQ (management UI 15672), the server (dashboard at http://localhost:5070/dashboard), and three sample workers (5170/5180/5190). The server is configured entirely by environment variables:

Variable	Values	Purpose
`UKBATCH_SERVICE_NAME`	string	The server’s own service identity
`UKBATCH_STORAGE`	`inmemory` \| `ef-sqlite` \| `ef-pg`	State backend
`UKBATCH_STORAGE_CONNECTION`	connection string	Required for the EF backends
`UKBATCH_TRANSPORT`	`inprocess` \| `http` \| `rabbitmq`	Cross-service transport
`UKBATCH_ENABLE_DASHBOARD`	`true` \| `false`	Serve the dashboard
`UKBATCH_ALLOW_ANONYMOUS`	`true` \| `false`	Run anonymously — only behind a trusted network or an external auth gateway
`UKBATCH_DEV_AUTH`	`true` \| `false` (default false)	Development-only header auth — never use in production

A worker opts in with UseWorkerMode plus a cross-service transport:

builder.AddUKBatchAspNetCore(b =>
{
    b.AddJob<GenerateInvoiceJob>();          // [Job(Name = "GenerateInvoice")]
    b.UseWorkerMode(w =>
    {
        w.WorkerName = "invoicing";           // routing key — MUST match .OnService("invoicing")
        w.ServerUrl  = "http://ukbatch-server:8080";
    });
});
builder.Services.AddUKBatchRabbitMqTransport();   // a cross-service transport is REQUIRED

Two warnings worth repeating:

WorkerName is the routing key and must match the step’s .OnService("...") exactly (ordinal) — a mismatch is silent.
A worker that registers no cross-service transport fails fast at startup rather than starting unable to receive work.

The server marks a worker offline after 45s without a heartbeat.