Every Windows VPS eventually needs a file transfer path: pushing a build to a staging server, pulling database backups off the box, or exchanging files with clients who will not touch a command line. On Windows Server you have two first-class options. The IIS FTP server has shipped with the OS for two decades and speaks FTPS (FTP over TLS); the OpenSSH server provides SFTP over the same SSH transport Linux admins already know. This guide sets up both and compares them so you can pick the one that fits your workflow.
The choice often comes down to your clients: if they use FileZilla or Windows Explorer-style drag-and-drop, IIS FTP with FTPS is the friendliest; if they live in a terminal or a CI/CD pipeline, SFTP wins. Either way, compare Windows VPS plans on our comparison table to see which providers let you open the ports you need without a support ticket — some budget hosts lock down inbound ports by default.
Option A — IIS FTP Server (FTPS)
Install the FTP Server role in two commands:
Install-WindowsFeature Web-FTP-Server -IncludeManagementTools
New-Item -Path 'C:\inetpub\ftproot\public' -ItemType Directory -ForceThen configure it in IIS Manager:
- Open IIS Manager → your server node → FTP Firewall Support. Set the data channel port range (e.g., 50000–50100). This step is mandatory for passive mode through any firewall.
- Right-click Sites → Add FTP Site. Point it at C:\inetpub\ftproot\public, bound to port 21.
- In FTP SSL Settings, require SSL. Windows Server can generate a self-signed certificate; use a real one if clients connect from the internet.
- Enable Basic Authentication and lock down access with FTP Authorization Rules.
Passive mode is the part that breaks most setups. FTP uses port 21 for commands and a separate port range for data transfers; open both in Windows Firewall:
New-NetFirewallRule -DisplayName 'FTP 21' -Direction Inbound -Protocol TCP -LocalPort 21 -Action Allow
New-NetFirewallRule -DisplayName 'FTP Passive 50000-50100' -Direction Inbound -Protocol TCP -LocalPort 50000-50100 -Action AllowOption B — OpenSSH Server (SFTP)
Windows Server 2019 and later ship OpenSSH as an optional capability — no downloads, no third-party binaries:
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
New-NetFirewallRule -Name 'SSH 22' -DisplayName 'OpenSSH (22)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22SFTP rides on port 22, which means one firewall rule instead of three, and it works with every SFTP client — WinSCP, FileZilla, curl, and every Linux tool. Prefer SSH keys over passwords. Generate a key pair on the client, then install the public key on the server:
# On the client: ssh-keygen -t ed25519
# On the server, for an admin user 'deploy':
Add-Content -Path 'C:\ProgramData\ssh\administrators_authorized_keys' -Value 'ssh-ed25519 AAAA... deploy@client' -Encoding ascii
icacls 'C:\ProgramData\ssh\administrators_authorized_keys' /inheritance:r /grant 'SYSTEM:F' /grant 'Administrators:F'For non-admin users the key file is C:\Users\<user>\.ssh\authorized_keys. To restrict a user to SFTP only — no shell access — add this to C:\ProgramData\ssh\sshd_config:
Match User deploy
ForceCommand internal-sftp
ChrootDirectory D:\sftp\deployChrootDirectory on Windows works per-drive, and the directory must be owned by an admin account. Verify with: sftp deploy@<vps-ip>
Head-to-head
| IIS FTP (FTPS) | OpenSSH (SFTP) | |
|---|---|---|
| Ports | 21 + passive range | 22 only |
| Encryption | TLS (explicit) | SSH |
| Key-based auth | No (user/pass or IIS auth) | Yes — keys are standard |
| Best for | GUI clients, Explorer-style users | CI/CD, admins, Linux interop |
| Setup effort | Role + firewall + passive range | One capability + one rule |
Which one should you pick?
Run both if you like — they coexist without conflict. The pragmatic rule: if the people moving files are humans with GUI clients, give them FTPS on IIS; if the things moving files are scripts, pipelines, and Linux boxes, give them SFTP. Many teams end up with SFTP for automation and FTPS only for the occasional manual upload.
Whichever you choose, never expose plain FTP (port 21 without TLS) to the internet — credentials and files travel in cleartext, and scanners will find it within hours. Require TLS for FTPS, keys for SFTP, and restrict the firewall rules to the source IPs that actually need them. If you are still choosing between providers and want one where you can open these ports and add a data disk without friction, see the full specs and pricing on our comparison table.
A real-world case
A small agency moved a client’s staging workflow from shared hosting FTP to a Windows VPS with OpenSSH. Deploys went from “zip, upload via FileZilla, pray” to a two-line CI script using sftp with key auth — while client-facing file drops still ran on IIS FTP over TLS, because their customers would not touch a terminal.
A Windows VPS running both protocols costs no more than a basic plan. Database Mart Windows VPS plans include the Windows Server license and US-based support — helpful if your provider’s firewall team needs to open that passive port range for you.
Bottom line
FTP vs SFTP is not really a protocol debate — it is a client debate. IIS FTP with mandatory TLS covers GUI users; OpenSSH covers everything scripted. Both install in minutes with the commands above, and both beat the plain-FTP habits that still cause breaches. Set one up, test with a real client, and document the ports you opened.
