To pull a file from a URL directly onto your server, SSH in and run wget "https://example.com/file.zip" or curl -O "https://example.com/file.zip". Both download to your current directory. Use whichever one is on your system, or either if both are.
wget basics
wget downloads a file and writes it to disk with the same name it had at the source:
wget "https://example.com/path/to/file.zip"
Useful flags:
-O newname.zip- save under a different filename.-P /home/user/public_html/uploads- save into a specific directory instead of the one you're standing in.-c- resume a partial download instead of starting over.-q- quiet mode, no progress output (handy in scripts and cron jobs).--limit-rate=500k- cap the transfer speed, so a big download doesn't hog the connection while other things are running.
To grab an entire directory listing recursively, wget -r -np -nH URL works, but be careful: recursive downloads can pull far more than you expect if the source directory is deep. Check what you're about to fetch first.
curl basics
curl is built for talking to URLs generally (APIs, redirects, headers) and downloading is one thing it does. The two common forms:
curl -O "https://example.com/file.zip" curl -o newname.zip "https://example.com/file.zip"
-O keeps the remote filename, -o lets you rename it on the way down. A few flags worth knowing:
-L- follow redirects. Without it, curl stops at the first 301/302 and downloads nothing useful. Add this by default unless you have a reason not to.-C -- resume an interrupted download.-#- show a simple progress bar instead of curl's default stats line.-H "Authorization: Bearer TOKEN"- pass an auth header, for pulling files from an API or private release URL.
If a download fails with an SSL or certificate error, that's almost always the source server's certificate, not your account. Don't reach for -k / --insecure to bypass it unless you're certain the source is trustworthy: skipping certificate verification means anyone between your server and the source could tamper with the file.
Where to run it and where it lands
Connect over SSH the same way you would for any command-line work; see FTP and SFTP accounts if you're more used to a file-transfer client and want the equivalent login details. On most hosting accounts, run the download from inside your site's web root (often public_html) so it lands where your site can serve it:
cd public_html wget "https://example.com/theme.zip"
Once a zip or tarball is on the server, extract it in place rather than downloading, extracting locally, and re-uploading:
unzip theme.zip tar -xzf archive.tar.gz
If the download is a WordPress plugin or theme package, it's often simpler to skip the manual download entirely and install it through WordPress Toolkit or the WordPress admin instead. wget/curl earn their keep for scripts, one-off assets, database dumps, and anything that doesn't have a built-in installer.
Shared hosting vs VPS: where root matters
On shared and WordPress hosting, you're downloading into your own account's file space. There's no root access, and you don't need it: anything inside your home directory or public_html is yours to write to.
On a VPS, you have root SSH access, which changes what's worth thinking about before you run a download:
- Downloading and running scripts as root executes with full system privileges. Read a script before piping it into a shell (the
curl ... | bashpattern is convenient and also a good way to hand a compromised or spoofed source total control of your server). - Where you save matters more. System directories like
/usr/local/binneed root to write to; application files should go under the site's own directory, not scattered into system paths. - File ownership after extracting an archive as root may end up owned by
rootinstead of the web server user, which can break permissions for your app. Check ownership withls -land adjust withchownif needed.
For the broader picture of what you manage yourself on a VPS versus what's handled for you, see VPS overview - what's included and where to find it.
When to contact support
If a download consistently times out or gets refused from our end, or you're not sure whether a script is safe to run as root on your VPS, open a ticket from the portal (Support → New ticket).