An internet radio station is three components in a line. A source client produces the audio, either from a live input or from a scheduled library. A streaming server takes that single feed and serves copies of it to every listener. The listener's player requests the stream over HTTP and decodes it. Almost every question a new broadcaster has about software is really a question about the middle component.
Icecast is the open source option, maintained by the Xiph.Org Foundation and released under the GNU General Public License. It organises output into mount points, so a single server instance can carry several streams at different bitrates or codecs on separate paths. It handles MP3 and AAC alongside the Xiph codecs, Ogg Vorbis, Opus, and FLAC, which matters for anyone intending to run a genuinely lossless feed, since a large share of hosted platforms will not carry FLAC at all. It is stable, it is well documented, and it does nothing beyond serving streams, which is either its main strength or its main limitation depending on what else you need.
SHOUTcast came first and left a permanent mark on the format. The ICY metadata protocol carrying now playing information on the majority of internet stations is a SHOUTcast invention, and the header names still begin with those three letters on servers that have no other connection to the product. The current DNAS server is proprietary with a free tier, and it remains widely deployed, particularly among stations that have run since the early 2000s and never had a reason to migrate.
AzuraCast is a different kind of choice, because it is not a competing server so much as a complete station in one installation. It wraps Icecast or SHOUTcast for delivery, uses Liquidsoap underneath for playout, and adds a web interface covering media library management, scheduled playlists, rotation rules, live DJ handover, listener statistics, and a public player page. It is open source and installs from a Docker container. For someone who wants a station running this week rather than a stack to maintain, it removes most of the work, at the cost of running considerably more software than a bare Icecast instance.
Liquidsoap deserves mention on its own, since it does the actual programming in most automated stations, AzuraCast included. It is a scripting language built for audio scheduling, and it expresses ideas that are awkward elsewhere: play from this rotation but never repeat within two hours, crossfade only when both tracks allow it, interrupt for a live source the moment one connects and fall back cleanly when it drops. Anyone applying the rotation and clock ideas from our guide on building a radio hour will end up writing Liquidsoap or paying for something that generates it.
Bandwidth is the constraint that catches people out, and the arithmetic is simple enough to do before committing to a host. Outbound bandwidth equals bitrate multiplied by concurrent listeners. A 128 kbps stream with 100 simultaneous listeners consumes 12.8 Mbps sustained, which across a month of continuous operation is roughly 4 TB of transfer. The same audience on a 320 kbps stream needs 32 Mbps and around 10 TB. A FLAC feed averaging 1 Mbps needs about ten times the 128 kbps figure. Listener counts scale the bill, not library size, and a station that succeeds unexpectedly discovers this quickly.
The reasonable default for most people starting out is AzuraCast, because it collapses the whole chain into one install and can be moved off later. A bare Icecast instance with Liquidsoap makes sense for anyone who wants to control the stack, is comfortable on the command line, or needs a codec or configuration the packaged option does not expose. SHOUTcast is mainly worth choosing when an existing workflow already depends on it.
References:
Xiph.Org Foundation. Icecast 2 Documentation.
AzuraCast. Official Documentation. docs.azuracast.com.
Savonet. Liquidsoap Documentation. liquidsoap.info.
Pantos, R., & May, W. (2017). HTTP Live Streaming. RFC 8216, Internet Engineering Task Force.