How I built GTA Radio
From a personal technical experiment to a working online radio system.
The project at a glance
- Started as a personal technical experiment to listen to GTA-style radio in the car.
- Runs on a Debian server at home, with the radio logic written in Python.
- Reached from the internet through Cloudflare Tunnel.
- A browser-based player for desktop and mobile, plus a direct stream for media players such as VLC.
- Four games in the library: Vice City, San Andreas, GTA IV and GTA V, each station with its own artwork.
Where it started
I started GTA Radio as a personal technical experiment: could I recreate the feeling of classic GTA radio as a continuous online listening experience that I could build, run and maintain myself?
What began as an experiment grew into a larger project involving local audio, Python, browser-based playback, mobile compatibility, streaming and server infrastructure.
Local audio
The project is designed around audio files stored locally on my server. This gives me direct control over the order, station structure and way the broadcast is assembled.
Instead of depending on an external playlist service, the radio server can select and play material directly from the project files.
Each station’s audio is stored together with its artwork. The player uses that artwork to show which station is playing.
The server
The radio system runs on a Debian server. Python handles the web server and the radio logic, while the public domain is connected to the server through Cloudflare Tunnel.
This setup means I can develop and test the project directly on the machine that is actually running the radio.
The browser player
The player is intentionally simple. A listener should be able to open the page and start listening without installing a dedicated application.
Browser compatibility has become one of the more interesting parts of the project. Desktop Chrome, Safari and mobile browsers do not always handle long-running audio in exactly the same way.
Interruptions and reconnecting
A real radio stream needs to survive normal interruptions. Phones lock, browsers suspend tabs, connections change and listeners refresh pages.
I therefore treat reconnecting and playback continuity as part of the project rather than as an afterthought.
What I learned
The project has taught me that a small web application can involve many different layers at once: file handling, audio processing, HTTP, browser behaviour, networking, Linux services and DNS.
That is one of the reasons I continue documenting the project. The technical problems are often just as interesting as the final radio experience.
Design decisions and trade-offs
Plain HTTP streaming. The stream is delivered over ordinary HTTP so that any browser or media player such as VLC can open it. The trade-off is that the project must handle reconnects itself, which is why interruptions are treated as a core feature.
Local control. Keeping the audio on my own server gives full control over order and structure, at the cost of running and maintaining the machine myself.
Simple interface. The player does little by design. The listener mostly wants sound, and a smaller interface is easier to make reliable on phones.
How the project is maintained
Changes are recorded on the changelog, and the background to earlier decisions is in the development history. For the thinking behind the stations, read the articles.