A Radio Broadcaster Serves Studio Signage in a Dozen Studios From Files.com Public Hosting

A US radio broadcaster operates radio stations in more than a dozen markets alongside syndicated programming and digital media.

Radio output comes out of studios, and a working studio has screens: displays showing the station's call letters, the time, the on-air light, and rotating imagery. In a dozen of the broadcaster's studios, those displays run on Raspberry Pi devices with WallTime signage software. Each device is, in effect, a bare browser. It requests an HTML page and a set of PNG images from a web address, renders them, and asks again on a short interval. Somewhere, a server has to answer those requests all day, every day.

One More Server, Kept Running Just for Signage

The server answering them was a separate external hosting account: a GoDaddy FTP hosting plan that existed for nothing but the signage. It did the job. But it meant a system visible in a dozen production studios ran on a server outside the platform the company's file operations already ran on: one more account to renew, one more set of web addresses to keep track of, and one more server for somebody to keep running. The broadcaster wanted the signage served from infrastructure it already operated, at addresses under its own management.

A Browser That Can't Get Past a Login Page

The obvious fixes didn't fit. The signage browser does exactly one thing: request a URL and render what comes back. It cannot enter a username or click through a login screen, and every standard path into a company file platform sits behind exactly that. Point the displays at an authenticated address and they stop at the login page. So the assets needed genuinely public URLs, served continuously over HTTP or HTTPS with no credentials at all. The conventional ways to get that are an external host or yet another server built and maintained just for signage.

By 2025, the broadcaster was already running core file operations on Files.com, which left the external hosting account as a separate server doing a job the company's own platform could take over. What the signage required was specific but small: files served around the clock at direct public URLs, to a client that will never log in. Files.com Public Hosting is built for exactly that, so the engineering team moved the assets there instead of building anything new.

A Dozen Studios, One Publicly Hosted Folder

The broadcaster placed the signage HTML and PNG files in a Public Hosting folder on its existing Files.com site and pointed each studio's device at the direct HTTPS addresses. Each display pulls on its configured interval and renders what comes back: call letters, clocks, on-air lights, rotating imagery. Nothing was installed on the devices and nothing about how they work changed. They were given a different address to ask.

One Less Server in the Estate

With Files.com Public Hosting feeding the fleet, the broadcaster retired the GoDaddy account and the server behind it.

• The on-air signage for a dozen studios is served from the platform the company already runs, at addresses the company manages, instead of from a separate hosting account.
• One less server sits in the estate: no separate account to renew, and no separate system for anyone to maintain.
• The workload was absorbed with no new infrastructure. The next always-on public feed, whether for a display, a device, or a script that can't log in, is a folder setting on Files.com rather than a server build.

The Server Nobody Had to Build

The lesson travels beyond broadcasting: a file platform is usually judged by the authenticated exchange it governs, but Files.com also turned out to be the always-on public web server this fleet of studio devices needed. The odd workload never required its own server. It required a folder.