How to Set Up an FTP Server: A Practical Walkthrough

Setting up an FTP server in 2026 has two paths: DIY (provision Linux, install an FTP daemon, configure auth, harden the OS, open the firewall) or hosted (a managed-file-transfer platform provisions an endpoint for you). The DIY path is mature and well-documented; the hosted path is what most teams converge on once they count the real operational cost of self-hosting. This post walks through both — the actual commands for the DIY route, the decision framework, and the production-grade concerns that turn "set up an FTP server" from a one-day task into a multi-week project.

For most production deployments in 2026, SFTP (encrypted, single-port, SSH-based) is the right protocol — not plain FTP. The setup is similar; the security posture is dramatically better. See our FTP vs FTPS vs SFTP comparison.

DIY vs hosted: the decision framework

Factor	DIY	Hosted
Setup time	1–5 days	10 minutes
Recurring engineering cost	4–8 hours/quarter	Zero
Storage cost	Whatever your VM provisions	Per-GB / included
Compliance scope	Yours	Vendor's
Multi-protocol support (FTP + FTPS + SFTP + WebDAV)	Each protocol = a separate daemon to maintain	All on one platform
Audit logging	You build it	Built in
Control over infrastructure	Total	Vendor-defined

For small internal workloads (one team, two partners, no compliance pressure), DIY is genuinely cheaper. For anything past that scale, hosted usually wins on TCO once you count the operational surface.

The DIY path

Step 1: Provision a server

Most production FTP servers run on Linux. Common cloud options:

• AWS EC2 — a t3.medium instance (2 vCPU, 4 GB RAM) is enough for low-to-medium volume. About $30/month before data transfer.
• DigitalOcean — a 4 GB / 2 vCPU droplet is comparable, around $24/month.
• Hetzner — for budget-sensitive workloads, ~$8/month for similar specs.

For high-availability production, double everything (two instances behind a load balancer + replicated storage), or use a managed disk service for resilience.

Static IP required. FTP clients connect by IP or hostname; the IP can't change between sessions. Cloud providers offer "elastic IPs" or equivalent.

Adequate bandwidth. FTP file transfer saturates the network easily; pick an instance class with at least 1 Gbps networking for anything beyond hobby use.

Step 2: Choose the FTP daemon

Three open-source options dominate Linux FTP server deployments:

• vsftpd (Very Secure FTP Daemon) — lightweight, security-focused, the default on most Linux distros. Best for FTP/FTPS only.
• ProFTPD — modular, extensible, supports FTP/FTPS/SFTP via mod_sftp. Best for multi-protocol workloads.
• OpenSSH — already installed on every Linux system. Enables SFTP via one line in sshd_config. Best when you only need SFTP.

For a new SFTP-only deployment, OpenSSH is usually the right answer — no additional software to install or maintain.

For multi-protocol (FTP + FTPS + SFTP on the same files), ProFTPD is the canonical open-source choice.

Step 3: Install and configure

For OpenSSH SFTP (Ubuntu/Debian):

# OpenSSH is already installed; ensure SFTP subsystem is enabled
sudo grep -i sftp /etc/ssh/sshd_config
# Should show: Subsystem sftp /usr/lib/openssh/sftp-server
sudo systemctl restart sshd

That's literally it. Add a Unix user with useradd, and they can connect via SFTP using their system credentials or an SSH key.

For vsftpd (FTP and FTPS):

sudo apt update
sudo apt install vsftpd
sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.orig

# Key settings in /etc/vsftpd.conf:
#   listen=YES                  # IPv4 listener
#   anonymous_enable=NO         # disable anonymous access
#   local_enable=YES            # allow local users
#   write_enable=YES            # allow uploads
#   chroot_local_user=YES       # confine users to their home dir
#   pasv_min_port=50000         # passive mode range
#   pasv_max_port=50100
#   ssl_enable=YES              # enable FTPS
#   rsa_cert_file=/etc/ssl/private/vsftpd.pem
#   rsa_private_key_file=/etc/ssl/private/vsftpd.pem
#   require_ssl_reuse=NO        # avoid TLS session-reuse issues

sudo systemctl restart vsftpd

For ProFTPD (FTP/FTPS/SFTP):

sudo apt install proftpd-basic proftpd-mod-mysql proftpd-mod-sftp
# Configure in /etc/proftpd/proftpd.conf — much more flexible than vsftpd
# but also a longer learning curve. Recommended: walk through the
# official "Quickstart" docs at http://www.proftpd.org/

Step 4: Configure authentication

The default is PAM authentication — users authenticate against Linux's normal /etc/passwd and /etc/shadow. Workable for small deployments where each FTP user maps to a real Unix account.

For larger deployments, virtual users are cleaner — users that exist only for FTP, with credentials in a database or file separate from system accounts. ProFTPD supports virtual users via mod_auth_file, mod_sql, or LDAP backends. vsftpd supports them via PAM + pam_pwdfile.

For SFTP, SSH key authentication is the modern default — put each user's public key in ~/.ssh/authorized_keys. See our SSH keys setup guide.

Step 5: Harden the operating system

A fresh FTP server with default Linux configuration is not production-ready. At minimum:

• Update everything — apt update && apt upgrade (or the RHEL equivalent). Re-do this monthly.
• Disable root SSH login — set PermitRootLogin no in sshd_config.
• Enforce password policies for FTP users — minimum length, complexity, expiration. PAM modules handle this.
• Install fail2ban — automatically blocks IPs that fail authentication repeatedly.
• Configure unattended security updates — unattended-upgrades package on Ubuntu.
• Disable unused services — anything not strictly needed shouldn't be running.
• Run a CIS benchmark scan (or use a hardening tool like lynis) and address findings.

The CIS Benchmark for Ubuntu / RHEL has hundreds of recommendations. Production servers should pass at least the Level 1 controls.

Step 6: Open firewall ports

The protocols' port requirements:

• FTP control — TCP 21
• FTP active-mode data — TCP 20 (rarely needed in 2026)
• FTP passive-mode data — a configurable range (e.g., 50000–50100). Both the OS firewall and any cloud-provider firewall (security groups in AWS, firewall rules in GCP/Azure) need to allow this exact range.
• FTPS implicit — TCP 990 control + 989 data (deprecated)
• SFTP — TCP 22 (single port — much simpler)

For UFW on Ubuntu:

sudo ufw allow 21/tcp                # FTP control
sudo ufw allow 50000:50100/tcp       # FTP passive data range
sudo ufw allow 22/tcp                # SFTP
sudo ufw enable

Match the passive port range to your FTP daemon's pasv_min_port / pasv_max_port settings exactly. Mismatch is the #1 cause of "I can log in but the directory listing hangs."

See our active vs passive FTP explainer for why passive mode is the default and how to debug it.

Step 7: TLS certificates for FTPS

If you're enabling FTPS, you need a valid TLS certificate. Three options:

• Let's Encrypt (free, automated) — works for FTPS with some setup; the certbot package handles renewal automatically.
• A commercial CA (paid, simpler audit story for some regulated environments).
• A self-signed certificate (free, but clients have to be configured to trust it manually — fine for internal-only deployments).

Step 8: Monitoring and logging

Production FTP servers need:

• Log shipping — vsftpd's /var/log/vsftpd.log or ProFTPD's /var/log/proftpd/proftpd.log should ship to a log-aggregation platform (Loki, ELK, Splunk).
• Health checks — at minimum, a cron job that connects to the FTP server every 5 minutes and alerts if the connection fails.
• Capacity alerts — disk usage, network utilization, concurrent-connection counts.

For shops without a log aggregation layer, even something simple like multitail plus email alerts is better than nothing.

What the DIY path doesn't give you

After the eight steps above, you have a working FTP server. What you don't have:

• A queryable audit trail. Raw log lines aren't a SOC 2 / HIPAA evidence package.
• MFA support. Add it via PAM modules; nontrivial.
• SSO with SAML or SCIM. Not native to any FTP daemon; build it or use a third-party gateway.
• A REST API for programmatic file access. Either build it on top, or use a different platform.
• Webhook notifications when files arrive. Build with inotify + a small service, or use a managed platform that provides it.
• Multi-region replication. Build with rsync jobs, or use a managed platform.
• Compliance documentation for auditors.

Each of these is doable; each adds days to weeks of work.

The hosted path

The alternative: a managed-file-transfer platform provisions an FTP / FTPS / SFTP endpoint for you. The platform handles the protocol layer, the OS hardening, the TLS certificates, the audit logging, and the compliance posture.

Files.com is the File Orchestration Platform we'd recommend in this category — broadest protocol support, strongest compliance posture, REST API + SDKs. Setup is:

1. Sign up at files.com/signup (free trial, no credit card).
2. Pick a subdomain. The platform provisions FTP, FTPS, SFTP, WebDAV endpoints on the standard ports.
3. Create users in the admin UI. Configure SSH keys for SFTP users.
4. Done.

The "set up an FTP server" job becomes 10 minutes of clicks instead of 1–5 days of apt install and config-file editing.

Other options worth knowing about:

• SFTP To Go and SFTPCloud — SFTP-only managed services, cheaper than Files.com for shops that only need that one protocol.
• Commercial MFT software (Globalscape EFT, Cerberus FTP Server, JSCAPE MFT) — self-hosted-but-managed paid software for shops that need to keep the server on their own infrastructure.

When self-hosting is genuinely the right call

Three scenarios:

• Air-gapped or sovereign-cloud deployments. Regulated workloads that can't touch multi-tenant cloud. Self-host inside your boundary, ideally on a hardened Linux image you already use for other services.
• You already have infrastructure capacity. If your team is running compliant Linux fleet management, audit aggregation, and key rotation tooling, adding FTP is incremental rather than a new category.
• Truly small, low-stakes workloads. One internal team, no compliance requirements, two partners. OpenSSH + a $20/month VM is the cheapest option that works.

For most other situations, the operational cost of self-hosting compounds in ways that aren't obvious in the first three months.

For air-gapped / on-prem deployments: the appliance

The free ExaVault on-premise appliance handles FTP / FTPS / SFTP / WebDAV from a self-hosted VM image (VMware OVA, AWS Marketplace AMI, GCP image). It's the "managed-but-on-prem" middle path: you run it inside your boundary, but the operational tooling (patching, audit logs, multi-protocol support) is already configured.

FAQ

What's the easiest FTP server to set up?

OpenSSH for SFTP — already installed on every Linux system, enabling it is one line in sshd_config. vsftpd for FTP/FTPS — one apt install plus a config file edit. For a hosted option that's even easier, sign up for Files.com and an SFTP endpoint provisions in 10 minutes.

How much does it cost to run an FTP server?

DIY: $20–500/month in cloud infrastructure depending on scale, plus the engineering time to maintain it (realistically 4–8 hours/quarter for a small deployment, more for production). Hosted: per-user or per-feature pricing, typically $50–500/month for a small team.

Can I run an FTP server on Windows?

Yes. Microsoft Internet Information Services (IIS) includes an FTP server role; install it via Server Manager. FileZilla Server is the popular open-source option for Windows. For commercial: Cerberus FTP Server and Globalscape EFT.

What ports does an FTP server need open?

FTP: port 21 (control) plus a configurable range of high ports for passive-mode data (typically 50000–50100). FTPS: same plus optionally 989/990 for implicit TLS. SFTP: just port 22. See our FTP ports deep-dive.

What's the difference between an FTP server and an SFTP server?

An FTP server speaks the original File Transfer Protocol on port 21 — cleartext by default, dual-channel design. An SFTP server speaks SSH File Transfer Protocol on port 22 — encrypted by default, single-channel, supports SSH keys. They're different protocols; a client built for one cannot connect to the other.

Should I use FTP or SFTP for a new deployment?

SFTP for almost every case. Single port, encrypted by default, native SSH key auth, easier to firewall. The only reason to choose FTP today is compatibility with a legacy partner or device that can't speak SSH. See our FTP vs SFTP comparison.

Do I need a static IP for an FTP server?

For a publicly-accessible server, yes — clients need to connect by a stable IP or hostname. For an internal-only FTP server, a DHCP-assigned IP is fine if you're using DNS to resolve the hostname. Cloud providers offer "elastic IPs" or equivalent for this.