An Open-Source Software Company Keeps Multi-Gigabyte Diagnostics Off Its Application Servers With Files.com

An open-source software company publishes a Linux distribution and sells assurance around it: enterprise support, security maintenance, and compliance for the governments, public cloud providers, and enterprises that run it in production. Its support engineers work across the Americas, EMEA, and APAC.

When a supported system misbehaves, the diagnosis lives in files. Logs, configuration files, diagnostic bundles, and sometimes entire disk images are the evidence a support engineer works from, and none of it is small. The artifacts of a modern production system run to gigabytes, and the company expects them to keep growing. For a business whose product is fixing other people's operating systems, file intake is not a side channel. It is the front door.

A Decade of Diagnostics Through One Branded Intake

For years, the company's support organization has run a branded Files.com site under its own support domain as the inbound channel for customer diagnostics. A generic, write-only login lets any customer push files in from the command line, with no account to request and nothing they can read back out, which suits the Linux administrators the company supports. The channel's reach is wide: thousands of unique IP addresses have uploaded through that generic login, and the site holds terabytes of customer-uploaded diagnostic data.

What that channel did not cover was the customer sitting inside the company's own Support Portal, looking at their open case.

The Upload the Portal Could Not Hold

In January 2024, the company set out to let customers submit files from inside the Support Portal itself, where they were already signed in through Salesforce. The natural design would have routed the upload through the portal's own backend: the browser would post the file to the company's application, and the application would forward it to storage.

But that architecture put the portal in the path of every multi-gigabyte transfer. A web application server is built to answer requests measured in seconds, and holding a multi-gigabyte file in transit ties it up for minutes or hours; long transfers can run past the server's request timeouts before they finish. And the files were only going to get bigger, because the company expected customers to upload huge log files when they needed to. Huge log files are what broken production systems produce.

The cost of shipping that design would have landed on the customer at the worst possible moment: a production system down, an engineer waiting for evidence, and the upload either dying mid-transfer or threatening the stability of the portal every other customer was using.

Bigger servers and longer timeouts could not fix it. That only raises the ceiling while file sizes grow past it. Redirecting customers to a separate upload site could not fix it either, because the identity the company needed lived in the portal: the customer was already authenticated in Salesforce, and every file had to arrive attributed to the user who sent it, without asking them to log in to a second system. The application had to own the identity, and the application could not be allowed to touch the file.

The company resolved it by making Files.com the upload plane behind the portal. The platform that already held its diagnostic archive would take the browser uploads too, straight from the customer's machine.

The Browser Sends the File While the Portal Keeps the Identity

The integration the company built in early 2024 splits the file plane from the application plane. Using the Files.com REST API, the portal generates upload destinations, and the customer's browser sends the file directly to Files.com storage. The company's application servers never receive, buffer, or forward a byte of it. The file travels from the customer's machine to the platform in one hop.

Identity comes from the session the customer already has. Because the uploader is signed in to Salesforce before they ever reach the upload control, the portal attaches that identity to each submission, and the file lands tied to the user who sent it. There is no Files.com account to create and no second login. As far as the customer can tell, they attached a file to their case.

What arrives through the portal lands in the same channel as everything else. The company's engineers retrieve customer files with their own accounts, over SFTP with SSH keys from the command line or through the web interface behind the company's own SAML single sign-on. However a diagnostic comes in, a terminal push or a browser drop, the people who need it reach it the same way.

An Intake Path Sized by the Platform, Not the Portal

With the integration in place, the company replaced an upload path bounded by its own application servers with one bounded by a platform built to carry files.

• The portal and the upload no longer share a fate. The company's application never holds a file in transit, so a large diagnostic does not consume portal capacity or run out the clock against a request timeout.
• Customers hand over evidence at the worst moment of an incident without leaving the portal they are already signed in to. No second account, no separate site, and every file arrives attributed to its sender.
• Growth in file size lands on Files.com, not on the company, and adding the browser path added no second system to run. Portal uploads and command-line uploads land in one governed channel.

One Front Door, Any Size of Evidence

Today, an administrator with a production system down opens the case they already have, drops in the logs or the disk image, and a support engineer pulls it straight down over SFTP. The size of the evidence no longer decides whether the handoff works, and the portal standing between a broken system and the engineer who can fix it does not have to carry the file itself.

The company did not make its web application better at carrying files. It stopped asking the application to carry them at all. The portal kept what an application is for — the customer's identity, their case, their context — and Files.com took the bytes. Since the split, the two have not had to grow together: diagnostics can keep getting larger, and the portal stays exactly the size of a web application.