Canonical Keeps Multi-Gigabyte Ubuntu Diagnostics Off Its Application Servers With Files.com

Canonical is the publisher of Ubuntu, an open-source Linux distribution. The company gives the operating system away and sells assurance around it: enterprise support, security maintenance, and compliance for the governments, public cloud providers, and enterprises that run Ubuntu in production, with support commitments that can run as long as 15 years. 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 Canonical engineer works from, and none of it is small. The artifacts of a modern production system run to gigabytes, and Canonical 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

Since 2015, Canonical'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 Canonical supports. The channel's reach is wide: more than 5,000 unique IP addresses have uploaded through that shared credential, and by 2023 the site held roughly 3 TB of customer-uploaded diagnostic data. The channel also handled large-file delivery: in 2021, a single 41 GB download completed through the web interface.

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

The Upload the Portal Could Not Hold

In January 2024, Canonical 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 Canonical'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 Canonical 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 Canonical 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.

Canonical 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 Canonical 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. Canonical'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. Canonical's engineers retrieve customer files with their own accounts, over SFTP with SSH keys from the command line or through the web interface behind Canonical'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, Canonical 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. Canonical'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 Canonical, 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 Canonical 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.

Canonical 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.