Intro

Creating a self-hosted web radio is not a really daunting task but there are some things to take into consideration. Since it’s a new web radio and has nearly no exposure, the overhead costs need to minimal.

The Server

After a bit of research I found Azuracast, a neat software stack put together to make a radio in a box, as the developers market it. So the server that will host the actual stream is pretty underwhelming but the cost benefit analysis is worth it & it will serve it’s purpose very well. Now choosing a host was a no brainer I went with linode, they have really good prices for this kind of project.

Specs

• Linode 2 GB
• 10$/Month
• 2GB RAM
• 1 CPU
• 50GB storage
• 2 TB monthly transfer
• 40/2 Gbps network In/Out

The minimum specification that Azuracast needs is:

• A 64-bit x86 (x86_64/amd64) or ARM64 CPU
• At least 2GB of RAM
• 20GB or greater of hard drive space
• A computer/server capable of running Docker

So with that out of the way it’s time to deploy Azuracast to the server.

Deployment of Azuracast

The host operating system is Debian 10 with docker installed to run Azuracast. Azuracast was in the linode marketplace, so it was just a matter of creating the server and let the automated system deploy the software stack of Azura. And yes docker does put an overhead on the resources of this little server but it will only serve one stream.

The Azuracast software stack

• Lquidsoap - An AutoDJ that keeps the tunes streaming.
• Icecast 2.4 - (Icecast-KH on supported systems) - A broadcasting frontend.
• SHOUTcast 2 DNAS - An alternate broadcasting frontend.
• NGINX - A webserver a proxy.
• MariaDB - A database.
• PHP 7 - General purpose programming language used for the website.
• InfluxDB - A database for capturing time-series based statistics.
• Redis - A database for session management and caching

Screenshot of the Azuracast backend.

Will it scale?

Another thing to take into consideration is the scaling of this project.

Will this server choke under heavy user traffic?

Well, after some stress tests done on icecast this little server will serve audio streams to about 500+ users with out a hitch. In the tests the stream started to breakup and not perform at the 1000+ users point. So the cost benefit is a clear win.

The good people over at The Icecast Project have put together this very neat load test that I used to run the stress test. Unfortunately at the time of the doing the stress test I did not think ahead and did not capture any screenshots while doing it. However I do have the network load of the server from the backend of linode, so here it is :
It peaked at around 9.6Mb/s. So we’re good with bandwith handling.

Okay so the stream server is performing “good”, I did however find that at some points the server load would go over 1.0 mark which is 100% CPU load. I fixed this issue in a hacky way by adding a swapfile to the host server which allowed the host RAM to dump whatever it did not need at present into the swapfile. After I let it run for a few hours it had settled at 40% to 50% CPU load, acceptable for our use case.
Below is a screenshot of HTOP and the load averages at 1min, 5min and 15min. As you can see it settled at ~ 45% CPU load/usage.

The Web Server

Now the web server runs on another instance so the backend & the frontend are seperate. Since this is a budget project the web server is nano in specs. After all it’s just Apache serving webpages.

To have a database driven site or not?

The go to platform for small independent sites is Wordpress the developers there turnout an exellent product and it’s really a reliable platform. However since it’s one of the most popular platforms it has a very big attack vector and the database can grow to be a behemoth. I wanted to avoid all of these hurdles so I decided to go with HUGO.

HUGO if you are not familiar is a static site generator framework. In other words you create you’re site and content and HUGO spits out everything in HTML. What you gain by running a static site is:

• It’s lightweight
• Fast
• Secure
• HUGO can handle taxinomies & pagination so you can organise you’re sites content
• Less point’s of failure

The last point is crucial in my book for security reasons. This however does not mean that you don’t have to abide by best security practices to secure your webserver(this is a whole other writeup btw).
Below automated “drive-by” scans looking for exploits.

• This is the nature of the modern internet. Look at all those 404’s hitting a brick wall of nothingness. Marvelous.

So for our usecase running a static site is perfect because what we’re outputting besides text/pictures/audio&video in HTML is just the media radio player & recently played tracks.

Webserver specs

• Nano 1 GB
• 5$/Month
• 1 GB RAM
• 1 CPU
• 25GB storage
• 1 TB monthly transfer
• 40/2 Gbps network In/Out

The frontend of the webradio

Homepage The radio page

Visit athensnoise radio

Updating Content

We have our slick & fast static site, how will the content be updated?

The conventional way would be to connect via SFTP and update the content that way, but that method has way to many steps if you are updating frequently.

Rsync to the rescue

Rsync is a very efficient little tool for syncing files between computers, by compairing the modification times and sizes of files. I use it daily for my local workstation backups. I wrote a one-liner bash script syncing the local directory with the remote location, rsync connects via SSH and updates the changed files. Here is the script :

#!/bin/bash
rsync /home/user/hugo-project/site/public/ -av -e  ssh user@yourhost.com:/var/www/html/yoursite.com/public_html

Save it as deploy.sh & make it executable. Done.
Now I can just run ./deploy.sh and the contents of the site will update with the made changes.

Closing notes

This is a small writeup on how I went about and setup a webradio & a website.
I would like to give a whole hearted thank you to my friend & mentor Ares who supported and guided me in any questions that I had through the whole process of creating this webradio. Visit his site Logicwrap