Deploy via FTP via CI?

Is there any way to automatically deploy via FTP via the CI? Or am I barking up the wrong tree entirely?

I have repositories on GitLab with source code, and deployments to the live environment, today, are made via ye olde “upload files via FileZilla to a server”.

I’m currently looking to do away with this step entirely, and would like it to automagically take my files and put them where they belong.

A cursory google search indicated that Travis CI has the option to do such a thing, does GitLab CI have it as well?

If not, are there any other neat ways to do it? The current solution I’m looking at is using a webhook, but if I can get away with less work (i.e. configuring a runner or somesuch), that’d be preferrable.


I had good success using gitlab ci doing some sort of:

apt-get install lftp

simple and easy, not having to worry about deploying is great and if anything goes badly, the revert button is just one build away :slight_smile:


I’m brand new to CI (GitLab or otherwise) and was wondering about the same thing. I’d love it if the documentation included a thorough explanation of setting up CI with FTP for deployment.

I know, there are better tools for deployment, but FTP is the lowest common denominator and sometimes (often even) it makes sense. All I really need for CI to do is syntax check PHP, maybe run unit tests and then FTP deploy it to staging or production server (ignoring a few folders).

When I get some free time I’m going to see if I can get the above setup running.

Another useful example for GitLab CI deploy via ftp (a little more complex than the above) is here:

How i should do it if I a want to run the build only when master branch is modified? changes made in other branchs are being deployed when i use the gitlab-ci.yml as above

@rbezerra: You can specify that a job only be run for builds of the master branch:

  - master

The first sample in CI documentation contains an example:

1 Like

FTP syncing should not be difficult for GitLab to implement. There are open-source tools, like git-ftp, which already enable simple git-like, rule-base deployment via FTP. This would mean also that web developers like me would not overburden the GitLab servers by setting up pipelines and using up runners just to do simple staging deployment via FTP…

The pipeline-based CI/CD solution offered by GitLab is amazingly powerful, but also incredibly complex. It requires a lot of investment in learning about docker containers, runners, environments, testing, CI, CD, to setup and use even the simplest deployment job - like the ones suggested above. CI/CD setups that cater to complex functional testing and multi-environment staging are useful - even vital - on larger development teams that work on apps. But for web developers working on simple sites, like me, it is overkill.

Or use a docker image for that purpose so your job does not need to install lftp all the time, e.g.

1 Like

I didn’t know that you can deploy via FTP with TravisCI. I knew that you could connect TravisCI ( ) with your github repo and then deploy on your server through it. When deploying from FTP, I don’t think you can mention the various versions of your app like you can with github. So why would someone still want to do it.

Could you please have a look on this issue…

Thank you

Did you find a solution, @nicoesiea?

I’ve tried to figure out the same thing, but “single files” are not updated on the FTP server :frowning: … All new files are transfered like they should, and deleted on the FTP-server, if they are not present in the repo anymore, so that part is working just fine.

It looks like other people, are experiencing the same problem. (I’ve also asked here)

(This topic has 26.5k views, and only 11 replies, so i guess multiple people are trying to do the same thing. But i’m unable to tell, if only a few of us, are facing problems with updating files)

1 Like

Not yet, sorry
I’m still using the same way for my personal projects, but at work we switch to another solution.
For the moment, my only way to manage this issue, is to watch the log and verify the actions traces… And force redeploy in case of no action…
Maybe it could be possible to to the same by watching the FTP client log (by saving them into a variable) and force a new comite based on the previous one… But this is a bit ugly…

Yes, and almost a bit risky, too. However, i would really like it to work, as expected…

Guess i need to make a custom script instead, and just execute it locally…

the problem is that it does not support keys afaik you need a password