Urban One Retires the Personal GoDaddy FTP Account Behind Signage in 12 Studios

Urban One is a U.S. media company operating radio broadcasting, syndicated programming, television, and digital media. Its Radio One stations operate in 14 markets, while its Reach Media division syndicates programming nationally.

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 12 of Urban One'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 an interval that can be as tight as 30 seconds. Somewhere, a server has to answer those requests all day, every day.

The Screens Ran on a Server the Company Didn't Own

The server answering them was a GoDaddy FTP hosting account that one of Urban One's engineers had bought personally, on a domain he owned himself. It did the job. But it meant a system visible in 12 production studios depended on infrastructure that belonged to an employee rather than to the company: his account, his domain, and one more server for somebody to keep running. Company display assets lived at web addresses the company didn't control, and the whole arrangement rested on a single person.

A Browser That Can't Get Past a Login Page

The arrangement lasted because 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 only ways anyone saw to get that were a cheap external host or yet another server built and maintained just for signage, and the external host had already won that argument once.

By 2025, Urban One was already running core file operations on Files.com, which left the personal 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.

Twelve Studios, One Publicly Hosted Folder

Urban One 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, anywhere from every 30 seconds to every three hours, 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, and Nothing on a Personal Domain

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

• The on-air signage for 12 studios is served from the platform the company already runs, at addresses the company controls, instead of from an employee's personal 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.