# Wexflow: a cross-platform workflow engine for technical jobs > Wexflow is an open source C# workflow automation engine for the kind of work that happens on a server rather than in an office: moving files, running scripts, sending mail, uploading over FTP or SFTP, and scheduling batch processes. It runs on .NET across platforms, ships a visual designer, a REST API and a Docker image, and lets you extend it with custom activities. **aelassas/wexflow** — Workflow Automation Engine - Repository: https://github.com/aelassas/wexflow - Website: https://wexflow.github.io - Stars: 844 · Forks: 190 - Language: C# - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/aelassas-wexflow ## What kind of automation Wexflow is built for Wexflow describes itself as an open-source and cross-platform workflow automation engine supporting a wide range of tasks, from file operations and system processes to scripting, networking and more. The README is precise about who it targets: both developers and technical users who need automation, covering file operations, tasks, scheduling and alerts. The word that keeps appearing is technical. Wexflow focuses on automating technical jobs like moving or uploading files, sending emails, running scripts or scheduling batch processes. For more complex scenarios you can create your own custom activities, install them, and use them to extend its capabilities. That is a narrower claim than most workflow products make, and it is the right one for the tool. A general-purpose automation suite tries to cover a company. Wexflow covers the jobs that run on a server: a file lands in a directory, something picks it up, validates it, moves it somewhere, and notifies a person. The activity list reflects that. More than a hundred built-in activities, six or more database engines, sequential and flowchart workflows, cron-based scheduling, and a visual designer for flows. Two design choices are worth noticing from the feature list. One is push notifications over SSE, giving real-time workflow job updates without polling, which is a small thing that makes a monitoring dashboard feel modern rather than laggy. The other is asynchronous workflow execution, listed as improving concurrency, which is what separates a workflow engine that runs one job at a time from one that can run a batch of them. The project also maintains llms.txt and llms-full.txt files at the repository root, which is the convention for making a documentation set readable by a language model, and it publishes a Docker image to Docker Hub alongside the NuGet package and a wiki. ## Running it with Docker, and the credentials you must change The quick start is a single container, published to Docker Hub as aelassas/wexflow: ```bash docker run -d -p 8000:8000 --name wexflow aelassas/wexflow:latest ``` That gives you the admin panel on port 8000, and the README lists the default login as admin with the password wexflow2018. That default is published in the README, in the Docker Hub image and in the documentation. Whatever else you decide about this tool, change that password the first time you log in. The README itself carries a note to that effect in the section it keeps in the file, even though the visible version has the section collapsed into a comment. The installation path beyond Docker is a wiki with separate pages for installing, getting started, configuration, the REST API reference, the built-in tasks and custom tasks, and a migration guide to v10.0 linked from the header. The migration guide being present in the header is worth a moment's attention. A major version bump in a workflow engine can change activity names, configuration formats or the schema of stored job state, and a project that ships a migration guide at the top of its README is telling you the ten release was not a small increment. If you are on an earlier major, the upgrade is a project rather than a package version bump. The releases listed are Wexflow 10.1 from 2026-09-10, Wexflow 10.0 from 2025-11-13 and Wexflow 9.9 from 2025-09-11, with the last push to the repository on 2026-10-13. So the ten line is about a year old and has had a point release since. ## The feature set: activities, triggers, designer and API The visible feature list is grouped under a workflow engine heading, and the individual capabilities are the ones that decide whether it fits your problem. There is a cross-platform workflow server, support for both sequential and flowchart workflows, and cron-based scheduling. The workflow types matter: sequential covers a pipeline, where each step runs after the last, while flowchart covers branching, and the README lists conditional logic with if and else, switch and while constructs alongside it. The trigger story is the part that determines the shape of the automation. The documentation in the repository compares the trigger types as cron, events and watchers. Cron is the obvious one and every scheduler has it. Events are the workflow being started by something else happening. Watchers are the interesting one, because a watcher notices a change in the filesystem or a database and starts a workflow because of it, which is how the file-processing case actually gets built. Extensibility comes in two forms and the README covers both. Custom activities let you write code against the engine and install it, in C#, and scripts let you run PowerShell, Bash or Python inline as a step. For a team whose processes involve a proprietary system with no API, the custom activity route is the way in. The integration surface is broad: API integrations between systems, database support, and file transfer over FTP and SFTP, alongside the scripting and notification tasks. Six or more database engines are supported, which is more than most workflow tools claim. Around all of that sits the delivery surface: a visual designer for flows, a REST API reference, and the SSE push notifications for job status. ## Where Wexflow sits, and the case where it is the wrong tool The most useful thing in the repository is a comparison table that the maintainers keep in the file but have commented out of the rendered README, and it is honest about the limits. The table sets Wexflow against Zapier, Power Automate, n8n and Apache Airflow, and the row that matters most is the best-for row. Wexflow is for devs and sysadmins, Zapier is for non-technical users, Power Automate is for business users, n8n is for devs and startups, and Airflow is for data engineers. That single row tells you the whole story about the tool's position. Wexflow is in the developer and systems administrator column, next to n8n, and away from the business-user products. It is one of the columns with offline usage marked as a yes along with self-hosting, and one of the few with an execution graph, which the table marks as a flowchart for Wexflow and as DAGs for Airflow. The same commented section addresses the business process management question directly. Wexflow is primarily a workflow automation engine, not a full BPM suite. It does not natively support BPMN, human workflows or built-in user forms. If your business processes require a lot of human interaction, approvals or business rule evaluation, Wexflow would be limited. The positives in that section are equally specific. It excels at automating technical tasks such as moving or transforming files, uploading to FTP and SFTP, running scripts in PowerShell, Bash or Python, scheduling and chaining tasks, triggering workflows by events, manual input, cron or watchers, designing flows visually, integrating with APIs and databases, and supporting conditional logic. The use cases named are back-office automation such as file syncing, reporting and monitoring, ETL pipelines, DevOps and IT operations automation, and API integrations between systems. So the honest summary is that Wexflow is a solid technical-job runner with an extensible activity model, and it is the wrong tool if your process needs a human in the loop. ## Limits: runtime reach, the self-hosted admin surface and the alpha of custom work Several limits follow from the design. The first is the runtime. The project is C# and cross-platform, but cross-platform in .NET still means the set of runtimes and operating systems the .NET version supports, and the samples directory in the repository shows the shape of that spread with samples for clients, for .NET and for .NET Core, plus a WexflowTesting sample. The Docker image removes most of the platform question for server deployment, since that is where the tool is meant to run. The second is the self-hosted admin surface. Wexflow publishes a Docker image and defaults to admin with wexflow2018, and the tool's whole value proposition includes a visual designer and a REST API. That means you are running an authenticated web application that can start arbitrary processes on your machine, because scripting activities execute PowerShell, Bash and Python. Anyone who can reach that admin panel can run code as the service account. The README's note to change the password is therefore not cosmetic, and putting it behind a reverse proxy with TLS and network restrictions is a step worth taking. The third is the extension model. Custom activities mean writing C# against the engine and shipping a binary into it, which is a code deployment rather than a configuration change. The script activities are the lighter alternative, and they work well for anything you can express in a shell script, but they lose the type safety and the structured inputs that an activity gets. The fourth is that a workflow engine's value depends on the activity coverage for your specific systems. A hundred built-in activities cover the common ground well, but the first thing to check is whether the two or three systems your process actually touches are covered, because that is where you will end up writing custom code. The fifth is the major version transition. The presence of a migration guide to v10.0 at the top of the README, and the size of the version numbers relative to their release dates, tell you that upgrades here are not trivial. Plan for it rather than discovering it during an incident. ## Wexflow against n8n and against a plain cron job Two comparisons make the choice clearer. The first is against n8n, which is the closest neighbour in the comparison table, both being self-hosted, developer-oriented and node-based. The difference in approach is the execution model. n8n is fundamentally a webhook-and-integration tool: it starts from HTTP triggers and connects services, and its own table row notes that it uses simple logic rather than an execution graph. Wexflow is built around an execution graph with a visual flowchart designer and conditional branching, with cron, events and watchers as the trigger set. In practice the difference shows up in the jobs that have a shape rather than a connection. A flow that inspects a file, branches on what it finds, calls out to three systems and then notifies a person is a graph, and Wexflow's designer and its branching support are aimed at that. A flow that is really three webhooks chained together is an n8n flow. The second comparison is against a plain cron job, which is the default answer to most of what Wexflow does. A shell script on crontab is free, obvious and entirely adequate for a single scheduled task. The difference in approach is that Wexflow gives you a persistent job record, a visual definition of the flow, retries and a history, a REST API to start things on demand, and a designer that a colleague can read. That history point is the underrated one. When a cron script fails at 3am, you have the mail and the log. When a Wexflow workflow fails, you can look up the instance, see which activity failed, and re-run from there. So the deciding question is whether you have one job or many. One job that runs nightly and succeeds or fails quietly is a cron script and should stay one. A dozen interdependent jobs with branching, retries and someone who needs to see what happened are what a workflow engine is for, and that is where Wexflow's history, designer and API earn their place. ## Conclusion Adopt Wexflow when your automation is technical and system-side, such as file movement, script execution, uploads, notifications or scheduled batch work, and you want something you can self-host and extend with your own activities. Do not adopt it if your processes need human approvals, business rule evaluation or a formal BPMN suite, since the project positions itself as a workflow automation engine rather than a business process suite. Verify first that your platform is supported by the .NET version you pick, that the trigger types you need are among cron, events and watchers, and that you change the default admin password before exposing the panel. ## FAQ ### What is Wexflow and what is it built for? Wexflow is an open source, cross-platform workflow automation engine written in C#, aimed at developers and technical users automating technical jobs such as moving or uploading files, sending emails, running scripts and scheduling batch processes. It supports sequential and flowchart workflows, more than a hundred built-in activities, six or more database engines, cron scheduling, and custom activities you write and install. ### How do I run Wexflow, and what are the default credentials? Run the official Docker image with docker run -d -p 8000:8000 --name wexflow aelassas/wexflow:latest, then open the admin panel at http://localhost:8000. The default username is admin and the default password is wexflow2018, and you should change that password after the first login. ### Is Wexflow a business process management suite? No. The project positions Wexflow as a workflow automation engine rather than a full BPM suite: it does not natively support BPMN, human workflows or built-in user forms, and the project notes that processes needing a lot of human interaction, approvals or business rule evaluation would be limited. It excels at technical tasks such as file movement, FTP and SFTP uploads, scripts, scheduling and API integrations. ## Sources - [aelassas/wexflow on GitHub](https://github.com/aelassas/wexflow) - [License: MIT](https://github.com/aelassas/wexflow/blob/main/LICENSE) - [Project website](https://wexflow.github.io) - [README](https://github.com/aelassas/wexflow/blob/main/README.md) - [Releases](https://github.com/aelassas/wexflow/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aelassas-wexflow