What are the differences between FTP, FTPS and SFTP?

Short answer: use SFTP. In 2026, SFTP is the right protocol for almost every deployment scenario. It encrypts everything, works through firewalls on a single port, supports SSH key authentication for CI/CD automation, and lets you run post-upload commands on the server. The only reasons to use FTP or FTPS are legacy hosting constraints or specific compliance mandates.

Now let's dig into why — and when the exceptions apply.

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, walks through real-world deployment scenarios, and gives you a migration path from FTP to SFTP.

Quick Comparison

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 server
• RETR — download a file from the server
• DELE — delete a file on the server
• LIST — 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 TLS command 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 file
• GET — download a file
• DELETE — remove a file
• LS — list directory contents
• SYMLINK — 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.

What Happens When You Use FTP in Production

The security difference between FTP and SFTP is not academic. Here's exactly what an attacker sees when they capture FTP traffic on a shared network — something that takes about 30 seconds with Wireshark or tcpdump:

$ tcpdump -A -i eth0 port 21

14:32:01.445312 IP client.52314 > server.21: Flags [P.], length 28
USER deploy_admin

14:32:01.512847 IP server.21 > client.52314: Flags [P.], length 33
331 Password required for deploy_admin

14:32:01.658923 IP client.52314 > server.21: Flags [P.], length 24
PASS s3cureP@ss2026!

14:32:01.734561 IP server.21 > client.52314: Flags [P.], length 27
230 User deploy_admin logged in

14:32:02.102445 IP client.52314 > server.21: Flags [P.], length 38
STOR /var/www/html/config/database.php

That's your username, password, and deployment paths — all readable as plain text. On a shared WiFi network at a coffee shop, a compromised router, or a cloud VPC where another tenant's instance is sniffing traffic, this is all it takes. The attacker now has:

1. Server credentials to log in directly and modify any file
2. Knowledge of your file structure to target config files, .env files, or database credentials
3. Access to file contents — if they capture the data channel too, they see every file you upload, including source code with hardcoded secrets

With SFTP, the same capture looks like this:

14:32:01.445312 IP client.52314 > server.22: Flags [P.], length 156
.......%C.E.~d..3.{..K..#.r..5.9L..h.a.Vw.p..J$..
.......m..R7..S.....z..N..e.2..Q....b..x.K.T.....

Encrypted. Every byte. The attacker gets nothing usable.

This matters more than most teams realise, especially in cloud environments. In AWS, for example, traffic between instances in the same VPC is not encrypted by default. If another EC2 instance in your subnet is compromised, FTP traffic to your deployment server is fully readable. SFTP eliminates this risk entirely.

Real-World Deployment Scenarios

The right protocol depends on your hosting environment, and your hosting environment determines far more than just the transfer method — it shapes your entire deployment capability. Here's what each scenario actually looks like in practice.

Shared Hosting (cPanel/Plesk)

Protocol: FTP (often the only option)

Most budget shared hosting plans expose FTP as the sole file transfer method. Some modern shared hosts have added SFTP support, but it's not universal. cPanel-based hosts typically provide FTP by default and SSH access only on higher-tier plans.

What this means for your deployment workflow:

• You can upload files, but you cannot run commands on the server after upload
• No composer install, no npm run build, no cache clearing, no database migrations
• You must build everything locally and upload the compiled output
• No atomic deployments — users may see partially uploaded files during a deploy
• No SSH key authentication, so you must store passwords (even in CI/CD tools)

If your project has server-side build steps, shared hosting with FTP-only access is a hard blocker. You'll need to either move to a host with SSH access or pre-build everything before upload.

VPS (DigitalOcean, Linode, Hetzner, Vultr)

Protocol: SFTP + SSH

Every major VPS provider gives you full SSH access by default. This is the sweet spot for most deployment workflows — you get complete control without the complexity of managed cloud services.

What this unlocks:

• SSH key authentication for fully automated, passwordless deploys
• Post-upload commands: composer install --no-dev, php artisan migrate, npm run build
• Atomic deployments via symlink switching — zero-downtime deployments become trivial
• Server-side Git pulls as an alternative to file uploads
• Service restarts (systemctl restart nginx, pm2 reload app)

A typical deployment to a VPS looks like: upload changed files via SFTP, run composer install to update dependencies, run database migrations, clear the application cache, and swap the symlink to the new release directory. All over a single SSH connection.

Cloud Providers (AWS, GCP, Azure)

Protocol: SFTP for VMs, or skip file transfer entirely

On cloud platforms, you have more options than traditional file transfer. EC2/Compute Engine/Azure VMs work exactly like a VPS — SFTP with SSH keys. But cloud-native deployment patterns often bypass file transfer protocols altogether:

• Container deployments (ECS, Cloud Run, AKS): You push a Docker image to a registry, and the orchestrator pulls it. No FTP/SFTP involved.
• Serverless (Lambda, Cloud Functions): You upload a zip archive or deploy via CLI. Again, no file transfer protocol.
• Platform-as-a-Service (Elastic Beanstalk, App Engine): Git push or CLI deployment.

For teams running traditional VM-based deployments on cloud providers, SFTP is the clear choice. The single-port requirement is especially valuable in cloud environments where security groups and network ACLs add friction for every open port.

WordPress on Managed Hosting

Protocol: Varies widely by host

WordPress managed hosting is a mixed bag:

• WP Engine, Kinsta, Flywheel: SFTP access included, often with SSH on higher plans. Some support Git-based deployment.
• Bluehost, GoDaddy, SiteGround basic plans: FTP or SFTP, but typically no SSH command execution.
• WordPress.com (hosted): No direct file access at all on lower plans.

The key question isn't just which protocol — it's whether you can run wp-cli commands after upload. If your theme or plugin deployment involves wp cache flush, wp rewrite flush, or wp db import, you need SSH access, not just SFTP file transfer.

Enterprise with Compliance Requirements

Protocol: FTPS (mandated) or SFTP (preferred)

Some compliance frameworks — particularly PCI DSS for payment card processing and certain HIPAA implementations — specifically require FTP over TLS in their documentation. This makes FTPS a compliance checkbox even when SFTP would be technically superior.

The practical reality:

• Compliance auditors want to see encrypted file transfer in transit — both FTPS and SFTP satisfy this
• If your compliance team insists on FTPS specifically, use explicit FTPS (port 21 with AUTH TLS) rather than implicit (port 990)
• Budget for the firewall complexity — FTPS passive mode requires opening port ranges (typically 10 ports minimum), and every port range must be documented in your security audit
• Certificate management adds operational overhead: renewals, revocations, chain validation
• Consider proposing SFTP as an alternative during your next compliance review — most modern frameworks accept SSH encryption as equivalent to TLS

Which Should I Choose?

flowchart TD
    Start([What protocol should I use?]) --> SSH{Does your server<br/>support SSH?}

    SSH -->|Yes| PostDeploy{Do you need to run<br/>commands after upload?}
    SSH -->|No| SSHUpgrade{Can you upgrade<br/>your hosting plan?}
    SSH -->|Not sure| CheckSSH[Try: ssh user@server<br/>If it connects, you have SSH]
    CheckSSH --> SSH

    PostDeploy -->|Yes| SFTP_REC[✅ Use SFTP<br/>Full deployment automation]
    PostDeploy -->|No| SFTP_STILL[✅ Use SFTP anyway<br/>Single port, key auth, future-proof]

    SSHUpgrade -->|Yes| UpgradePlan[Upgrade plan for SSH access] --> SFTP_REC
    SSHUpgrade -->|No| Compliance{Compliance requirement<br/>for FTP over TLS?}

    Compliance -->|Yes, mandated| FTPS_REC[⚠️ Use FTPS<br/>Budget for firewall + cert management]
    Compliance -->|No| FTP_REC[⚠️ Use FTP<br/>Consider switching hosts]

    style SFTP_REC fill:#2d6a4f,color:#fff
    style SFTP_STILL fill:#2d6a4f,color:#fff
    style FTPS_REC fill:#e9c46a,color:#000
    style FTP_REC fill:#e76f51,color:#fff

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

Migrating from FTP to SFTP

If you're still using FTP, migrating to SFTP is one of the highest-impact, lowest-effort improvements you can make to your deployment security. Most servers already have SSH enabled — you just haven't configured it yet.

Step 1: Confirm SSH Access

Check whether your server supports SSH. Connect from your terminal:

ssh your-username@your-server.com

If you get a password prompt or a shell, SSH is available and SFTP will work. If the connection is refused, check with your hosting provider — many hosts enable SSH on request or on upgraded plans.

For connection issues, our guide to debugging SSH connections covers the most common problems.

Step 2: Generate an SSH Key Pair

On your local machine, generate a key pair:

ssh-keygen -t ed25519 -C "deploy@yourcompany.com"

ed25519 is the recommended algorithm in 2026 — it's faster and more secure than RSA for new keys. If your server doesn't support it (very old OpenSSH versions), fall back to ssh-keygen -t rsa -b 4096.

Step 3: Install the Public Key on Your Server

Copy your public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub your-username@your-server.com

If ssh-copy-id isn't available (Windows without WSL), manually append the contents of ~/.ssh/id_ed25519.pub to ~/.ssh/authorized_keys on the server.

Verify passwordless login works:

ssh your-username@your-server.com
# Should connect without asking for a password

Step 4: Update Your Deployment Tool

In your deployment tool, change the protocol from FTP to SFTP and add your SSH private key. In DeployHQ, this is a single settings change on your server configuration — switch the protocol dropdown, paste your private key, and you're done.

Once you've verified SFTP deploys are working, disable FTP access on your server entirely. On most Linux servers:

sudo systemctl stop vsftpd
sudo systemctl disable vsftpd

This closes port 21 and eliminates the plaintext credential risk permanently.

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.