v1.660.0 lets developers preview flows using local script changes before pushing to production, cutting iteration cycles for script-heavy workflows.
Test flow-script integration locally before deployment, cutting iteration cycles and reducing production risks.
Signal analysis
Here at Lead AI Dot Dev, we tracked this release because it directly addresses a friction point in Windmill's development loop. Previously, developers had to deploy scripts to see how they'd behave within a flow preview. The v1.660.0 update flips this - the CLI now references local scripts during flow previews, meaning you test against uncommitted changes without touching your production environment or staging layers.
This is a workflow efficiency gain. For teams building complex orchestrations with multiple script steps, the ability to iterate locally first reduces deploy-test cycles. You're no longer blocked by the deploy-preview-fail loop. Instead, you work locally, verify behavior in preview, then deploy with confidence.
The practical win here is predictability. Before this change, flow previews were static snapshots - they used whatever scripts were already deployed. If you modified a local script to fix a bug or add logic, preview wouldn't reflect those changes. You'd deploy, test in a staging environment, then deploy again to production. That's two deployments for one fix.
Now, your preview environment is tethered to your local filesystem. Edit a script, save, run preview - you see the impact immediately. This matters most for builders working with TypeScript, Python, or shell scripts that feed data into downstream flow steps. Any script mutation that affects return types, error handling, or side effects shows up in preview before it matters.
The tradeoff: you need to keep your local environment in sync with your actual intent. If you're testing against an uncommitted script change and someone else deploys a different version, your preview won't match production. Document your local changes and communicate timing with your team.
This feature assumes you're running Windmill CLI locally and have your scripts in a source-controlled directory structure that mirrors your workspace. If you're using Windmill's web UI exclusively without CLI, this doesn't apply to your workflow - but it should prompt you to reconsider. Local-first development with CLI tooling is becoming table stakes for automation platforms.
The constraint worth noting: external dependencies and environment variables still need to be handled carefully. If your scripts call APIs or databases, those endpoints need to be accessible from your local machine during preview. This is fine for most development workflows but matters if you're building in isolated networks or behind corporate proxies.
Builders should now think of Windmill scripts as first-class code artifacts. Use the same review, testing, and version control practices you'd apply to application code. The CLI is now mature enough to support that workflow. Thank you for listening, Lead AI Dot Dev
Best use cases
Open the scenarios below to see where this shift creates the clearest practical advantage.
One concise email with the releases, workflow changes, and AI dev moves worth paying attention to.
More updates in the same lane.
Mistral Forge allows organizations to convert proprietary knowledge into custom AI models, enhancing enterprise capabilities.
Version 8.1 of the MongoDB Entity Framework Core Provider brings essential updates. This article analyzes the implications for builders.
The latest @composio/core update enhances Toolrouter with custom tool integration, expanding flexibility for developers.
