Windmill CLI Now Previews Flows With Local Scripts

Here at Lead AI Dot Dev, we tracked Windmill's latest release and identified a meaningful shift in how the platform handles local development. Version 1.660.0 updates the CLI to use local scripts when previewing flows instead of always pulling from remote versions. This is a direct response to developer friction in iteration cycles - builders testing flows had to push changes to see them reflected in previews, creating unnecessary deployment steps.

The change is surgical: the CLI now recognizes when you're working with local script files and uses those versions during flow preview operations. This means your test runs reference your actual working code, not stale remote versions. It's the kind of workflow improvement that seems small until you've spent thirty minutes wondering why your changes aren't showing in preview.

For teams using Windmill to build workflow automation, this removes a testing bottleneck. Previously, the preview-test-deploy cycle required pushing to see results. Now local iteration is the default path. Your development loop tightens: edit locally, preview immediately, refine, then deploy when confident.

This particularly matters for teams working on complex flows where script logic changes frequently. Data transformation scripts, API orchestration, conditional branching logic - all these benefit from immediate feedback. The friction reduction compounds across a sprint when developers aren't constantly pushing test versions.

The practical implication: your local environment becomes the actual testing ground instead of a staging approximation. This reduces deploy-time surprises and catches integration issues earlier. Teams leveraging this should expect faster iteration velocity on automation projects.

• Local scripts now mirror what preview will actually execute
• Eliminates unnecessary push-to-test cycles during development
• Reduces gap between local testing and production behavior

Builders should verify their workflow uses consistent script references between local and deployed versions. The CLI change is transparent in most cases, but teams with complex script dependencies or environment-specific logic should test the behavior. Ensure your local scripts match what's committed to your repository.

When you're ready to deploy, the workflow remains unchanged - scripts push to Windmill's storage and flows reference them there. This update doesn't alter deployment mechanics, just the preview phase. Teams should document this in their CI/CD processes so everyone understands the local-first testing approach.

One consideration: if your team still has developers manually managing script versions across environments, this update makes that mismatch more visible. Use it as a signal to standardize how scripts are versioned and deployed. The clearer feedback loop should push teams toward better version control practices around their automation code.

• Verify local script versions match repository state before preview
• Deployment process unchanged - only preview behavior shifts
• Makes environment inconsistencies more visible

This update signals where Windmill is placing its bets: developer experience in the iteration phase. As workflow automation platforms mature, the differentiator increasingly isn't execution capability but developer velocity. Windmill is removing friction in the build-test-deploy cycle.

The competitive implication is clear - platforms that reduce time-to-feedback win mindshare with engineering teams. Automation code that changes frequently (which is most automation code) needs tight feedback loops. Windmill's focus on this mirrors trends in broader tooling where local-first development and instant previews have become table stakes.

Thank you for listening, Lead AI Dot Dev