Roadmap
This roadmap sets out the main features we want to release at the moment. To see the latest releases, check our Changelog and to see all feature requests, visit our GitHub.
For what’s been shipped recently, see the changelog.
Next 6 months
Dedicated workers v2Backend
Dedicated workers are currently a setting for individual scripts, flows and worker groups. A dedicated worker can only be dedicated to one script or flow. We mean to change that so that in the extreme case, it can handle a full workspace.
We want them to now have a configuration, let's call it the dedicated worker configurations that select all the flows and scripts (potentially apps) it will be dedicated to:
for all those it needs to do a compaction for ts and python where it will essentially route internally the job to the right subfunction based on job path which mean all those scripts can now run on the same runtime and we have at most 2 running runtimes (bun, python) on a dedicated worker. Those configuration can be deployed and each deployment will have a deployment version and a status . It corresponds to the status of creating the single lockfile for ts and single lockfile for python. If we have incompatible reqs for different scripts it will fail otherwise it pass.
Instead of having to declare if a script or flow is ran on dedicated worker on the script or flow, they will be automatically updated when they are part of a successful deployment of a worker config such that their tag become dedicated:<dedicated_worker_config_name>
The creation of the compacted view is the "hard part". Once we have those, we can use our normal traversers to generated or fail to generate the single lockfile.
We want them to now have a configuration, let's call it the dedicated worker configurations that select all the flows and scripts (potentially apps) it will be dedicated to:
for all those it needs to do a compaction for ts and python where it will essentially route internally the job to the right subfunction based on job path which mean all those scripts can now run on the same runtime and we have at most 2 running runtimes (bun, python) on a dedicated worker. Those configuration can be deployed and each deployment will have a deployment version and a status . It corresponds to the status of creating the single lockfile for ts and single lockfile for python. If we have incompatible reqs for different scripts it will fail otherwise it pass.
Instead of having to declare if a script or flow is ran on dedicated worker on the script or flow, they will be automatically updated when they are part of a successful deployment of a worker config such that their tag become dedicated:<dedicated_worker_config_name>
The creation of the compacted view is the "hard part". Once we have those, we can use our normal traversers to generated or fail to generate the single lockfile.
Workflow as code v2Default
Using a syntax similar to mastra/cloudflare workflows for better Workflow As Code support
Local Windmill executionDeveloper
Investigate having Windmill work locally for local workflow and script execution allowing better DX and AI agents to have immediate local feedback.
Improve wmill lint for agentsDeveloper
The wmill lint command already works for v0. Improve it to be a more complete feedback tool for agents locally + clear OpenAPI specs for each kind of items writable locally by agents, for improved local dev.
Unit tests supportDeveloper
Investigate unit tests with Windmill, either only guidance for local tests or/and supporting it as a first class concept in Windmill.
Extend multiplayer to flows and appsDefault
Extend multiplayer working for scripts to flow and apps.
Add more native triggersBackend
Native triggers for Nextcloud and Google are already done. Next steps are adding native triggers for GitHub, Linear, etc.
Single shard performance focusBackend
Performance focus for low hanging fruits of single shards
Multi-shard support for unlimited scalabilityBackend
Support multi-shards for unlimited scalability
Add more rulesetsBackend
Add more rulesets for deployment rules to match Github rules (read-only prod workspaces, approver rules, etc)
Data tables/PostgreSQL runtime v2Backend
Postgresql runtime v2 to remove the need to cast trivial types and enhance usability
Hub search v2 + AI generation for stepsAI
Better search from hub + better AI generation for steps.
Hide sensitive values from logsBackend
SDK clients should automatically propagate to the workers (maybe using a special pattern in stdout) that there is some strings that are sensitive because they correspond to secrets pulled with getResource and getValue. Additionally, workers should be able to have a list of values to consider secrets synced from an external source-of-truth. Those sensitive values would always be masked in logs.