Building an SFTP-Only Client File Drop on a Cheap VPS
TL;DR / Summary: Freelancers and tiny agencies often need a place for clients to upload brand assets without sharing a full shell or a consumer cloud folder. A budget VPS with chrooted SFTP users, per-client directories, and boring backups solves it. Find a low-cost VPS with enough SSD space for campaign seasons, not just idle system files.
Why SFTP still wins for non-technical clients
Email attachments corrupt, hit size caps, and vanish into threaded chaos. Consumer file links expire or require accounts clients refuse to create. SFTP looks old-fashioned, yet FileZilla, WinSCP, and Cyberduck make it approachable, and many design studios already know the workflow from web hosts.
The security story is clearer than “here’s my Google Drive.” Each client gets a login that cannot leave its jail. You keep ownership of retention policies. When a project ends, you disable one user instead of hunting shared links across personal accounts.
Choose disk and I/O before fancy CPU counts
File drops are storage-and-bandwidth problems. Video drafts and RAW photo sets will dwarf a 20 GB plan overnight. Estimate the largest concurrent project set you support, multiply by 1.5 for versions, and pick SSD capacity from that number. A single vCPU is usually enough; starved I/O is what makes uploads crawl.
Watch transfer allowances if clients upload from offices with aggressive sync tools. A misconfigured client that re-uploads identical trees can burn monthly caps. Prefer providers that show clear overage math rather than silent throttling mid-deadline.
Snapshots help recover from “I deleted the wrong folder,” but keep an off-site rsync or object-storage copy for ransomware days. Snapshots on the same hypervisor are convenient, not sovereign.
Account layout that stays sane at ten clients
- One system role: your admin SSH key on a non-default port or behind AllowUsers.
- One SFTP user per client: random username, key preferred, password only if they insist.
- Chroot to /srv/drops/clientname: no visibility into other clients.
- inbox/ and outbox/ folders: clients write inbox; you publish deliverables to outbox.
Write the folder contract into your kickoff email. Ambiguous “just put it on the server” instructions create duplicate trees and overwritten finals.
Hardening without breaking FileZilla
Disable unused SSH subsystems where possible and force internal-sftp for drop users. Keep admin SSH separate from client credentials. Fail2ban on SSH still helps when passwords are unavoidable; key-only client accounts reduce that noise dramatically.
Set upload quotas per user if your filesystem supports project quotas, or enforce soft limits with a nightly du report emailed to you. Surprises are worse than firm caps communicated upfront—“20 GB per active project” is a professional boundary, not rudeness.
TLS certificates are irrelevant to raw SFTP, but if you add a simple HTTPS file list later, terminate TLS properly and never recycle client SFTP passwords into web logins.
If a client user can read /etc/passwd or another tenant’s files, you built a shared host, not a drop box.
Operational manners that save Friday nights
Name files with project codes and dates on your side even if clients upload “final_final2.zip.” Keep a receiving checklist: confirm checksum when they provide one, virus-scan archives before opening on your workstation, and acknowledge receipt in the project channel.
Rotate access at project close. Disable the account the day invoices are paid and archives are cold-stored. Lingering credentials are how old campaigns leak into new mood boards years later.
Document reconnect steps in a one-page PDF: host name, port, protocol, and which folder to use. Support time shrinks when the same PDF answers every “it won’t connect” email.
Automations that stay humble
Optional: a cron job that notifies you on new inbox files via a small script watching mtimes. Avoid elaborate middleware that unpacks client zips automatically—hostile archives exist. Human open on an isolated machine still beats cleverness.
If you sync outbox deliverables from your laptop, use an explicit push command. Bidirectional sync tools have deleted deliverables when someone “cleaned up” a local folder. Explicit beats clever for money files.
Cost and exit plan
Price the VPS against the hours you lose wrangling email binaries. Include backup storage in the true monthly cost. Keep an export script that packages each client tree so you can migrate providers without a scavenger hunt.
When a client outgrows SFTP—hundreds of collaborators, elaborate permissions—graduate them to a proper DAM or Drive shared drive. The cheap VPS should remain a sharp tool for small casts, not a pretend enterprise NAS.
Onboarding script you can reuse
Send a short checklist: recommended client apps by OS, exact hostname, port, protocol SFTP (not FTP), username, and whether key auth is required. Include a screenshot of the inbox/outbox folders. Clients who receive only a password in Slack will invent wrong ports and generate weekend support pages you cannot bill fairly.
For key auth, accept a public key via a side channel you already trust—signed email or a kickoff call—rather than a random pastebin. Store the public key in your inventory notes beside the matter or campaign code so offboarding deletes the right line in authorized_keys.
Offer a five-minute screenshare once per new client. The time prepaid beats three asynchronous “still failing” loops. After that, point them back at the PDF; do not become an unpaid IT desk for their entire company VPN.
Give clients a folder, not a full shell
An SFTP-only drop on budget hardware is professional when chroots are real, disks are sized for media, and off-box backups exist. Size the machine with help from Affordable VPS Server, hand each client a narrow login, and retire access when the campaign ends so your next upload window starts clean.
