Redis Gives Every Support Ticket Its Own HTTPS or SFTP Intake Route With Files.com

Redis is the company behind one of the most widely adopted databases in the world. It sells the commercial platform as a fully managed cloud service and as Redis Software for enterprises that run the database themselves.

The self-managed product is where this story starts. Redis Software runs on the customer's hardware, inside the customer's network, behind the customer's firewall. When it misbehaves, Redis's global support organization has to diagnose a system it cannot reach. Diagnosis starts with a support package: a multi-gigabyte bundle of logs and state that the customer has to get out of their own environment and into the hands of a Redis engineer.

Diagnostics Redis Must Receive, Through Firewalls It Doesn't Control

For the self-managed product, uploading diagnostics is not optional. A customer who wants help has to send the data, so anything that blocks the upload stalls the case at the worst possible moment: while a production database is in trouble.

The old intake ran through the ticketing system. Customers attached files to the Zendesk ticket, or Support generated a one-time upload URL for each file. Neither path was built for multi-gigabyte bundles, and neither scaled with a support organization of roughly 60 people pulling customer diagnostics every day.

Two constraints made the problem hard to fix, and neither was under Redis's control. The first is the customer's network. Enterprise firewall policy varies unpredictably: many organizations block HTTP uploads outright, and at least one European customer blocks SFTP entirely. Any single-protocol intake would leave part of the customer base with no way to deliver the data.

The second constraint Redis imposed on itself. Support leadership refused to hold standing credentials for external uploaders. Long-lived customer passwords sitting on an internet-facing endpoint were an exposure the team would not carry. That ruled out the conventional answer, a static SFTP server with an account per customer, because those accounts never die.

What the fix had to do was clear before any product entered the picture. Intake had to exist per ticket, appearing when the ticket opened and vanishing when it closed. It had to be write-only, so an uploader could deposit a file and nothing more. It had to speak more than one protocol, so every customer's firewall had a way through. And because Redis does not control how many tickets get opened, all of it had to run through an API rather than through anyone's hands. Redis selected Files.com to be that intake layer.

A Folder Per Ticket, a Credential That Dies With It

When a support ticket opened, Redis's tooling called the Files.com REST API and created a dedicated folder named for the ticket. If the customer needed SFTP, the same API provisioned a temporary SFTP user scoped to that folder, authenticating with SSH keys generated for the case. When the ticket closed, the user was deleted. The credential never existed apart from the case it served.

The folder itself was a drop point, and only that. Its permissions let an uploader deposit the support package and nothing else, with no ability to browse or read anything on the site.

On the internal side, Files.com became the ingest and staging layer. Support engineers downloaded packages from the ticket folder and fed them into Redis's own analysis engine.

Two Ways In, Because Every Customer Firewall Is Different

Most customers take the easy route: a Files.com share link, a write-only HTTPS upload page that works in any browser with no account and no client to install. Plenty of enterprise networks block that. For them, the ticket carries the temporary SFTP credential instead, and their tooling uploads over a protocol their firewall already permits. Every route shares the same destination: the ticket's folder, reached through a Redis-branded Files.com domain, so a customer mid-outage uploads to an endpoint that reads as Redis.

The two protocols are not a convenience. They are the coverage model. Where HTTPS is blocked, SFTP works; where SFTP is blocked, HTTPS works; and no customer's network policy has to change before Redis can help them.

Roughly 250 GB of Diagnostics a Day, With No Password List to Manage

With the Files.com workflow in production, Redis replaced attachments and one-off upload URLs with an intake pattern that repeats itself on every case.

• Every customer has a working route in. A blocked protocol no longer stalls a support case, because the alternative protocol is provisioned by the same workflow.
• Zero standing credentials exist for external uploaders. Every SFTP account is created for one ticket and removed at close, so there is nothing to rotate and nothing for an access review to find.
• Files.com is the support team's daily pipeline. Engineers across the Americas, EMEA, and APAC pull diagnostic packages from it every day, moving about 250 GB of customer data through the platform daily.
• The next ticket requires no manual setup. The folder and the credential are an API call made by the ticket workflow itself, not a task on anyone's queue.

Intake Wired Into the Ticket Lifecycle Itself

Today, when a Redis customer's production database is in trouble, nobody works out how this particular company can get a file to Redis. The route exists the moment the ticket does, over whichever protocol the customer's firewall permits, and it stops existing when the case is resolved. A support engineer opens the folder named for the ticket and the data is there.

Redis did not solve external intake by standardizing its customers on one protocol or by relaxing its own security bar. It bound file access to the support case itself. That only works when creating and destroying an account is as cheap as opening and closing a ticket, and that is what the Files.com API made true: external file intake, at enterprise support scale, with no standing external accounts at all.