Skip to main content

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

A write-only credential let customer-run automation deliver fleet-wide support packages without exposing the diagnostic data already in Redis’s intake.
RedisFiles.com

Redis is the company behind the Redis in-memory data platform. It sells the platform two ways: as a fully managed cloud service, and as Redis Software, 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 Redis cannot see. Diagnosis starts with a support package: a bundle of diagnostics generated on the customer's own instance and delivered to Redis. Every fix begins with a file crossing out of a network Redis does not operate.

Hundreds of Instances, One Upload at a Time

Large Redis Software 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. Redis support 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 Redis did not control, and any script Redis handed a customer needed a credential to upload with. That credential leaves Redis'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. Redis selected Files.com to provide that upload layer.

A Python Script and a Key That Can Only Write

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

I had it working in like half an hour. Your documentation is great.
John Isaac, Technical Account Manager, Redis

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 Redis's intake and nothing more. It could not read, browse, or delete anything already there.

Isaac also attacked the payload itself, compressing support packages roughly 50x, down to about 25 MB each. 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, Redis 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 support package is about 25 MB, small enough that routine, repeated collection is practical instead of a favor Redis 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 Redis 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 Redis automation it could hand to outside organizations without exposing the files already in its intake.