LinkUp Built Its Data Delivery Product on Files.com and Retired Its Self-Run FTP Server

LinkUp is a labor-market data company built on an unusual refusal: it does not pull job listings from aggregators. Its crawlers visit employer career pages directly, more than 80,000 of them, every day, so a posting that is live in LinkUp's data closely tracks a posting that is actually live on the employer's own site. That source-level discipline is why hedge funds, global asset managers, banks, central-bank research groups, and university economists buy the data to forecast the labor market. LinkUp now operates as a division of GlobalData plc, the London-listed data and analytics group.

What those clients buy is, in the end, a set of files. Datasets and custom feeds in CSV and Excel, compressed archives running from a few megabytes into the hundreds of gigabytes, generated on LinkUp's pipeline and delivered on a schedule. LinkUp's delivery footprint grew to more than 28 TB in active use. Half of LinkUp's product is delivery. And every institutional client dictates how it can receive files: one runs automated pulls over SFTP, another can only manage plain FTP, a third wants a download button inside a dashboard. LinkUp's business puts a file between its pipeline and dozens of client environments it does not control.

Partners Couldn't Use S3, So LinkUp Ran Its Own FTP Server

LinkUp's first delivery path was Amazon S3: hand clients access to a bucket and let them pull. In practice, its partners could not work that way.

So LinkUp stood up its own FTP server, and paid for it twice. The first cost was operational: a server to patch, monitor, and keep online at a company whose engineers exist to collect and refine job data, with data files built in an on-premise datacenter and then uploaded to the delivery server by hand, every publishing cycle. The second cost was worse, because it blocked the product itself. The server had no API. LinkUp wanted delivery embedded in its own application, so a client could log in, see the files generated for them, and click download. Every improvement to the client's experience of receiving the data stopped at a delivery layer that could not be programmed against.

The problem persisted because it is structural to the business. A data vendor does not choose the protocol; its clients do. A bank behind a change-controlled firewall runs a scheduled SFTP script. A research group wants a browser. Serving all of them from one layer is exactly what a single self-hosted FTP server was never going to become. Building that layer in-house would have pulled engineering away from the data business the company actually sells.

Running the server was survivable as overhead. It was untenable as the foundation for the delivery product LinkUp intended to build. The replacement had to be easier to run than the server it retired, which in practice meant not run by LinkUp at all. Because LinkUp did not control client environments, it also had to accept the protocols already in use while keeping each client's data separate and delivery under LinkUp's brand. And it needed the REST API that LinkUp's application could be built on.

LinkUp selected Files.com as that delivery layer.

One Files.com Site Behind Every Protocol and the Dashboard

Files.com became the delivery layer for LinkUp's product: a single place its pipeline publishes into once, and that every client draws from, whether by script, by FTP client, or by clicking a link inside LinkUp's own application.

On the publishing side, LinkUp's build pipeline pushes generated files over FTPS into per-client Files.com folders. Nobody uploads a file by hand. Each client has its own credentials and its own folder, sees only its own data, and Files.com's per-user download history records who took which file, which gives LinkUp both access attribution and a clean answer when a client asks what was delivered and when.

On the client side, each organization connects the way its environment allows: FTP, FTP with explicit TLS, SFTP, or WebDAV over HTTPS. Automated client systems pull the daily archives on schedule; others download in a browser. All of it runs against LinkUp's own branded domain with dedicated IP addresses that client firewalls can allowlist, so the client sees LinkUp, not a vendor.

The part the FTP server could never do is the delivery product itself. LinkUp's customer-facing application lists the files generated for each client, and every download link in that dashboard is a Files.com delivery: the application calls the Files.com REST API to generate a signed URL for the file and redirects the client's browser to it. The client downloads from inside LinkUp's product. Files.com carries the transfer.

The Server Is Gone, and Delivery Ships Inside the Product

With Files.com in production, LinkUp replaced a server it had to keep alive with a delivery layer it builds on.

• The self-run FTP server was retired. Nobody at LinkUp patches or monitors delivery infrastructure, and the manual publishing step disappeared.
• Delivery became a feature of LinkUp's commercial product. File listings, signed download URLs, and download history surface inside LinkUp's own application through the Files.com API, so improving the client experience is application work, not server work.
• Clients kept the access patterns their environments required, while LinkUp gained a single place to publish and trace delivery.
• When LinkUp moved its entire build pipeline from its on-premise datacenter onto AWS, the Files.com integration carried across that infrastructure change unchanged.

Delivery Became Something LinkUp Builds On

That is the lesson LinkUp's story carries for any company whose product is data: you do not have to build delivery infrastructure to make delivery part of your product. LinkUp made Files.com the layer behind its own application and got out of the server business without giving up an inch of the client experience.