Workflow Server by Optimajet · v10.0.0 stable · October 2026 · .NET 8 · Windows, Linux, macOS · Page last updated
The ready-to-run product in the Optimajet workflow family. It targets .NET 8 and starts as one container, with the workflow designer and the admin panel already inside. Your team hosts it and extends it in C#. Everything else calls it over plain HTTP.
Workflow Server is a separate product with its own license, its own release line, and its own site. Downloads, pricing, and support live on workflowserver.io, and every edition is quoted on request.
Optimajet keeps a real Workflow Server running at demo.workflowserver.io. It opens straight into the admin panel with no sign-in, so you can open the schemes, look at running processes, and read the logs.
Workflow Server by Optimajet is a ready-to-run workflow application you deploy into your own infrastructure, as a Docker image or a package. It runs the Workflow Engine library inside, so it executes the same schemes, and your services drive it over HTTP.
A Docker image and your database. You do not create a .NET project, add NuGet packages, or compile anything before the first process runs.
Initial activity
The Workflow API drives processes. The Callback API calls back into your services for actions, conditions, and rules.
Schemes, processes, users, roles, logs, and reports in a browser. There is no console for you to build.
Targets .NET 8, runs cross-platform, and is extended in C# through Code Actions and plugin classes. Everything that calls it speaks HTTP.
It has its own site, its own releases and its own price list. The price is quoted on request, and it is higher than the library.
Version 10.0.0 carries the engine library as its runtime, so it supports the same schemes and the same execution model.
Current activity
The rest of the family works differently. The .NET workflow engine is a development tool you embed and call from C#, and the free product in its family, Workflow Engine Free, lets you evaluate it without talking to anyone. Workflow Engine NEO is still that library, with a ready Workflow Engine HTTP API and full multitenancy added, for teams building their own .NET service. Workflow Server is the service, already built. The Optimajet FAQ sums it up, “Workflow Engine is a development tool. Workflow Server is a ready-to-use product. Workflow Engine is cheaper than Workflow Server.” The full matrix is on the product comparison page.
Both products run the same processes, and both are for .NET teams. The difference is where the engine lives. With Workflow Engine it runs inside your application. With Workflow Server it runs beside your application, as a service anything can call.
Your schemes carry over untouched. The work is in your C#, because it moves out of your assembly and behind an HTTP endpoint.
| What | Workflow Engine | Workflow Server |
|---|---|---|
| Your schemes | Authored in the Workflow Designer | The same schemes, unchanged |
| Actions and conditions | C# in your own assembly, in-process | Callback API endpoints on your service, or a C# plugin class inside the server |
| Authorization rules | An IWorkflowRuleProvider implementation | GetRules, RuleCheck and RuleGet callbacks, or the same interface in a plugin |
| How your app calls it | C# calls on WorkflowRuntime, no network hop | Workflow API over HTTP with a bearer token |
| Where it runs | Inside your application process | Its own container, beside your application |
| Trying it | Install Workflow Engine Free from NuGet | Open the live demo, then ask for a quote |
There is a middle option as well. Workflow Engine NEO gives you a workflow HTTP API that you host inside your own .NET service. The four-product comparison puts every capability side by side.
With most standalone workflow tools, your business logic moves into the tool. Workflow Server works the other way round. You call the Workflow API to drive processes, and it calls your own services back for each action, condition and permission check.
Create a process from a scheme, ask what commands are available right now, execute one, set state, and read history. Since version 9.0.0 the API is protected with OpenID Connect client credentials through OpenIddict; version 9.0.0 removed the older Basic auth and AccessToken mechanisms.
Actions, conditions, and authorization rules can live on your own servers, and you can register several of them in the admin panel. That is what lets Workflow Server fit into a set of microservices you already run. If you would rather keep that code in-process, the same logic can go into a C# plugin class inside the server.
# 1. Get a token. Endpoints are published at
# /.well-known/openid-configuration
curl -X POST https://workflow.example.com/connect/token \
-d "grant_type=client_credentials" \
-d "client_id=$WFS_CLIENT_ID" \
-d "client_secret=$WFS_CLIENT_SECRET"
# {"access_token": "...", "token_type": "Bearer", "expires_in": 3600}
# 2. Start a process for one business object
curl -X POST \
https://workflow.example.com/workflowapi/createinstance/VacationRequest \
-H "Authorization: Bearer $ACCESS_TOKEN"// You register the base URL in the admin panel; Workflow
// Server calls the method names underneath it.
app.post('/callback/ExecuteAction', (req, res) => {
const { processInstance, name, parameter, token } = req.body
if (token !== process.env.WFS_TOKEN) return res.sendStatus(401)
if (name === 'NotifyApprover') {
notifyApprover(processInstance, parameter)
// data carries back the parameters you changed
return res.json({ success: true, data: { notified: true } })
}
res.json({ success: false, error: 'UnknownAction', message: name })
})
// A condition answers with a boolean, same envelope.
app.post('/callback/ExecuteCondition', (req, res) =>
res.json({ success: true, data: needsSecondApproval(req.body) }))The handler is JavaScript here only because it reads shortest. The contract is the same in any language, a JSON body in and the {"success": true, "data": ...} envelope out.
| Callback group | Methods | What it is for |
|---|---|---|
| Actions | GetActions · ExecuteAction | Workflow Server asks your server which actions a scheme may use, then calls one when a process reaches it. Your handler gets the process instance, the action name, its parameter, and a token. |
| Conditions | GetConditions · ExecuteCondition | Branching decisions run as your code. The server asks the question, your service answers true or false, and the process takes the matching transition. |
| Authorization rules | GetRules · RuleCheck · RuleGet | Who may run this command, and which people those are. Both answers come from your own directory or permission model, so your roles never get copied into the workflow product. |
| Notifications and data | ProcessStatusChanged · ProcessActivityChanged · ProcessLogs · GetParameter · SetParameter | Push updates back into your systems when a process idles, finalizes, or moves, and read or write process parameters from outside. |
Full request and response shapes are in the Callback API documentation, and the token flow with code samples is in the Workflow API documentation. Timeout and retry behavior when a callback server is unreachable is not stated in either page, so ask the team before you design around it.
The quickest way in is the official image with your own database next to it. Start it, open the admin panel on port 8077, upload your license key and register your callback servers. Nothing in your own application has to change.
services:
workflowserver:
image: optimajet/workflowserver
ports:
- "8077:8077"
environment:
Provider: postgresql
ConnectionString: "Host=db;Port=5432;Database=workflowserver;Username=postgres;Password=..."
CreateMetadata: "true"
volumes:
- ./logs:/app/wfs/logs
- ./license:/app/wfs/licenseThe image name, port, environment keys and volumes are the documented ones. This file covers the workflow service only, so add your own database service next to it, or use the full docker-compose file and startcontainer.sh script that come with the download.
There is a version without Docker too. The Workflow Server download page ships a package you run under IIS, Nginx, or as a service, with SQL scripts for each database. The official WorkflowEngine.NET-Server NuGet package is v10.0.0.
| Layer | What it needs | Notes |
|---|---|---|
| Runtime | .NET 8.0 | Inside the container already. Only a non-Docker install needs it on the host. |
| Operating system | Windows, Linux, macOS | Cross-platform, including ARM64 for Apple silicon. |
| Machine | 1 core at 1 GHz, 1 GB RAM, 5 GB disk | The documented minimum. The published throughput figures assume 4 GB RAM. |
| Database | MS SQL Server, PostgreSQL, MySQL, Oracle, or MongoDB | Five providers. Workflow Server has no SQLite option, unlike the library. |
| Hosting | Docker, IIS, Nginx, Windows service, shell scripts | Run it as a container, behind a reverse proxy, or as a plain service. |
| License | A key file mounted into the container | Without a key the server processes data in a single thread. |
Workflow Server keeps no state of its own. To handle more traffic you start more instances and point all of them at the same database. There is no cluster protocol to learn.
Any number of Workflow Server instances connect to one database and work as a cluster. Instances can be disconnected and reconnected at any time, and one server is enough to keep the cluster running. Nginx is the recommended load balancer.
With several instances you pick one master to handle all timer events, and set DisableTimeManager to true on the others. Miss this step and the same timer fires on every instance.
Processes that were active when an instance went down can be restored. The recovery procedure is documented and can be customized to match how your business wants interrupted work to resume.
Workflow Server supports multi-tenant applications. You pass a tenant id to the process, and one deployment serves many customers without mixing their data.
Optimajet publishes what one instance does on a typical 4 GB RAM server. About 200 requests per second, an estimated 20 ms per request, and no slowdown up to several million records on default database settings. Use those numbers as a starting point. Throughput depends a lot on how your schemes are built, and bigger volumes need database tuning. SoapUI tests ship with the product, so you can run the same test against your own processes and plan against that figure instead.
One thing to check before you benchmark. An unlicensed Workflow Server runs on a single thread, so an instance without a key tells you nothing about the product.
Every workflow project builds the same parts around the engine, from a place to draw processes to users, roles, logs and a way to move configuration to production. Workflow Server has them all.
The same drag-and-drop HTML5 designer the engine ships, mounted under Workflow, then Manage schemes. Draw a process from scratch or start from a ready-made scheme, and visualize running processes on the canvas.
Create users in the panel, add and edit them through the Workflow API, import them over LDAP, or let an OpenID provider such as Google or Okta create them on first login. Access is role-based.
Developer Mode exports the whole configuration to a zip archive. Keep it in your repository and import it into the next environment instead of setting everything up again by hand.
Log to the console, Visual Studio debug output, a file, the Windows event log or the database. You set the targets and the levels on the Settings page, so there is no config file to edit and redeploy.
The admin panel and the designer are translated into English, French, German, Italian, Portuguese, Spanish, and Turkish. The people approving work are rarely the people who deployed the server.
The live demo server runs Basic, File, Loop, BPMN and Real-Time Tracking, each a toggle on the dashboard. Your own plugin is a C# class implementing IWorkflowActionProvider, IWorkflowRuleProvider or ICustomActivityProvider.
These parts are most of what the higher price buys. The designer is the same component you can embed in your own product with the library. Its capabilities are covered on the Workflow Designer page, and BPMN 2.0 diagrams import through the same route described on the BPMN workflow engine page.
A screen recording from start to finish. An approval scheme is built in the designer and a process runs through it. Then the same process is driven over the HTTP API while the scheme changes. Recorded by Optimajet in 2023, on an earlier release.
More recordings are on the official Optimajet YouTube channel and in the Workflow Server video tutorials.
These are the things teams usually find out three weeks into an evaluation.
Workflow Server runs on your own infrastructure. Optimajet ships the Docker image and the package. The database, the secrets, the backups, the monitoring and the upgrades stay with your team, which is worth saying out loud before a procurement meeting.
Workflow Server has no free version and no public price list. The editions are Company and Enterprise for internal use, and Ultimate for commercial and SaaS use, sold as either a perpetual or a subscription license. The free option in the family is Workflow Engine Free, which is the library you embed rather than this application.
Without a license key, Workflow Server runs single-threaded. That is enough to open the admin panel and click through a scheme. It tells you nothing about throughput, so get a key before you benchmark anything.
The Workflow API is protected with OpenID Connect client credentials since version 9.0.0, and the admin panel manages users, roles and LDAP import. Deploy Workflow Server in a DMZ or behind a firewall, and keep the admin panel off the public internet.
Workflow Server is at 10.0.0 and carries Workflow Engine 22.1.0 inside it. The two products publish separate release notes, so an engine version number tells you nothing about which server release you are running.
Workflow Server supports five database providers, one fewer than the library, because SQLite is not among them. There is no file-database shortcut for a local install, so point it at a real database from the first run.
Direct answers to what teams ask while deciding between Workflow Server and the embeddable engine. APIs, databases, scaling, versions, and how it is licensed.
Workflow Server by Optimajet is a ready-to-run workflow application you deploy into your own infrastructure. It ships as a Docker image and as a downloadable package, comes with an admin panel and a drag-and-drop workflow designer, and is driven over HTTP by two APIs. Inside it runs the Workflow Engine library, so it executes the same schemes. The current release is 10.0.0 (October 2026).
Workflow Engine is a .NET library you put inside your own application and call from C#. Workflow Server is a finished .NET application you install and run, and call over HTTP. The Optimajet FAQ says it plainly: "Workflow Engine is a development tool. Workflow Server is a ready-to-use product. Workflow Engine is cheaper than Workflow Server. Workflow Server is built on top of Workflow Engine."
You need .NET to run it and to extend it. You do not need .NET to call it. The current Workflow Server package targets .NET 8, and everything you add to it is C#: Code Actions, plugin classes, and the Visual Studio solution that ships with the package. The code that calls it is a separate matter, because the contract is HTTP with JSON bodies. The documentation names Node.js, PHP, Ruby, Java and .NET as client stacks. In practice the teams that buy it are .NET teams who want the workflow service ready-made and callable from every other service they run.
With OpenID Connect client credentials. Since version 9.0.0 Workflow Server uses OpenIddict for token-based authentication. You register client credentials in config.json or through WorkflowServerRuntime.RegisterOpenIdConnectClientCredentials, read the endpoints from /.well-known/openid-configuration, POST client_id, client_secret and grant_type=client_credentials to /connect/token, then send the token as an Authorization: Bearer header. Version 9.0.0 removed the older Basic auth and AccessToken mechanisms.
It lets the code behind Actions, Conditions and Authorization Rules stay on your own servers. Workflow Server calls out to them over GET and POST for GetActions, ExecuteAction, GetConditions, ExecuteCondition, GetRules, RuleCheck and RuleGet, and sends notifications such as ProcessStatusChanged, ProcessActivityChanged and ProcessLogs. You register several callback servers in the admin panel, which is how Workflow Server fits into a set of microservices. The other route is a C# plugin class inside the server, which keeps that code in-process.
Five: Microsoft SQL Server, PostgreSQL, MySQL, Oracle and MongoDB. That is one fewer than the Workflow Engine library, which also has a SQLite provider. Workflow Server has no SQLite option, so a development install still needs one of the five.
Yes. Workflow Server is a stateless server, so any number of instances can connect to a single database and share it as a cluster. Instances can be disconnected and reconnected at any time, and one server is enough to keep the cluster working. The documentation advises Nginx for load balancing. In a multi-server deployment you pick one master to handle all timer events and set DisableTimeManager to true on the others.
Yes. Workflow Server runs on Workflow Engine and supports all of its functions, so the scheme format is the same. A scheme drawn in the Workflow Designer runs in either product. What changes on a move is where your code lives. C# actions and an IWorkflowRuleProvider implementation become Callback API endpoints, or a plugin class inside the server.
No. Workflow Server has no free version. The free option in the Optimajet family is Workflow Engine Free, the free product of the .NET library you embed. One more thing worth knowing: without a license key Workflow Server runs on a single thread, so an unlicensed instance is no guide to how fast it goes.
Workflow Server is quoted on request. The editions are Company and Enterprise for internal use, and Ultimate as a perpetual or subscription license for commercial and SaaS use, with support and update plans priced as a percentage of the license fee. Pricing, downloads and product documentation live on workflowserver.io, which is the buying surface. Workflow Engine is the cheaper of the two products.
Workflow Server 10.0.0, released October 2026, carrying Workflow Engine 22.1.0 inside it. Workflow Server has its own release line and its own release notes, so its version number does not track the Workflow Engine version. Reading engine release notes as server release notes is a common mistake.
Workflow Server is a finished product, so you evaluate it by running it. The documentation and the Docker guide get you a working admin panel on your own infrastructure. A meeting covers licensing, topology, and whether the library would suit you better.
01Documentation
What the product is, how the two APIs fit together, what it needs to run, and the performance to expect. Workflow Server has its own documentation site.
02Deploy
Pull optimajet/workflowserver, point it at MS SQL Server, PostgreSQL, MySQL, Oracle or MongoDB, and open the admin panel on port 8077. The download page also ships a package for IIS, Nginx, and Windows or Linux hosting.
03Book a demo
An hour with the team. Which product fits your stack, how to lay out multiple servers and tenants, how your services connect through the Callback API, and a quote for the tier you need.
