Yes, FileZilla CLI can drive your FTP deployment step in a CI/CD pipeline on a Windows runner or agent. If your build already runs on Windows (self-hosted Windows runners, Azure DevOps Windows agents, or GitHub Actions’ windows-latest), wiring in an automated FTP deploy step is straightforward. Here’s how.
The Windows catch, upfront
FileZilla CLI is a Windows-only product. GitHub Actions defaults new workflows to Ubuntu runners, and most CI/CD tutorials assume Linux — if that’s your setup, this approach doesn’t apply without switching that specific job to a Windows runner. It’s a real, common setup for teams already building on Windows (.NET projects, Windows-targeted builds).
What you need before you start
- A FileZilla CLI license, registered on the machine that will run the deploy step.
- A Windows runner or agent in your CI/CD system — a self-hosted Windows runner, or a hosted Windows image if your provider offers one.
- A Site Manager entry for your deployment target, created ahead of time (in FileZilla Pro’s GUI or via CLI’s own Site Manager commands), so credentials live in Site Manager rather than in a script file you might check into version control.
Write the deployment script
FileZilla CLI runs a plain text file of commands, one per line. Using an existing Site Manager entry keeps credentials out of the script itself:
site "0/My Deploy Site" rput dist /public_html disconnect
site "0/My Deploy Site" connects using the saved Site Manager entry (the 0/ prefix is required for user-defined entries), rput dist /public_html recursively uploads your local dist folder to /public_html on the server, and disconnect closes the connection cleanly. Save this as, for example, deploy.fzcli in your repository.
Learn more about how to manage file transfers with FileZilla CLI.
Wire it into your pipeline
The pipeline step itself just needs to run FileZilla CLI in standalone mode against that script, on a job configured to use a Windows runner. For a GitHub Actions workflow, that means setting runs-on: windows-latest (or your self-hosted Windows runner’s label) on the deploy job, then calling the CLI the same way you would from a Windows command prompt:
fzcli --mode standalone --script deploy.fzcli
This is the same invocation used for scheduled, time-based automation via Windows Task Scheduler — the difference in a CI/CD context is what triggers it. Instead of a fixed daily time, the step runs whenever your pipeline reaches that job: after tests pass, on a push to your deploy branch, or whatever trigger your workflow already uses. If you also need fixed-time automation independent of your CI/CD triggers, that’s a separate, already-documented setup — see How to Schedule a Script with FileZilla CLI.
Test the script locally first
Run fzcli --mode standalone --script deploy.fzcli from a Windows machine with FileZilla CLI installed before wiring it into your pipeline. Confirming the Site Manager entry connects and the upload path is correct outside of CI makes it much faster to tell a script problem apart from a runner or pipeline-configuration problem later.
Managing deploys across FTP, SFTP, and cloud storage from the same automation layer? See FileZilla CLI plans.