# Elsa Workflows: a .NET workflow engine you host inside your own application

> Elsa 3 runs workflows inside any .NET application, defined in C#, JSON or a visual designer. It suits teams that want orchestration logic in their own process, not a separate platform.

**elsa-workflows/elsa-core** — The Workflow Engine for .NET

- Repository: https://github.com/elsa-workflows/elsa-core
- Website: https://www.elsaworkflows.io
- Stars: 7,894 · Forks: 1,525
- Language: C#
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/elsa-workflows-elsa-core

## The problem Elsa solves for .NET teams

Most workflow engines ask you to run a separate service, deploy it, and talk to it over HTTP. Elsa takes the opposite position: it is a library. The README describes it as "a powerful workflow library that enables workflow execution within any .NET application," with support for .NET 6 and beyond. That single design decision determines who the project is for.

If your team already ships a .NET service and the orchestration logic belongs next to the domain code, Elsa lets you keep it there. Short-running and long-running workflows are both supported, which matters because those two cases usually pull toward different tools. A short workflow might validate an order and send a confirmation. A long-running one might wait days for an approval, survive a process restart, and resume. Elsa treats both as the same programming model.

The cost of this choice is that you own the hosting. There is no vendor running the engine for you, no managed control plane, and no separate operations team. The repository is MIT licensed, so the code is yours to read and modify, but so is the responsibility for persistence, identity and upgrades.

## Three ways to define a workflow, and what each one costs you

Elsa accepts workflow definitions from three sources, and the README lists them plainly: writing C# code, using a visual designer, or specifying workflows in JSON. These are not three skins over one format. They are three authoring paths with different trade-offs.

C# definitions live in your codebase, go through code review, and are versioned with everything else. They are the easiest to test and the hardest for a non-developer to change. JSON definitions can be stored, diffed and moved between environments, which makes them a reasonable fit when workflows change more often than the application does. The visual designer produces those definitions through a browser UI.

The designer is the part to scrutinise. The README's known issues section states that the designer currently only supports Flowchart activities, with Sequence and StateMachine support planned for a future release. It also states that starting workflows from the designer is supported only for workflows that do not require input and do not start with a trigger. So the designer is a real tool, but it is not yet a complete authoring environment for every workflow shape the engine can execute. If your design depends on Sequence or StateMachine activities, you are writing those in C# or JSON for now.

## Running Elsa Studio and Elsa Server with Docker

The fastest way to see the engine and its designer together is the published Docker image, which the README describes as a reference ASP.NET application hosting both the workflow server and the designer. Pull it and run it with the environment variables the README gives:

```bash
docker pull elsaworkflows/elsa-server-and-studio-v3:latest
docker run -t -i -e ASPNETCORE_ENVIRONMENT='Development' -e HTTP_PORTS=8080 -e HTTP__BASEURL=http://localhost:13000 -p 13000:8080 elsaworkflows/elsa-server-and-studio-v3:latest
```

The container listens on port 8080 internally and is mapped to 13000 on the host. The README states that by default you can reach http://localhost:13000 and log in with the username admin and the password password. Treat that as a development convenience only.

For anything beyond a local trial, the README is explicit that this image is not intended for production use. It also says that for any non-development deployment you should inject a secure random JWT signing key through environment variables or a secrets manager rather than relying on committed appsettings values. For code-first hosts such as Elsa.Server.Web, the key to set is Identity__Tokens__SigningKey. For shell-based hosts, the README gives the shell feature key instead:

```bash
CShells__Shells__Default__Features__Identity__SigningKey
```

That naming difference is worth reading twice. The two host styles do not share one configuration key, so a deployment guide copied from one will not work on the other.

## Certificate trust in the Elsa Docker images

The README states that all Elsa Docker images now ship with the operating system's certificate authority bundle baked in at build time, so calls to public HTTPS endpoints such as https://example.com work without extra configuration. That is a build-time decision, not a startup script.

For a private or corporate CA, the container accepts a mounted certificate bundle referenced through EXTRA_CA_CERT:

```bash
docker run \
  -v /path/to/company-ca.crt:/certs/company-ca.crt:ro \
  -e EXTRA_CA_CERT=/certs/company-ca.crt \
  elsaworkflows/elsa-server-and-studio-v3:latest
```

On startup the container copies the certificate into /usr/local/share/ca-certificates and runs update-ca-certificates, which makes the trust visible to .NET, OpenSSL, curl and other system components. Pointing EXTRA_CA_CERT at a directory containing .crt or .pem files handles multiple certificates.

Where the system trust store cannot be modified, the README offers the standard SSL_CERT_FILE and SSL_CERT_DIR environment variables as an alternative. The README also notes that installing the CA bundle adds roughly 300KB to the Debian-based images, and that no package managers run at container startup. If image size or a strict no-network-at-startup policy is a constraint in your environment, that 300KB and the immutable build-time trust update are the details to weigh.

## Where Elsa is the wrong tool

The README's own limitations list is the honest starting point. Documentation is described as still a work in progress. Input and output are not yet implemented in the Workflow Instance Viewer, which means debugging a running instance gives you less than you might expect from a mature product. UI input validation is not yet implemented either, so the designer will accept things the engine may reject later.

Taken together, those gaps point at a specific mismatch. If your team needs a low-code platform where business analysts build and debug workflows end to end without developer involvement, the current designer is not that. The Flowchart-only activity support, the inability to start input-requiring or trigger-starting workflows from the designer, and the missing instance input/output view all sit on the path a non-developer would walk.

The other case to avoid is treating the Docker image as a deployable product. The README says it is a reference application and not intended for production. Teams that want a managed workflow service with an operations story included are looking at the wrong category of tool, not the wrong implementation of it.

## Elsa compared with a general-purpose orchestrator

The natural alternative for a .NET team is a general-purpose orchestrator such as a container or DAG scheduler. The difference is where the workflow lives and what it is made of.

A DAG scheduler typically runs outside your application and executes tasks as external units, often containers or scripts. The workflow definition describes a graph of those units, and the scheduler owns retries, scheduling and observability. Elsa inverts this. The workflow executes inside your .NET process, and an activity is a unit of code in that process, not a separate deployment. You get direct access to your domain objects and dependency injection, and you give up the isolation and the built-in operational tooling that comes with running tasks elsewhere.

That makes the choice fairly clear. If your steps are HTTP calls, message publishes and database writes that belong to the same application, embedding Elsa avoids a network hop and a second deployment target per step. If your steps are long-running batch jobs that need their own CPU and memory, or if you want the scheduler to be someone else's operational problem, a separate orchestrator fits better. Elsa also supports long-running workflows, so duration alone is not the deciding factor; process isolation and operational ownership are.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-20. The most recent releases listed are 3.8.4 on 2026-09-20, 3.8.2 on 2026-09-15 and 3.8.1 on 2026-09-12. Those dates sit within the 3.8 line, and the spacing between them suggests patch releases arrive often. Frequent patches are convenient for fixes and inconvenient for anyone who pins versions and upgrades on a slow cadence.

The licence is MIT. That permits commercial use and modification, and it places no copyleft obligation on your own code. It also means no warranty and no support contract from the licence itself. The README separates community support channels from enterprise support, so paid support exists as a separate arrangement rather than something the licence provides. This is a description of the licence terms, not legal advice; check your own obligations before shipping.

Upgrade cost is harder to estimate from the repository alone. The README documents a configuration split between code-first hosts and shell-based hosts, which means a hosting-model change is not a drop-in edit. Budget for reading release notes between minor versions rather than assuming patch compatibility across the 3.x line.

## Conclusion

Adopt Elsa if you are a .NET team that wants workflow execution inside your own process and can live with a designer limited to Flowchart activities. Do not adopt it if you need a designer that supports Sequence and StateMachine activities today, or if you need production-ready defaults out of the box: the README states the Docker image is a reference application and not intended for production. Before committing, verify the NuGet package version you will pin, confirm the Identity token signing key configuration for your host type, and check whether the workflow you need can be expressed as a Flowchart.

## FAQ

### What is Elsa Workflows?

Elsa is a workflow library that enables workflow execution within any .NET application, with support for .NET 6 and beyond. Workflows can be defined in C# code, through a visual designer, or as JSON.

### How do I install Elsa Workflows?

The README gives a Docker route for trying Elsa Studio and Elsa Server together, using the elsaworkflows/elsa-server-and-studio-v3 image. As a library it is distributed through NuGet, and the README links the Elsa package on nuget.org.

### Is Elsa Workflows free to use?

The repository is licensed under MIT, which permits commercial use and modification. The README lists community support and enterprise support as separate channels, so paid support is not part of the licence.

### What are some open source workflow engines?

Elsa Workflows is one: it is MIT licensed and executes workflows inside a .NET application. The README positions it as a library rather than a standalone service, which distinguishes it from orchestrators that run tasks outside your process.

## Sources

- [elsa-workflows/elsa-core on GitHub](https://github.com/elsa-workflows/elsa-core)
- [License: MIT](https://github.com/elsa-workflows/elsa-core/blob/main/LICENSE)
- [Project website](https://www.elsaworkflows.io)
- [README](https://github.com/elsa-workflows/elsa-core/blob/main/README.md)
- [Releases](https://github.com/elsa-workflows/elsa-core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/elsa-workflows-elsa-core