A Database Vendor Turns Hundreds of Manual Diagnostic Uploads Into One Script Run With the Files.com Python SDK

An enterprise database software company sells its data platform two ways: as a fully managed cloud service, and as on-premises database software that enterprises run in their own datacenters.

The on-prem product creates a support problem the cloud product never has. When a self-hosted cluster misbehaves, the evidence lives inside an environment the vendor cannot see. Diagnosis starts with a support package: a bundle of diagnostics generated on the customer's own instance and delivered to the vendor. Every fix begins with a file crossing out of a network the vendor does not operate.

Hundreds of Instances, One Upload at a Time

Large on-premises customers run hundreds of database instances. The old collection path treated each one as its own event. For every instance, someone on the customer's side generated a support package, took a one-time upload URL issued from the ticketing system, and pushed the file up by hand. Getting a full picture of a big fleet meant repeating that loop hundreds of times.

The cost landed on both sides of the ticket. Customer engineers spent hours on uploads, often in the middle of an incident, when their time was worth the most. The vendor's support team could realistically ask for only the handful of packages a customer would tolerate uploading, so engineers diagnosed fleets from samples. And routine collection, gathering packages when nothing is on fire so that problems surface early, was out of reach entirely. Nobody hand-uploads hundreds of files for a checkup.

The problem persisted because the obvious fix was genuinely hard to do safely. Automation had to run on infrastructure the vendor did not control, and any script the vendor handed a customer needed a credential to upload with. That credential leaves the vendor's hands the moment it ships. A shared password or a broadly scoped key, distributed into hundreds of external organizations, is exactly the kind of standing credential no security review will bless.

So the fix had a specification before it had a product. It had to collect packages across a customer's entire cluster list in one run. It had to upload over an API rather than a browser. And it had to authenticate with something scoped so tightly that losing it would expose no stored diagnostic data: a credential that could deposit files and do nothing else. The company selected Files.com to provide that upload layer.

A Python Script and a Key That Can Only Write

The company's engineers wrote a Python script against the Files.com Python SDK. Given a customer's cluster list, the script called the database's management API on each instance to generate a support package, then pushed the packages to Files.com in bulk. The Technical Account Manager who built it did not need a project plan to get there.

The credential design is what made the script safe to hand into someone else's datacenter. Each upload identity is a Files.com API key with granular, write-only permission. The automation could deposit packages into the vendor's intake and nothing more. It could not read, browse, or delete anything already there.

The company also attacked the payload itself, compressing support packages to a small fraction of their original size. At that size, moving diagnostics stopped being a bandwidth event and became something a script could do quietly and often.

Fleet Collection Is Now a Script Run

With the pipeline in place, the vendor replaced an exception process built on one-time URLs and manual uploads with a repeatable collection pattern.

• Collecting diagnostics from a fleet of hundreds of instances is one script run against a cluster list, not hundreds of hand uploads by the customer's engineers.
• A compressed support package is small enough that routine, repeated collection is practical instead of a favor the vendor asks only when something is broken.
• No credential capable of exposing stored diagnostic data sits in customer automation: every key is write-only and scoped to the intake path.
• Extending the pattern to another customer means issuing another scoped key rather than building a new workflow.

Getting Evidence Out of Environments the Vendor Cannot See

The barrier to collecting diagnostic data at scale was never the file transfer. It was the credential. A write-only, narrowly scoped Files.com key gave the vendor automation it could hand to outside organizations without exposing the files already in its intake.