How We Built a 24/7 Radio Network With No Studio and No Night Shift
Running one radio station around the clock used to take a building, a staff, and a lot of money. We run two — with no studio, no overnight crew, and no ops team watching a board at 3 AM.
This is the story of how the Righteous Radio platform was engineered: the streaming infrastructure, the automation, the monitoring, and the discipline that keeps it on the air.
The problem
The goal was simple to say and hard to build: a professional, always-on, multi-station radio network that a small team could operate without being chained to it.
That meant five problems to solve:
1. Streaming — get audio to listeners reliably, at scale.
2. Automation — decide what plays and when, with no daily manual scheduling.
3. Operations — monitor everything, fix what can be fixed automatically, and get a human involved only where judgment matters.
4. Growth — analytics you can trust, SEO that scales, and native mobile apps.
5. Repeatability — build it once, so the second station doesn't cost as much as the first.
Streaming infrastructure: boring on purpose
The streaming layer is built from real components: a streaming media server handling live audio distribution, fed by an automation engine producing a continuous, gapless audio source.
Multi-bitrate delivery. Each station serves multiple simultaneous streams at different quality tiers — a high-quality feed for broadband and WiFi, a lighter feed optimized for cellular. The infrastructure handles this, not the listener's device. Someone on a phone in a parking lot and someone on home WiFi both get a stream tuned to their connection.
Never exposed raw. The streaming server's actual port is never visible to the public. All listener traffic goes through HTTPS on the standard web port and routes internally. No mixed-content warnings, no port numbers in anyone's player.
The listener-count bug. Mid-project, real-time listener counts silently dropped to near zero — while the stream itself was clearly live and working. The root cause wasn't our code. The streaming software in use had no support for reading real client IPs through a reverse proxy: every listener arrived via localhost, and the server couldn't unpack the actual origin. The fix was migrating to an actively maintained build of the same server software with proper forwarded-IP support. Total listener-facing interruption during the swap: under four seconds.
The lesson: infrastructure claims have to be verified against ground truth, not just "the dashboard shows a number."
Automation: the schedule is data, not code
What airs and when is driven by structured configuration — not logic baked into the playback engine. The on-air schedule, rotation rules, and break cadence can be changed by editing data, not redeploying code. For a solo-operated project, that's the difference between a five-minute tweak and a development cycle.
Rotation rules are tunable. How often music, station jingles, and spoken segments interleave is configurable per station — a ratio for songs-to-jingles, a separate cadence for breaks — adjustable without touching the engine.
Operating modes, not just on/off. The platform supports distinct modes (for example, a music-and-jingles mode versus a full mode with breaks and segments) that toggle live. Every content subsystem checks the current mode before producing anything — because during an audit, we found a secondary automation process bypassing the primary quiet flag. It wasn't broken; it was checking a different source of truth than everything else. The fix was unifying every subsystem behind one single mode check — one place in the codebase that answers "should anything be playing right now," which every component is required to ask. A textbook distributed-state bug: not a crash, just two systems disagreeing about reality.
Operations: monitoring that acts, not just alerts
The platform runs continuous automated health checks against its own critical services, and issues are triaged by severity:
- Low-risk, high-confidence problems — a service that's demonstrably down — get fixed automatically. No human in the loop, because the fix is safe and the diagnosis is unambiguous.
- Higher-risk actions — like restarting a core broadcast service, which briefly interrupts every live listener — require human approval. The monitoring system generates a one-time, time-limited approval link with a confidence score attached to its own diagnosis, so the person reviewing it knows how certain the system is.
The restart race condition. Two mornings in a row, the stream briefly dropped for all listeners at once. Root cause: the host OS's own automatic security patching was restarting the streaming server and the automation engine at the exact same moment whenever a shared library got patched — an OS-level tool treating two order-dependent services as interchangeable. The fix was restart hooks that make the automation engine health-check the streaming server before restarting itself, regardless of what order the OS chooses. We verified it through the OS tool's own restart-selection logic — without forcing a live outage to prove it.
Backup discipline. Every production change — code, configuration, or system-level — is preceded by an automatic backup and followed by live verification before it's considered complete. Not a habit. Part of the deployment process itself.
Built for two stations from the start
The platform was designed so a second station could launch on the same core engine without duplicating the engineering. Streaming infrastructure, automation logic, and the content pipeline are all shared; station-specific configuration — branding, music catalog, rotation rules — layers on top.
The second station reused roughly 80–90% of the first station's engineering investment. That's the economics you want from a platform built to scale, not a one-off build.
Analytics: computed from logs, not wished into existence
Listener geography and reach figures are computed from real server access logs — aggregated every few minutes, so the "countries reached" figure is genuinely live, not manually maintained.
One source of truth. Reach figures are computed once and read everywhere they're displayed — dozens of pages across two codebases pull from a single function. That was a deliberate choice after an audit found stale, inconsistent figures hardcoded in multiple places.
Two methodologies, on purpose. The platform tracks listener totals two different ways — a continuous presence method and a session/log-based method — because they answer different questions. Rather than hiding the difference, the system keeps both visible and understood.
Grant-ready by design. Because the analytics are real and auditable, the pipeline supports funding and grant reporting for the nonprofit side of the organization. That requirement shaped the architecture from the start — it wasn't bolted on later.
SEO that scales through templating
The station sites run 500+ geo-targeted landing pages generated from a single shared template — so a content or schema fix made once propagates to every page instantly, instead of requiring hundreds of manual edits.
Structured data (schema.org markup for Organization and RadioStation) is deployed site-wide, the XML sitemap is maintained, and an internal linking architecture connects the city pages, blog content, and core pages. Reach figures and key stats are injected into page titles, meta descriptions, and structured data dynamically — so SEO-facing content never silently goes stale.
Native mobile apps
Each station has a dedicated native mobile app for iOS and Android, built on a shared cross-platform framework and connected to the same live streaming and metadata infrastructure as the websites — app-store discoverability and a persistent listening surface beyond the browser.
What this demonstrates
Small teams can run systems that used to require large ones — if the automation and monitoring layers are taken as seriously as the feature layer.
Specifically: production streaming infrastructure from real components, not a no-code platform. Automation driven by data, not hardcoded logic. Multi-station architecture from a shared core, without a second full build. Monitoring that heals itself where it's safe and asks a human where it isn't. Analytics that are auditable, not decorative. SEO that scales through templating.
The stream is the easy part. Everything around it is the engineering.
