How to Transfer Files to Your Server (FTP, SFTP, and rsync)
%203.png&w=256&q=75){kind=small}
Three Ways to Move Files Onto a Server
There are three real options for getting files onto a Linux server, and they are not interchangeable. FTP is the legacy option — it moves both credentials and file contents in plaintext, and there is rarely a good reason to reach for it in 2026. SFTP runs file transfer over the same SSH connection you already use to manage the server, encrypting everything and needing only port 22, which makes it the right default for GUI clients and one-off uploads. rsync over SSH adds delta transfer and resumability on top of that same encrypted channel, which makes it the right tool for large sites, media libraries, and full migrations.
Picking between them is really a question of scale and repetition. A single zipped backup or a handful of images is fine over SFTP with a GUI client. A multi-gigabyte WordPress uploads folder, a database dump over a shaky connection, or a full site migration is a job for rsync, because it only sends what changed and can pick up where it left off after a dropped connection.
SFTP: The Default Choice for Manual Transfers
SFTP uses your server's normal SSH credentials or key over port 22, so there is no separate account or extra firewall rule to manage on top of what SSH already needs. From the command line, connecting and uploading a file or a whole folder takes two commands.
For most people, though, a GUI client is the more practical way to work with SFTP day to day. FileZilla, Cyberduck, and WinSCP all connect over SFTP using the exact same SSH credentials or key and the same port 22 — there is nothing server-side to configure differently for a GUI client versus the command line. Point the client at your server's hostname, supply the SSH key or password, and drag files between the local and remote panes the same way you would with old-style FTP, minus the plaintext risk.
rsync Over SSH for Large Transfers and Migrations
rsync earns its place for anything larger than a quick upload because it transfers only the parts of a file that actually changed, rather than re-sending the whole thing every time. The basic push over SSH looks like this.
The trailing slash on the source path matters more than it looks like it should: `/local/path/` copies the contents of that folder into the destination, while `/local/path` without the slash copies the folder itself into the destination, nesting everything one level deeper than you probably intended. It is easy to get this backwards once and end up with a duplicated directory structure on the server.
rsync's other advantage over a plain `scp` is that it resumes cleanly. A single `scp` of a large database dump that fails partway through a flaky connection starts over from zero on retry. rsync, run again with the same command, picks up from where the interrupted transfer left off instead of re-sending bytes that already arrived — which matters a lot when you are moving a multi-gigabyte media library or backup archive over a connection that occasionally drops.
Mirroring a Directory with --delete
Sometimes you don't just want to add new files to the destination — you want the destination to end up as an exact mirror of the source, with anything removed locally also removed on the server. Adding `--delete` does exactly that.
`--delete` is dangerous without testing first. A wrong source path, a wrong remote path, or a source directory that is emptier than you think will delete real files on the server, permanently. Always dry-run it before letting it touch anything.
Read the dry-run output line by line before dropping the `n`. If the list of files it plans to delete looks larger or different than you expect, stop and check your paths again rather than assuming the command is right.
Why Plain FTP Should Be Avoided
Plain FTP runs on port 21 plus a range of passive ports, and it sends both your login credentials and the actual file contents in plaintext over the network. Anyone positioned on the same network path — a shared network, a compromised router, an intermediate hop — can read a plaintext FTP session in full, credentials included.
There is rarely a good reason to use plain FTP over the public internet in 2026. SFTP uses the same port your server already has open for SSH, needs no extra firewall rules, and encrypts the exact same data FTP would have sent in the clear.
The extra passive port range FTP needs is also its own maintenance burden — it means opening more of your firewall than SFTP ever requires, for a protocol that offers no encryption in return. If a client or legacy tool insists on FTP specifically, FTPS (FTP over TLS) is the closer substitute, but for anything you are setting up new, SFTP or rsync over SSH covers the same ground with none of the exposure.
How CloudStick Handles File Transfer
Day-to-day file transfer on a CloudStick server doesn't require root SSH access or a shared, server-wide FTP account. Code updates go through Git deployment — push-to-deploy from your repository straight into the site's document root — which covers the most common transfer need without touching SFTP or rsync at all. For everything else, the dashboard File Manager handles direct uploads and edits through the browser, and per-site SFTP and FTP accounts are scoped to that one site's own document root rather than to the server as a whole.
If your workflow is Git-based, start there — it's the fastest path for code. For a one-off asset upload or a quick edit, the File Manager or a scoped SFTP account gets it done without handing out broader access than the task needs. And when you are moving a whole site's worth of files during a migration, rsync over SSH with a dry run first is still the right tool for the job, CloudStick server or otherwise — just point it at the per-site account rather than a shared root login.
