One Write-Only Files.com Login Eliminates Customer Account Provisioning for Canonical Support

Canonical is the publisher of Ubuntu, the most popular guest operating system on the public clouds. Its global support organization spans 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 Canonical's engineers is where every support case actually starts.

To make that first step work at global scale, Canonical 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 Canonical'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 Canonical 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. Canonical'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 Canonical's own name, and whose routing Canonical could control. Canonical selected Files.com to be that endpoint, and its support intake has run on the platform since 2015.

One Shared Login That Can Only Write

What Canonical 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 Canonical maintains no account roster at all.

Because the intake speaks plain SFTP, every machine in Canonical'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 Canonical's own support domain, so customers push files to Canonical, 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. Canonical's engineers retrieve customer files under their own identities, using Canonical-backed 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 Canonical'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 Canonical 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 Canonical 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 Canonical'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. Canonical successfully moved a 41 GB file 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: Canonical's support operation has grown for more than a decade, and the channel that feeds it is still one credential on one endpoint.

What the Publisher of Ubuntu Decided Not to Build

Canonical is a company of developers and system administrators. It ships the operating system much of the world's cloud server infrastructure runs on, and 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 Canonical has run on Files.com since 2015. 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 40 gigabytes across the internet.