A Final-Mile Delivery Provider Retires Its In-House File Server for Unattended SFTP Dispatch

A US final-mile delivery and third-party logistics provider runs dispatch and warehouse operations for retail shippers.

Final-mile work runs on a daily rhythm. A retail client hands over the day's freight, and dispatch software turns the day's truck manifest into driver routes. Which means the dispatch pipeline starts before any truck moves: it starts with a file, arriving from a client, every single day. For a company whose business is other companies' deliveries, client file exchange is not back-office plumbing. It is the front end of dispatch.

For three years, Files.com has kept that nightly feed running unattended, with the warehouse contacting the site's operator only when something goes wrong.

A Hand-Managed Server Standing in Front of Dispatch

For one of the company's dispatch operations, that exchange ran on infrastructure of its own. File sharing lived on a legacy internal server, provisioned by requesting hardware from the corporate parent, alongside GoDaddy storage that supported only FTP. The clients needed SFTP. Each client also needed strict isolation: a national retailer sending its manifests could never be allowed to see another retailer's folder. That isolation was built and maintained by hand, one folder and one login at a time.

The cost compounded with every client. Each new retail shipper added another hand-managed boundary, and getting one folder's permissions wrong would have put one national retailer's operational data in front of another. Underneath all of it sat the nightly manifest feed that routes the drivers. The whole daily dispatch operation depended on an arrangement the company itself had lost confidence in.

The problem was hard to fix in-house for a structural reason: the person running the exchange was a business-side manager, so any fix built on servers meant more requests to the corporate parent and more infrastructure to maintain. And the retail clients connected with their own standard tooling, so whatever replaced the server had to look, from the outside, exactly like an SFTP server.

That was the specification. A standard SFTP endpoint the clients could reach with the tools they already had. Per-client isolation enforced by the platform rather than by hand. Nothing to host, and simple enough for one business-side manager to run alone. The provider selected Files.com to be that server.

One Site, One Folder and One Login Per Client

The business-side manager set up the site in a self-directed rollout with no infrastructure project behind it. The design is a single Files.com site exposed over SFTP, with a dedicated folder and a dedicated login for each retail client. Files.com user- and folder-level permissions scope each credential to its own directory, so the wall between clients is enforced by the platform rather than by anyone's memory.

To the clients, nothing unusual happened. National retail chains and a major freight marketplace connect with FileZilla, the same way they would reach any SFTP server, with nothing new to install and no change on their side. Each drops the day's truck manifest into its own folder, encrypted in transit, and the file loads into the dispatch software that routes drivers for that operation.

The same design is what makes the next client cheap. Bringing a new retail shipper onto the feed is a folder, a login and a permission, applied to a site that already exists.

Three Years of Unattended Nightly Manifests

With the Files.com site in production, the provider replaced a hand-managed server exercise with a repeatable pattern for connecting retail clients to dispatch.

• The nightly manifest feed runs unattended. The warehouse contacts the site's operator only when something is wrong, and the file has kept arriving every night for three years.
• Per-client isolation stopped depending on manual folder management. Each client's credential reaches its own directory and nothing else, so the exposure risk that came with every hand-built login is gone.
• Onboarding a new retail shipper no longer means requesting a server from the corporate parent. National retailers were brought onto the same site with no IT project at all.
• The entire exchange is operated by one business-side manager, with no server to patch, host or babysit.

From Running a Server to Running Deliveries

The fundamental change is who the file server belongs to. Files.com holds the folders, enforces the walls between clients, and answers on the SFTP endpoint their clients' tools already speak, while the provider runs deliveries.