A Radio Broadcaster Runs Two Markets on Files.com Without a Second FTP Server

A radio broadcasting group spans radio, digital media, and publishing. Its syndication arm distributes news, talk, and weekend programming to affiliate stations across the United States, and the company also owns and operates radio stations of its own.

Nearly all of that programming moves as files. Affiliate stations and the company'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 the company a way to fold a second market into an existing market's operation without another FTP server or changes to broadcast workflows, leaving one operations owner to run both markets.

A Homegrown FTP Server With Fixed Per-Station Allocations

For one of the company's market operations, the file layer under live broadcast was a homegrown FTP server, a custom build maintained inside the company's IT group. Each station and show worked from a fixed allocation on it, and adding room, a station, or a whole market meant hands-on work on the server itself.

In syndicated radio the pull runs at fixed, published times, so the file layer has to have the audio in the folder before the automation comes for it, every day, for every station. The company wanted a platform where no station could run out of room.

The company's markets were also heading in a direction the server could not follow. The company wanted the option to run more than one market from a single hub. The file layer under that hub had to carry more stations, more shows, and more outside contributors without more administration.

That set the requirements for whatever replaced it. It had to run without a maintainer inside the company'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.

The company selected Files.com as the file backbone for that market's operation.

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

On Files.com, the unit of the company'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 the company's WideOrbit playout system. Downstream affiliates kept pointing their own pull software at the company'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 a second market proved the model. When the operations owner for the first market took on the company's operations in a second market as well, that market 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, One Site

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

• Per-station ceilings went with the server. There is no fixed allocation for a station to outgrow.
• One operations owner runs both markets from one site, an outcome the company 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.

Consolidation Stopped Being an Infrastructure Decision

Before Files.com, the file layer under the company's broadcasts in that first market was a custom server built for one market. Today, when the company folds a market into the 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 this broadcaster that platform is Files.com.