FTP vs SFTP vs FTPS: Which Is Safe to Use?
%203.png&w=256&q=75){kind=small}
The Short Answer: Use SFTP
SFTP is the one to use. It runs entirely inside an encrypted SSH session on a single port, which means every credential and every byte of a file transfer is protected, and it inherits whatever SSH hardening already exists on the server instead of needing its own separate configuration. Plain FTP sends usernames, passwords, and file contents in the clear and has no real justification on the public internet in 2026. FTPS sits in between — it does encrypt the connection, but it keeps FTP's awkward multi-port model and adds complexity that SFTP simply avoids.
The rest of this comes down to why: what each protocol actually does on the wire, where FTPS and SFTP diverge despite the similar-sounding names, and which one wins on the practical details — firewall rules, NAT traversal, and client support — that decide how painful a setup actually is to run.
Plain FTP: Unencrypted by Design
Plain FTP (File Transfer Protocol) sends everything — the login handshake and the file contents — completely unencrypted. FTP splits into two connections: a control connection on port 21 that carries commands and credentials, and a separate data connection, opened on a different port, that actually carries the file bytes. Neither connection is encrypted in any way. Anyone able to observe traffic between the client and the server — a shared network, a compromised router, a man-in-the-middle position — can read the username, the password, and every uploaded or downloaded file in plaintext, in real time.
There is no meaningful reason to run plain FTP over the public internet today. The only place it still shows up is on very old embedded devices, legacy client software that has never been updated, or closed internal networks with no internet exposure at all — and even in those cases, SFTP or FTPS should be used instead whenever the client is capable of it.
FTPS: TLS Bolted Onto FTP
FTPS (FTP over SSL/TLS) is FTP with TLS encryption added on top — and it is not the same protocol as SFTP, despite the near-identical name. FTPS comes in two modes. Implicit FTPS connects on port 990 and starts the TLS handshake immediately, before any FTP commands are exchanged. Explicit FTPS connects on the standard FTP control port, 21, and then issues an AUTH TLS command to upgrade the plaintext connection to an encrypted one partway through.
Encrypting the credentials and file data is a real improvement over plain FTP. What FTPS does not fix is the underlying multi-port model it inherits from FTP itself: a control channel plus a separate data channel, with the data channel often needing a whole range of ports open for passive mode. That makes FTPS noticeably harder to configure through NAT and firewalls than a protocol that only needs one port, even though the data traveling over it is now protected.
SFTP: A Different Protocol Entirely
SFTP (SSH File Transfer Protocol) is not FTP with encryption bolted on — despite the similar name, it is a completely different protocol that runs entirely inside an SSH session, on a single port, 22 by default. There is no separate control channel and data channel to manage, and no second port range to open for passive-mode transfers, because the file transfer traffic rides inside the same SSH connection a server already uses for shell access.
Because SFTP is carried inside SSH, it automatically inherits whatever SSH hardening is already in place on the server — key-based authentication, disabled password login, fail2ban rules watching for brute-force attempts — instead of needing its own, separate security configuration to lock down. Harden SSH once, and SFTP access is hardened along with it.
Firewalls, Ports, and Client Support
On firewall and NAT complexity, SFTP wins outright: FTP and FTPS both need a control port open plus a whole range of data ports for passive mode — often 20 or more additional ports — while SFTP needs exactly one port, the same port SSH already uses. Fewer open ports means a smaller attack surface and a much simpler firewall rule set to maintain.
Opening a large passive-mode port range for FTP or FTPS just to make a client connect reliably widens the attack surface on every server it touches — each open port is one more thing that has to be firewalled, monitored, and eventually patched.
Client support settles the rest of the argument. Virtually every modern FTP client — FileZilla, Cyberduck, WinSCP — supports SFTP natively, alongside FTP and FTPS. There is no compatibility reason left in 2026 to choose FTP or FTPS over SFTP for a new setup; the only scenario where plain FTP might still appear is a very old embedded device or a closed internal network with no internet exposure, and even then SFTP or FTPS should be preferred if the client can handle it at all.
How CloudStick Handles File Access
CloudStick supports SFTP on every plan, including the Free tier, so encrypted file access is never something you have to configure or pay extra for. Plain FTP access is offered as an additional option on Basic and above, for the rare case where a specific tool or workflow still expects classic FTP. Both are scoped to a single site's own document root rather than the whole server, so a set of credentials for one website can never reach another site or the server's system files.
Use SFTP by default for anything server-related — it is single-port, key-friendly, and inherits your existing SSH hardening for free. Reach for FTPS only if one specific client absolutely requires classic FTP semantics but still needs the connection encrypted. Never use plain FTP over an untrusted network; there is no scenario on the open internet where that trade-off makes sense in 2026.
Because CloudStick scopes both options to a single site's document root and treats SFTP as the default rather than an add-on, there is no FTPS configuration to manage and no unencrypted transfer path exposed by default — the safe choice is simply the one that's already there when a site is created.
