Windmill vs VisualCron: a code-first VisualCron alternative
Eight questions teams ask when they compare job schedulers, with an honest answer on each one for where Windmill or VisualCron is the better pick.
- 01What you can buildWhich solution fits for your specific use case
- 02TargetWho the platform is built for
- 03Build experienceHow you build on each platform
- 04IntegrationsHow the platform integrates with your existing stack
- 05Migration & lock-inHow hard to get in, how hard to get out
- 06Enterprise requirementsDeployment, scaling, monitoring, audit
- 07LicensingOpen source, editions, self-hosting
- 08VerdictThe verdict
An open-source, self-hostable platform where jobs are scripts and workflows written as code, in PowerShell, C#, SQL, Python, TypeScript and other languages, run on Linux workers and, on Self-Hosted Enterprise Edition, on native Windows workers.
VisualCron describes itself as "an automation, integration and task scheduling tool for Windows". Jobs are configured in its Windows Client or Web Client from a library of built-in Task types and started by time and event Triggers, all run by the VisualCron Server, a Windows service.
This page is written by Windmill. Statements about VisualCron come from its own documentation and website and link to them. Feel free to contact us for any correction. If you are moving jobs over, see Migrate from VisualCron.
Which jobs can you build and run?
Both tools run jobs on a schedule or an event, chain steps and act on errors. VisualCron gives you a catalog of configurable Task types, plus a file transfer server and desktop automation in the higher editions. Windmill makes every step a script in the language that suits it, kept in Git, and runs it on Linux or Windows workers from the same queue.
| Primitive | VisualCron | |
|---|---|---|
Run on a cron or interval schedule | ||
Start a run from an HTTP request, an email, a message queue or a database | ||
Chain steps, with actions on error and on success | ||
Built-in task catalog Configurable task types for files, FTP, databases, email, Active Directory and more | Hub scripts | |
Every step is a script with typed inputs and its own dependencies | Code Tasks | |
Jobs run on Windows hosts with their accounts, paths and modules | Enterprise only | |
The server runs on Linux with Docker Compose or Kubernetes | ||
Each job is a file you review in a pull request and deploy from a repository | Settings export | |
Desktop UI automation Drive desktop applications in the session of a logged-on user | Pro edition | |
Managed file transfer server Host SFTP and FTP servers and start a job when a file is received | Advanced and Pro |
VisualCron's order page lists 132 Task types and 20 Trigger types in the Essentials edition and 359 Task types and 37 Trigger types in the Pro edition. The MFT Server comes from the Advanced edition and the Robot Task is in the Pro edition. Windmill has no catalog of configurable task types: steps are scripts you write, or scripts from the Windmill Hub.
On the Windmill side, Windows workers are Self-Hosted Enterprise Enterprise only, and Git sync is on Cloud and Enterprise Self-Hosted, and on Community Edition for workspaces with up to 2 users. See Windows automation for what running on Windows covers.
Who is each platform built for?
VisualCron is built for administrators who want to automate Windows servers by configuring Tasks rather than writing scripts. Windmill is built for teams that want each job to be code: a file in Git, reviewed in a pull request, with a form and an approval step for the people who run it.
Primary audience
Windows administrators who want to automate work on Windows servers without writing code. Each Job is a list of Tasks, and each Task is one of the built-in Task types, configured in a form, covering file transfers, databases, email, Active Directory, cloud services and more.
Reviewing a change
The Client shows versions and an audit log for each Job and Task. Jobs are stored in the Server's settings folder.
How do you build on each platform?
VisualCron builds a Job from forms: pick a Task type, fill in its settings, and drop into a PowerShell, Execute or .NET Code Execute Task when no Task type fits. Windmill builds a job from code: scripts with their own dependencies, chained in a flow, edited locally or in the browser and kept in Git.
The PowerShell script is a normal script with a param block. Windmill reads that block to generate the input form, and the script runs on its own from a schedule, a webhook or another trigger. The flow file references it by path, maps arguments onto it and adds an approval step. Both files sit in Git and are editable in any editor.
- disable_user.ps1
- flow.yaml
# f/windows/disable_user.ps1
param(
[string]$samAccountName,
[string]$reason = "offboarding"
)
Import-Module ActiveDirectory
Disable-ADAccount -Identity $samAccountName
Set-ADUser -Identity $samAccountName -Description "Disabled: $reason"
Get-ADUser -Identity $samAccountName -Properties Enabled, Description |
Select-Object SamAccountName, Enabled, Description |
ConvertTo-Json
summary: Offboard a user
value:
modules:
- id: a
summary: Disable the AD account
value:
type: script
path: f/windows/disable_user
input_transforms:
samAccountName:
type: javascript
expr: flow_input.sam_account_name
reason:
type: static
value: offboarding
- id: b
summary: Confirm before archiving the mailbox
suspend:
required_events: 1
timeout: 86400
value:
type: script
path: f/windows/archive_mailbox
input_transforms:
account:
type: javascript
expr: results.a.SamAccountName
A Job is a list of Tasks, and each Task is one of the built-in Task types, configured in a form in the Windows Client or the Web Client.
Code goes into a Task: the PowerShell Task, the Execute Task for commands and batch files, or the .NET Code Execute Task, which compiles C# or VB.NET for each run.
Jobs and other objects are stored in the Server's settings folder and can be exported to a zip file with Export settings.
Authoring
Scripts in the browser editor or locally with VS Code and the CLI. The flow editor chains scripts. Windmill AI writes and edits scripts and flows in the editor, and the CLI installs skills for coding agents such as Claude Code, Codex and Cursor.
Jobs and Tasks are configured in the Windows Client or the Web Client, which runs in IIS.
Custom code
Every step is code: PowerShell, C#, SQL, Python, TypeScript, Bash and other languages. Dependencies are resolved from each script's imports, including NuGet packages for C# and PowerShell modules, and pinned in a lockfile when the script is saved.
The PowerShell Task, the Execute Task for commands and batch files, and the .NET Code Execute Task, which compiles C# or VB.NET for each run.
Flow control
Branches, for loops, retries, error handlers, approval steps and sleep in the flow editor.
Job and Task Flow actions on start, error, success, completion and running longer than a set time, such as running another Job or sending a Notification.
Where jobs run
On workers that pull jobs from a queue: Linux workers by default, Windows workers running as a Windows service Enterprise only, and agent workers that only need an HTTP connection to the server Enterprise only. Worker tags route each script or flow to the workers that should run it.
On the VisualCron Server, as the service account or as a stored Credential. The Remote Execute Task starts a process on another computer through WMI, without capturing its output.
Credentials & connections
Connection details live in resources and secrets in variables, encrypted with a workspace-specific key. A job runs as the account its worker runs as; for SQL Server, Windows integrated authentication uses that account. MS SQL scripts need Enterprise Edition or Cloud.
Credentials store a Windows user name, password and domain, encrypted, so Tasks can run or connect as that user. Connections store the address and sign-in for other systems.
Git & change history
Jobs and other objects are stored in the Server's settings folder and can be exported to a zip file with Export settings. The Client shows versions and an audit log for each Job and Task.
How does the platform integrate with your existing stack?
VisualCron wins on ready-made Windows events: Event Triggers react to services, the registry, the event log, performance counters, session changes and printers on the Server. In Windmill, that is a scheduled script on a Windows worker that checks the state. Windmill treats code as the integration layer: a step imports the vendor's SDK or calls its API, and every script and flow gets a webhook.
Connecting out
No catalog of configurable task types. Steps are scripts you write, or scripts from the Windmill Hub; for a system without a ready script, a step calls its API or imports its SDK.
Task types for files, FTP and SFTP, databases, email, Active Directory, cloud storage, SharePoint, VMware, SAP and more. The number depends on the edition.
Receiving events
Cron schedules, webhooks, HTTP routes, email, Kafka, NATS, SQS, MQTT, AMQP, Postgres and other triggers (some are self-hosted or Enterprise only). Polling a source such as a folder or a table is a scheduled poll that keeps state between runs.
Time Triggers (Interval or Custom) and Event Triggers for files, remote and cloud files, an incoming HTTP REST request, SQL, mail, Windows services, the registry, the event log, performance counters, message queues and more. Several Triggers can be combined in a dependency.
APIs
A .NET API, used directly or through PowerShell; a REST and SOAP Web API (Advanced edition and up); and the VCCommand.exe command-line tool.
How hard to get in, and how hard to get out?
VisualCron is the quicker start on a single Windows server: one install with an embedded database. Windmill keeps the switching cost low at the other end, since the step code is ordinary code in ordinary files, and you do not have to move every Job at once (see using them together).
Getting in
The migration guide maps Jobs, Tasks and Triggers to Windmill and shows how a coding agent can convert an exported Job. Run the Windmill copy with its schedule disabled until you have compared the results. Windmill needs a server and PostgreSQL, deployed with Docker Compose or Kubernetes, or Windmill Cloud, and Windows machines join as workers.
VisualCron installs on one Windows machine with its own embedded database. The requirements page lists Microsoft-supported Windows Server and Desktop versions and .NET Framework 4.8. No separate database is needed: SQL Server Compact 4.0 is included.
Getting out
Step logic is ordinary code (PowerShell, C#, SQL, Python, TypeScript, Bash) in files you already keep in Git, and the CLI pulls the workspace to a local folder. What you leave behind is the runtime, not the step code.
Export settings saves Jobs and other objects to one zip file. Each Task is a configured instance of a VisualCron Task type, so on another platform it becomes code or that platform's equivalent step.
Deployment, scaling, monitoring and audit
VisualCron is one Windows server with an embedded database, and the Pro edition adds Agent distribution across Servers. Windmill separates stateless servers from workers on PostgreSQL, so you add workers, Linux or Windows, as load grows.
Where the server runs
A server and PostgreSQL, self-hosted with Docker Compose or Kubernetes, or Windmill Cloud. The Windows binary is a worker only and does not include the web interface.
Windows only. The requirements page lists Microsoft-supported Windows Server and Desktop versions and .NET Framework 4.8. No separate database is needed: SQL Server Compact 4.0 is included.
Scaling
Stateless servers and workers sharing PostgreSQL. Workers can be scaled horizontally, and Windows and Linux workers pull from the same queue.
With the Pro edition, Agent distribution runs a Job on Servers connected to a Broker Server, chosen by the load balancer settings Pro.
Monitoring
A Runs page with all past and future runs and their logs.
Job and Task logs in the Client; an internal log database on the Server.
Audit logs
Audit logs for every operation with side effects. Full, unredacted entries are Enterprise only; on the self-hosted Community Edition, entries are redacted or not recorded.
The Client shows versions and an audit log for each Job and Task.
Open source, editions, and self-hosting?
VisualCron is a commercial product licensed per server, and the edition decides which Task types, Triggers and server features you get. Windmill's core is open source and free to self-host, with Enterprise features such as native Windows workers behind a license priced by seats and compute units.
Source model
Open source, with an AGPLv3 core on GitHub. The Community Edition is free to self-host; features marked Enterprise in the docs need an Enterprise license and ship in a separate proprietary codebase. Paid plans are priced by seats and compute units on the pricing page.
Commercial, licensed per server as an annual subscription in Essentials, Advanced and Pro editions (order page).
What the editions change
Windows workers are Self-Hosted Enterprise, agent workers are Enterprise (Cloud or self-hosted), full, unredacted audit logs need Enterprise Edition, MS SQL scripts need Enterprise Edition or Cloud, and Git sync is free on Community Edition for workspaces with up to 2 users.
The edition sets the number of Task and Trigger types (132 and 20 in Essentials, 359 and 37 in Pro). The Web API and the MFT Server come from the Advanced edition; the Robot Task and Agent distribution are in the Pro edition.
The verdict
Both tools schedule and run jobs on Windows. VisualCron does it by configuring Tasks from a large catalog on one Windows server. Windmill does it with scripts and flows written as code, run on Linux and Windows workers and kept in Git.
Where VisualCron is the better choice
- Configured tasks instead of code. Hundreds of Task types are configured in forms, so an administrator can build a Job without writing a script. Windmill steps are code.
- Managed file transfer in the same product. From the Advanced edition, VisualCron's MFT Server hosts SFTP and FTP servers inside the VisualCron Server, and an MFT Server Trigger can start a Job when a file is received. Windmill has no built-in file transfer server.
- Desktop automation. The Pro edition's Robot Task automates desktop applications, browsers and Excel workbooks, including "older applications that have no API". It runs in the desktop session of a logged-on user, through that user's VisualCron Tray Client. Windmill has no Robot Task and no recorder for desktop interfaces. A script on a Windows worker can call Windows UI Automation, but a worker run as a Windows service, as the Windows workers page recommends for production, runs in session 0, which has no interactive desktop, so the script finds no application windows to drive.
- Windows events as triggers. Event Triggers react to Windows services, the registry, the event log, performance counters, session changes and printers on the Server. In Windmill, that is a scheduled script on a Windows worker that checks the state.
- One Windows server and nothing else. VisualCron installs on one Windows machine with its own embedded database. Windmill needs a server and PostgreSQL, deployed with Docker Compose or Kubernetes, and Windows machines join as workers.
Where Windmill is the better choice
- Jobs as code in Git. Each script and flow is a file that you can edit locally, review in a pull request and deploy with Git sync or the CLI.
- Windows and Linux in one place. PowerShell and C# steps run on Windows workers (Self-Hosted Enterprise), next to Python, TypeScript or Bash steps on Linux workers, in the same flow and the same run history.
- Any language, with its packages. Each script declares its own dependencies in its imports, pinned in a lockfile when it is saved, instead of being limited to what a task type exposes.
- People in the loop. Approval steps pause a flow until someone approves, and every script has an auto-generated form so colleagues can run it with their own inputs, without access to the scheduler.
- Event-driven runs over HTTP. Every script and flow has webhooks, and HTTP routes map your own paths to them.
- AI-assisted authoring. Windmill AI writes and edits scripts and flows in the editor, and the CLI installs skills for coding agents such as Claude Code, Codex and Cursor.
- Open source. The Community Edition is free to self-host, and the AGPLv3 core's source is on GitHub.
If you are deciding between the two, the fastest way to judge is to spend an afternoon in each.
Using VisualCron and Windmill together
You do not have to move every Job at once.
Start a VisualCron Job from Windmill
VCCommand.exe runs a Job "from scripts, batch files or another scheduler", so a PowerShell script on a Windows worker where VCCommand.exe is installed can start an existing Job as one step of a flow, for example after an approval step.
Start Windmill from VisualCron
The HTTP Task sends an HTTP request to a URL, so a VisualCron Job can call a Windmill webhook and hand the rest of the work to a flow.
Move Jobs one at a time
The migration guide maps Jobs, Tasks and Triggers to Windmill and shows how a coding agent can convert an exported Job. Run the Windmill copy with its schedule disabled until you have compared the results.
For the other Windows schedulers and Microsoft tools, see Windmill vs Task Scheduler and SQL Server Agent, Windmill vs SSIS, Windmill vs PowerShell Universal and Windmill vs Power Automate.
Frequently asked questions
Build your internal platform on Windmill
Scripts, flows, apps, and infrastructure in one place.