One Write-Only Files.com Login Eliminates Customer Account Provisioning for a Linux Vendor's Support Team

An enterprise Linux vendor runs a global support organization spanning the Americas, EMEA, and APAC.

Supporting Linux at a distance runs on evidence. An engineer cannot fix a deployment they cannot see, so nearly every serious case begins with something leaving the customer's environment: a log, a configuration file, a diagnostic bundle, sometimes an entire disk image. Getting that evidence from the customer's machine to the company's engineers is where every support case actually starts.

To make that first step work at global scale, the company built one standing Files.com endpoint around a shared, write-only credential: customers could upload from the shell, but none needed an account and none could see another's files.

Thousands of Command-Line Customers, and No Way to Give Each One an Account

The population that needs to send those files is the company's entire enterprise support base: thousands of organizations, changing constantly, unknowable in advance. Provisioning a file-transfer account for every one of them, then distributing, tracking, and retiring each credential, is a standing tax no support team can pay at that scale. But without a standing intake channel, every case that needs a multi-gigabyte artifact turns into bespoke handling: an engineer and a customer negotiating how to move a file, while the system the customer pays the company to support is still broken.

The diagnosis was straightforward: intake at this scale could not depend on knowing the uploader in advance.

The customers themselves ruled out the usual shortcut. The company's support base is Linux administrators, and the diagnostics live on servers, often headless ones with no browser to point at an upload page. Whatever the intake was, it had to be reachable from a shell.

And the files are sensitive. These are diagnostics from production enterprise systems, business-critical customer data, and one customer's submissions can never be visible to another. Data-residency requirements also constrained how any transfer layer was allowed to route traffic.

So the intake had to be a standing endpoint that any Linux machine could push to with tools already installed, that gave nothing back out, that could take files measured in tens of gigabytes under the company's own name, and whose routing the company could control. The company selected Files.com to be that endpoint, and its support intake has run on the platform for years.

One Shared Login That Can Only Write

What the company built is deliberately simple: a single generic credential, shared with its support customers, carrying write-only permissions. Files.com became the standing front door of the support business, a door any customer can push through and no customer can see through.

Write-only permissions do the isolation that per-customer accounts would otherwise have to. An uploader can push files in over SFTP or FTP, but cannot list the directory, read anything back, or see any other customer's submissions. Thousands of organizations share one login, each one's data stays invisible to all the rest, and the company maintains no account roster at all.

Because the intake speaks plain SFTP, every machine in the company's customer base already has the client. An administrator pushes a diagnostic bundle from the affected server itself, or scripts the upload, with nothing to install and nothing to sign up for. The endpoint runs on a branded subdomain of the company's own support domain, so customers push files to the company, not to a visible third party.

Write-Only at the Front Door, Strongly Identified Behind It

The inside of the channel is the opposite of the outside. The company's engineers retrieve customer files under their own identities, using corporate single sign-on for the web interface and SSH public keys for command-line access over SFTP. Frictionless public intake did not require weak internal identity controls. When the company's engineers asked to hold those keys in hardware, in a Yubikey or a Secure Enclave where even a compromised laptop cannot give them up, Files.com shipped support for five additional SSH key formats four days after the request.

Retrieval is automated too. An internal bot the company wrote in Elixir watches the intake folder through the Files.com REST API and pulls relevant new arrivals onto servers behind the corporate proxy, so an uploaded file starts moving toward the engineers who need it without anyone touching it.

One more constraint the design honors is residency. Files.com's Global Acceleration routes transfers through edge locations for speed, and the company uses edge-location control to switch it off where required to meet data-residency requirements.

More Than a Decade of Intake Without a Single Customer Account

More than a decade on, that one channel still carries the diagnostic intake for the company's global support business, and the per-customer provisioning it was built to avoid never happened.

• Diagnostics arrive from wherever they live. Customers push logs, configuration files, diagnostic bundles, and disk images straight from their own servers and scripts.
• The artifacts kept growing and the channel kept up. The company has moved files of tens of gigabytes through the web interface and expects file sizes to keep climbing.
• A new support customer needs no account created, no credential issued, no ticket raised, and no software installed. They get the same door everyone else uses.

That last point is the compounding one. The intake is a rare piece of infrastructure that does not scale with the business it serves: the company's support operation has grown for more than a decade, and the channel that feeds it is still one credential on one endpoint.

What a Company of Linux Engineers Decided Not to Build

The vendor is a company of developers and system administrators. It could have stood up its own file transfer service without breaking stride. It never has, because the hard part of customer file intake was never the protocol. It is operating a governed public endpoint year after year: thousands of strangers' uploads kept apart, strong identity on the inside, zero friction on the outside, and residency requirements honored the whole time.

That is what the company runs on Files.com. Today, when an enterprise case opens anywhere in the world, the path for the evidence already exists. The customer pushes the file from the machine that produced it, and the engineer starts the case with the artifact in hand, not with a conversation about how to move tens of gigabytes across the internet.