When you set up a deployment pipeline, one of the first decisions you'll make is how files actually reach your server. FTP, FTPS, and SFTP all move files between a client and a server, but they differ significantly in security, authentication, and what else you can do once connected. Choosing the wrong protocol can leave credentials exposed in transit, block key-based authentication, or prevent you from running post-deployment commands.
This guide breaks down each protocol, compares them side by side, and gives you a clear recommendation based on your hosting environment.
Quick Comparison
| Feature | FTP | FTPS | SFTP |
|---|---|---|---|
| Encryption | None — plaintext | TLS/SSL on control + data channels | Full SSH encryption |
| Authentication | Username + password | Username + password + SSL certificate | Username + password or SSH key |
| Default Port | 21 | 21 (explicit) / 990 (implicit) | 22 |
| Firewall Friendliness | Poor — passive mode needs port range | Poor — same passive-mode issues as FTP | Excellent — single port |
| Remote Commands | No | No | Yes (if SSH access granted) |
| Speed | Fast (no encryption overhead) | Moderate (TLS handshake + encryption) | Moderate (SSH session + encryption) |
| Best Use Case | Legacy systems, isolated networks | Compliance-driven environments (PCI DSS) | Modern deployments, CI/CD pipelines |
FTP — File Transfer Protocol
FTP is the original file transfer protocol, dating back to 1971 (RFC 114) and later standardised in RFC 959. It operates on a client-server model with two separate channels: a control channel (port 21) for commands, and a data channel (negotiated dynamically) for actual file transfers.
How It Works
The client connects to port 21 and authenticates with a username and password. Once authenticated, FTP commands handle file operations:
STOR— upload a file to the serverRETR— download a file from the serverDELE— delete a file on the serverLIST— list directory contents
Many FTP clients wrap these raw commands in friendlier interfaces, so you'll sometimes see PUT instead of STOR or GET instead of RETR in logs.
The Security Problem
Everything in FTP travels in plaintext — including your username and password. Anyone on the same network segment can capture credentials and file contents with a packet sniffer like Wireshark. This isn't a theoretical risk; it's trivially exploitable on shared networks, cloud VPCs with misconfigured security groups, or any environment where traffic passes through untrusted hops.
FTP also requires opening a range of ports for passive mode data connections, which complicates firewall rules and increases attack surface.
When FTP Still Makes Sense
Some shared hosting providers only offer FTP access. If that's your situation, FTP is your only option — but you should push your provider to support SFTP, or consider migrating to a host that does. FTP is also acceptable on completely isolated networks where traffic never crosses an untrusted boundary, though even then SFTP is preferable. For a deeper look at whether FTP still has a place in modern workflows, see Is FTP Dead? A Look at Its Continued Use in Deployment.
FTPS — FTP Secure (FTP over TLS)
FTPS extends FTP by wrapping the connection in TLS (Transport Layer Security), the same encryption layer that protects HTTPS traffic. It comes in two flavours:
- Explicit FTPS (port 21): The client connects on port 21 and issues an
AUTH TLScommand to upgrade the connection. This is the modern, preferred approach. - Implicit FTPS (port 990): The TLS handshake happens immediately on connection. This is largely deprecated but still found on older servers.
How It Works
After the TLS handshake, FTPS behaves identically to FTP — same commands (STOR, RETR, DELE), same two-channel architecture. The difference is that both the control and data channels are encrypted, so credentials and file contents are protected in transit.
FTPS authentication involves SSL/TLS certificates. The server presents a certificate that the client can verify against a trusted Certificate Authority, providing server identity assurance that plain FTP lacks.
Strengths and Weaknesses
FTPS solves FTP's biggest problem — plaintext transmission — while maintaining compatibility with existing FTP infrastructure. If your organisation already has FTP workflows and tooling, FTPS is a relatively painless upgrade.
However, FTPS inherits FTP's firewall headaches. The data channel still requires either a port range for passive mode or complex NAT traversal. This makes FTPS noticeably harder to configure in environments with strict firewall policies or cloud security groups compared to SFTP's single-port simplicity.
FTPS also only supports password-based authentication (plus certificates). It doesn't support SSH key authentication, which limits automation options in CI/CD pipelines.
When to Use FTPS
FTPS is the right choice when compliance requirements specifically mandate it (some PCI DSS implementations require FTP over TLS), or when you're upgrading an existing FTP setup and need to preserve compatibility with existing scripts and workflows.
SFTP — SSH File Transfer Protocol
SFTP is not an extension of FTP. Despite the similar name, SFTP is a completely different protocol that runs as a subsystem of SSH (Secure Shell). Every byte — authentication, commands, and file data — travels through an encrypted SSH tunnel over a single port (22).
How It Works
SFTP uses SSH's authentication mechanisms, which means you can authenticate with:
- Username and password — similar to FTP, but the credentials are encrypted in transit
- SSH key pairs — a far more secure option that eliminates password-based attacks entirely
If you're not yet using SSH keys, our guide on creating SSH keys from the command line covers five different methods.
SFTP commands mirror FTP's functionality:
PUT— upload a fileGET— download a fileDELETE— remove a fileLS— list directory contentsSYMLINK— create symbolic links
That last command — SYMLINK — is particularly useful for deployment strategies. You can use symlinks to point a web server's document root at a specific release directory, enabling atomic deployments that eliminate downtime during uploads.
Why SFTP Is the Modern Default
Single port: SFTP only needs port 22. No passive mode port ranges, no NAT traversal headaches. This makes it dramatically easier to configure in cloud environments, behind load balancers, and through corporate firewalls.
SSH key authentication: Eliminates password-based attacks and enables passwordless automation — essential for CI/CD pipelines. Keys can be rotated, scoped to specific commands, and audited.
Remote command execution: Because SFTP runs over SSH, you can also execute commands on the server (if your access allows it). This means you can run build steps, restart services, clear caches, or fetch dependencies — all within the same connection. For a walkthrough, see how to deploy using SSH/SFTP and Git with DeployHQ.
Compression: SFTP supports on-the-fly compression, which can offset the overhead of encryption — especially for text-heavy transfers like source code deployments.
SFTP on Windows
Historically, Windows servers were the one environment where SFTP was awkward to set up. That changed with Microsoft's native OpenSSH integration. If you're deploying to Windows servers, OpenSSH on Windows removes the last major barrier to SFTP adoption.
Which Should I Choose?
Here's the short answer: use SFTP unless you have a specific reason not to.
Choose SFTP if:
- You have SSH access to your server (most VPS, cloud, and dedicated hosting)
- You want key-based authentication for CI/CD pipelines
- You need to run post-deployment commands (cache clearing, service restarts, dependency installation)
- You want simple firewall rules (single port)
- You're setting up a new deployment pipeline from scratch
Choose FTPS if:
- Compliance requirements specifically mandate FTP over TLS
- You're upgrading an existing FTP workflow and need backward compatibility
- Your server supports FTPS but not SSH/SFTP (rare, but it happens)
Choose FTP only if:
- Your hosting provider offers no alternative (and consider switching providers)
- You're on a completely isolated, trusted network
Troubleshooting Connection Issues
If you're having trouble connecting via SFTP or SSH, firewall rules and key configuration are the most common culprits. Our troubleshooting server connection issues guide walks through the most frequent problems and fixes.
If you're evaluating SFTP against other secure transfer methods like SCP or rsync, SFTP vs SCP vs rsync provides a detailed comparison to help you decide.
Deploying with DeployHQ
DeployHQ supports all three protocols — FTP, FTPS, and SFTP — so you can connect to virtually any hosting environment. For servers with SSH access, DeployHQ can also run commands before and after file uploads via Build Pipelines, enabling full CI/CD workflows including code compilation, dependency installation, and cache clearing.
Even if your server only supports FTP, DeployHQ's build pipeline still lets you run build steps locally before uploading the compiled output — giving you modern deployment capabilities regardless of your server's protocol support.
Ready to automate your deployments? Sign up for DeployHQ and connect your first server in minutes.
If you have questions about FTP, FTPS, SFTP, or any other aspect of DeployHQ, get in touch or find us on Twitter/X.