Salem Media Runs Chicago and Detroit on Files.com Without a Second FTP Server

Salem Media Group is a multimedia company specializing in Christian and conservative content, spanning radio, digital media, and publishing. Its syndication arm, Salem Radio Network, distributes news, talk, and weekend programming from Dallas to affiliate stations across the United States. The company also owns and operates radio stations of its own.

Nearly all of that programming moves as files. Affiliate stations and Salem's own market clusters pull MP3 audio into their broadcast automation systems at precise, published times each day and play it to air. In this business, the file is the show. If the audio is not in the folder when the automation comes for it, the station has nothing to broadcast.

Files.com gave Salem a way to fold Detroit into Chicago's existing operation without another FTP server or changes to broadcast workflows, leaving one operations owner to run both markets.

The Show Depended on One Employee's FTP Server

For Salem's Chicago market operation, the file layer under live broadcast was a homegrown FTP server, a custom build put together and maintained by one employee in Salem's IT group. It had no hard limits. A station could fill its allocation and nothing would warn anyone. Files simply stopped arriving, and the first Salem heard of it was a client calling to say the show never came.

“You wouldn't have known that you hit the limit, and all of a sudden the client's calling, going, I can't get you the show.”

That was the server's standing failure mode, not a bad day. Every time a ceiling was reached, the outage announced itself through a customer, at the moment the audio was already due on air. In syndicated radio the pull runs on a fixed daily schedule, so a file that is not there at pull time is a missed airing, discovered by the people Salem exists to serve.

The server survived the way homegrown infrastructure usually does: it worked most days, and one person kept it running. But Salem's markets were heading in a direction the server could not follow. The company runs its market clusters with small staffs, and the operating model is consolidation, with more markets folding into fewer hubs run by leaner teams. The file layer under those hubs had to carry more stations, more shows, and more outside contributors, with less administration rather than more.

That set the requirements for whatever replaced it. It had to run without a maintainer inside Salem's IT group. It had to keep every station, show, and contributor in its own lane on one shared platform. It had to speak FTP and SFTP, because the playout tooling on the other end pulls audio over those protocols. And it had to absorb an entire additional market without anyone standing up new infrastructure.

Salem selected Files.com as the file backbone for the Chicago operation.

One Files.com Site, With a Folder Set per Market

On Files.com, the unit of Salem's operation is the folder set, not the server. Files.com's folder-level permissions and per-user root folders keep each station, show, and workflow in its own lane: a user lands in their own directory and sees nothing else. That separation makes it safe to put affiliate stations and outside contributors on the same platform, each reaching only the audio that belongs to them.

On the pull side, nothing at the stations changed. Radio Spider continued to pull audio out of Files.com over FTP and SFTP on its usual schedule and feed Salem's WideOrbit playout system. Downstream affiliates kept pointing their own pull software at Salem's folders and taking shows straight into their broadcast systems. Files.com replaced the server underneath the workflow, and the workflow itself never had to move.

Then Detroit proved the model. When Eric Thomas took on Salem's Detroit operations alongside Chicago, Detroit did not get a server of its own. Its workflows were folded into the existing Files.com site as another permissioned folder set with its own scheduled automations, and both markets have run from that single site, under one operations owner, ever since.

Two Markets, One Operations Owner, and No Silent Ceilings

With Files.com in production as the file backbone, Salem replaced a server one employee maintained with a managed platform its broadcast tooling pulls from every day. What changed:

• The silent-ceiling failure went with the server. There is no homegrown limit for a station to hit without warning, and an affiliate's phone call is no longer Salem's monitoring system.
• One operations owner runs both the Chicago and Detroit markets with a leaner team, an outcome Salem credits to Files.com's reliability and its granular user access controls.
• The same platform absorbed a growing, heavily active user base under the same owner.

“I don't see another solution with the amount of workload that I'm doing.”

Consolidation Stopped Being an Infrastructure Decision

Before Files.com, the file layer under Salem's Chicago broadcasts was one employee's custom server, and its failures reached Salem through an affiliate asking where the show was. Today, when Salem folds a market into the Chicago hub, that market arrives as a permissioned folder set on the same Files.com site. Its playout tooling pulls over the same protocols, its contributors land in their own folders, and the same operations owner runs it alongside everything else. A broadcast group consolidating markets does not need a server per market. It needs one governed platform each market can land on, and for Salem that platform is Files.com.