Why an automated Deployment Tool is better than FTP for Freelancers
Imagine, you're a freelance web developer. You've just fixed some bugs or added a new feature to a customer's website. It's time to upload your code and the free Wi-Fi in the cozy café seems convenient and fast enough. You start your graphical FTP client, enter the credentials the customer has given to you, the upload begins… and then: "Connection timed out".
The web shop is offline or something else went wrong, and now you're in serious trouble. FTP is an inefficient protocol, it's old-fashioned and – this is the worst part – it's also vulnerable to attacks. Let's take a look at how FTP works and then at alternatives.
How does FTP work?
The File Transfer Protocol is used to exchange files between two computers via a network connection. It's a client-server architecture: The client identifies itself to the server, usually with username and password. Alternatively, anonymous connections are allowed if the FTP server is configured accordingly. Credentials as well as files are being transmitted in clear text, there is no encryption!
To make things more safe FTP can be secured with SSL/TLS (FTPS). There is also SFTP (SSH File Transfer Protocol or Secure File Transfer Protocol), an extension of the SSH protocol (part of the SSH program suite) to provide secure file transfer capabilities and not to be confused with FTP run through an SSH tunnel.
Unlike most other internet protocols, FTP uses two channels between client and server. The command or control channel (port 21) and the data channel (port 20) are on two separate TCP connections. The command channel usually handles the commands between the server and the client as well as the replies. The actual data transfer happens on the data channel.
FTP also knows two different modes that define how the data connection is established: active and passive. In active mode, it's the server that initiates the connection with the client (after the FTP client has established a connection on the command channel). If this happens the other way round, i.e. the client initiates the data connection with the server, then this is called passive mode.
Why FTP is annoying
The File Transfer Protocol has been around for a very long time. It all started in 1971 when the first version was published. Over the years FTP has seen a number of revisions and improvements, but it still lacks a lot of features and has plenty of flaws:
- FTP is insecure
This protocol was never designed to be secure. We've mentioned the lack of encryption, and there are a number of known exploits. Not just the files are sent in clear text, also the usernames, passwords, and the commands you use in an FTP session. Really, it is quite vulnerable.
- FTP is slow
For every single file you transfer, FTP opens a new data channel, performs a TCP handshake and then starts transmitting – transferring a large amount of smaller files is a pain and FTP users often see messages like "FTP connection timed out" or "Read timed out".
- Deleting files via FTP is a pain
If you've uploaded the wrong files and later try to delete a folder that contains files and more folders in a nested structure, then you'd better be patient. You can't delete non-empty folders via FTP. First, remove all files, then the empty directory.
- FTP is not designed for Collaboration
Are you working in a team? So, which one of you is going to upload the latest code review to your customer's server? Do you all have different accounts, or do you share the username and password? Which brings us back to "1. FTP is insecure"…
Alternatives to FTP
To solve some of the security issues, you can switch to FTPS (same protocol, same problems, with a little extra security) or SFTP which is not really FTP, as mentioned above. It uses a completely different protocol and requires an SSH server instead of an FTP server. If you can find a web hoster that offers SSH access, that's definitely a lot better than FTP. Because SSH and therefore SFTP only use one channel (TCP port 22), this protocol solves performance issues at the same time.
Now, let's look at the collaboration problem. Neither FTP nor SFTP are meant for team work. Even if you're all located in one office and talk about when and what to upload, you really shouldn't share usernames and passwords. Giving the credentials to just one person causes even more trouble when this team member is off sick or on vacation.
Connecting it all: Deployment Tools
Using a deployment tool can improve your workflow and enhance security at the same time. Most deployment tools can connect to a version control system like Git that offers to store a history of all changes, to track code revisions in a repository, to merge different file versions, and, if needed, to restore previous versions. Using a combination of a version control system and a deployment tool improves the collaboration between team members.
The deployment tool also connects repositories of your version control system to one or more servers where you upload your changes to. DeployBot, for example, supports modern and secure protocols with encryption and authentication. Apart from SFTP, you can use our Atomic SFTP feature to add an extra layer of security. Instead of uploading files directly to the defined directory on the remote server, atomic deployments maintain a special directory structure on your server. This allows you to store more than one release and and switch between them if necessary.
If it has to be FTP…
Of course, DeployBot not only supports SFTP or Atomic SFTP, it also connects to FTP servers if you don't have SSH access. DeployBot supports both FTP modes (active and passive), connects to one or more FTP server with your credentials and uploads files to a specified destination path.
You will still be stuck with the File Transfer Protocol, but you can at least connect a version control system, quickly roll back to previous versions and share the server credentials in a safe environment. So, if you still have customers insisting on FTP, you can make your life easier with a deployment tool and sleep a lot better knowing that you're not going to break a website or a web shop – at least not because of a lousy protocol.