1047f1e0b8
- Elsa.Studio.Wasm project (net9.0): WASM shell with Login/Dashboard/Workflows modules,
reads its backend URL from a JS-injected window.getClientConfig() so the same build
can point at any origin without a rebuild.
- Elsa.CustomServer:
- references Elsa.Studio.Wasm as a project so `dotnet publish` emits its wwwroot/
- UseBlazorFrameworkFiles + MapFallbackToPage('/_Host') serve the WASM app + SPA routes
- Pages/_Host.cshtml renders the Studio shell and injects apiUrl at request time
- Bumped Elsa server packages to 3.5.3, Studio packages to 3.7.0 (Studio release train
moved ahead of server; 3.7 Studio is compatible with 3.5 server API)
- Dockerfile: SDK/runtime 9.0, restores both csprojs before copying sources
Elsa Custom Server
Custom Elsa Workflows API server. Extends stock Elsa 3.x with our own activities.
Where activities live
src/Elsa.CustomServer/Activities/*.cs — anything marked [Activity(...)] under this
folder is auto-registered via AddActivitiesFrom<Program>() in Program.cs.
To add a new node type in the Studio designer:
- Drop a new file under
Activities/. - Inherit from
CodeActivity,CodeActivity<T>, orActivityfor triggerable ones. - Rebuild and redeploy — Studio picks it up automatically the next time it fetches the activity descriptors.
Example — see Activities/Shout.cs.
Local run
dotnet run --project src/Elsa.CustomServer
Listens on http://localhost:8080; API root is /elsa/api.
Docker
docker build -t elsa-custom-server .
docker run --rm -p 8080:8080 \
-e Identity__Tokens__SigningKey="$(openssl rand -base64 64)" \
elsa-custom-server
Deployment
Coolify builds this image from the Dockerfile at repo root when the app is created
with build_pack: "dockerfile". The Studio (separate container running the stock
elsaworkflows/elsa-studio-v3 image) needs its BACKEND__URL env var pointed at
this server's /elsa/api.