Use and troubleshoot FTP
When FTP still fits
Choose FTP, FTPS, SFTP, HTTPS, or object storage according to interoperability, security, automation, and publishing needs.
8 minute lesson
Use plain FTP only inside a deliberately protected legacy environment when replacement is not yet possible. Prefer FTPS when a partner mandates the FTP protocol but supports TLS.
Prefer SFTP when you control SSH-based server access and want one encrypted connection. Prefer HTTPS uploads or object-storage APIs for modern web applications, signed links, fine-grained credentials, and cloud workflows.
For a final exercise, draw one required transfer. Mark trust boundaries, protocol, ports, authentication, encryption, data direction, retry behavior, integrity check, and how partial files stay hidden. The diagram should justify the protocol instead of choosing by habit.
Use a decision table:
| Constraint | Strong default |
|---|---|
| Existing partner requires FTP semantics | Explicit FTPS with protected data channels |
| You manage SSH accounts on both ends | SFTP |
| Browser or service uploads | HTTPS API or signed upload URL |
| Large cloud objects and lifecycle rules | Object storage API |
| Unreplaceable cleartext appliance | Isolated network, narrow gateway, replacement plan |
Also define failure semantics. Can an upload resume? Is a retry idempotent? How do consumers avoid partial files? Which hash or application check proves integrity? Who rotates credentials and reviews access?
Compatibility is a reason to keep FTP, not a reason to ignore its risks. Put a protected gateway near the legacy endpoint instead of spreading cleartext credentials and wide passive ranges across the network.
Revise the transfer diagram with one deliberate network failure after data EOF but before final confirmation. Explain how the automation discovers whether it is safe to retry.
Lesson completed