How to set up an Icecast2 server and mountpoints

How to Set Up an Icecast2 Server and Mountpoints (2026) Guide

by

Setting up an Icecast2 server with working mountpoints is one of the most reliable ways to broadcast audio over the internet from your own infrastructure. I run Icecast2 in my home lab for two stations (a 24/7 lo-fi stream and a live DJ booth), so this guide reflects what actually works after hundreds of hours of uptime, not just what compiles on a clean install.

In this 2026 walkthrough, I’ll show you how to install Icecast2 on Ubuntu, walk through the icecast.xml configuration file, set up authentication passwords, create Icecast2 server mountpoints for both Ogg Vorbis and MP3, connect source clients like VLC and DarkIce, and harden the server for production. I also include the troubleshooting checklist I wish I had when I first hit “connection refused” on a mount.

Table of Contents

What Is an Icecast2 Server?

An Icecast2 server is an open-source audio streaming server written in C that supports Ogg Vorbis, Opus, MP3, and WebM streams. It runs as a daemon on Linux, accepts an incoming audio feed from a source client, and re-distributes that audio to any number of connected listeners. Free Stream Hosting uses the same core Icecast2 codebase that powers thousands of community radio stations, college stations, and indie podcasters worldwide.

The way Icecast handles audio is simple. A source client (VLC, DarkIce, ezStream, Liquidsoap, OBS) connects to the server on a specific port, authenticates with the source password, and pushes live audio into a named endpoint called a mountpoint. Listeners then connect to that same mountpoint URL and receive the stream in their player. Each stream on one Icecast instance lives at its own unique mountpoint path, like /stream.ogg or /radio.

The mountpoint is the heart of Icecast2 routing. Every stream you broadcast must have a unique mountpoint name, and that name also tells listeners which codec they’re getting. A listener pointing their player at http://yourserver:8000/stream.ogg will get an Ogg Vorbis stream; pointing to http://yourserver:8000/mystream will get whatever the source client pushed (often MP3 unless the extension says otherwise).

Prerequisites for Setting Up an Icecast2 Server

Before you install anything, run through this quick checklist. I learned the hard way that skipping the bandwidth check makes for choppy streams.

  • A Linux server running Ubuntu 20.04 LTS or newer (Debian 11+, CentOS Stream 9, and Arch Linux all work with minor command differences)
  • Root or sudo access to install packages and edit system files
  • A static public IP address, or a domain pointing to your server, if listeners outside your LAN will connect
  • At least 1 Mbps of upload bandwidth per 32 simultaneous MP3 listeners at 128 kbps (rough rule of thumb)
  • A terminal you are comfortable in (Icecast has no GUI setup wizard)
  • A source client available to push audio: VLC, DarkIce, ezStream, or Liquidsoap
  • Port 8000/tcp open on your firewall (Icecast’s default listening port)

If you’re hosting for a small local audience under 20 listeners, a $5/month VPS works fine. For anything approaching 100+ concurrent listeners, get an unmetered or high-bandwidth VPS or a dedicated server, because streaming eats bandwidth fast.

How to Install Icecast2 on Ubuntu

Installing Icecast2 on Ubuntu is a single apt command because it lives in the universe repository. I’ve refreshed these steps on three fresh Ubuntu 22.04 installs so far this year and they always work the same way.

Step 1. Update your package index so you pull the latest stable release:

sudo apt update
sudo apt upgrade -y

Step 2. Install Icecast2 with the recommended metapackage:

sudo apt install icecast2 -y

Step 3. During installation Ubuntu will pop up a configuration dialog asking for hostname, source password, relay password, and admin password. Type these in now or skip them; we’ll set real values in icecast.xml next. If the dialog is skipped, the service still installs and runs with defaults.

Step 4. Enable and start the Icecast2 systemd service:

sudo systemctl enable icecast2
sudo systemctl start icecast2

Step 5. Open port 8000 on the firewall if you’re using ufw:

sudo ufw allow 8000/tcp
sudo ufw reload

Step 6. Verify the service is listening:

sudo systemctl status icecast2
ss -lntp | grep 8000

If ss shows icecast2 bound to *:8000, you have a working install. Browse to http://your-server-ip:8000 and you should see the Icecast2 welcome page with a “No source connected” notice. That’s correct; nothing is streaming yet.

Understanding the icecast.xml Configuration File

Every Icecast2 server reads its full configuration from a single XML file, traditionally located at /etc/icecast2/icecast.xml on Debian/Ubuntu or /etc/icecast.xml on Arch and other distributions. This file controls authentication, networking, logging, paths, mountpoint limits, and the admin web interface. If you only ever touch one Icecast file in your life, it’s this one.

Before editing, back it up so a typo doesn’t lock you out:

sudo cp /etc/icecast2/icecast.xml /etc/icecast2/icecast.xml.bak
sudo nano /etc/icecast2/icecast.xml

The configuration file has five top-level sections you’ll come back to repeatedly:

  • <location>, <admin>, <server> — admin contact info, displayed in the web interface
  • <limits> — client caps, queue size, source timeouts, burst size
  • <authentication> — passwords for source, relay, and admin users
  • <listen-socket> — IP and port the server listens on (default port 8000)
  • <paths> — log, web root, admin xsl, and other filesystem locations

Defaults are sane for experimentation, but for any server that touches the public internet you must change at least the passwords, the bind address, and the server hostname.

Configuring Authentication Passwords

The <authentication> block in icecast.xml holds three passwords, each with a distinct job. New users routinely confuse them, so here is exactly what each one does:

  • source-password: used by source clients (VLC, DarkIce) to authenticate when pushing a stream into a mountpoint
  • relay-password: used by other Icecast servers pulling your stream (rare, only needed for relays)
  • admin-password: used to log into the Icecast2 admin web interface at /admin/

Open the section and change all three to long random strings. The simplest way I generate these is with openssl rand -hex 16 for each role.

<authentication>
    <source-password>YOUR_SOURCE_PASSWORD_HERE</source-password>
    <relay-password>YOUR_RELAY_PASSWORD_HERE</relay-password>
    <admin-password>YOUR_ADMIN_PASSWORD_HERE</admin-password>
</authentication>

Never reuse the admin password as the source password. If a malicious source client gets your source-password, the attacker can broadcast whatever they want on your server. Sharing the admin password in IRC or forums is the single most common Icecast2 break-in vector.

Save the file, then restart the service for changes to take effect:

sudo systemctl restart icecast2

How to Create and Configure Mountpoints

Mountpoints are how Icecast2 routes audio. Every stream your server broadcasts occupies one mountpoint, and you choose the mountpoint name yourself. There are two flavors of mountpoints you’ll work with on Icecast2 server mountpoints setups.

Dynamic mountpoints are created automatically the first time a source client connects and authenticates. They live as long as the source keeps streaming. Most single-purpose Icecast servers only ever use dynamic mountpoints because the source client supplies the path.

Static mountpoints are declared in icecast.xml with their own <mount> block. Use these when you need predictable URLs, max listener limits per stream, fixed bitrate enforcement, or fallback files (a “stream offline” audio loop).

Mountpoint names should follow the convention of including the stream type as a file extension. Append .ogg or .opus for Ogg Vorbis/Opus streams, and .mp3 for MP3 streams. This matters because players like Winamp, foobar2000, and browser tabs rely on the extension to pick the correct decoder.

Example static mountpoint block for a 128 kbps MP3 main stream:

<mount type="normal">
    <mount-name>/stream.mp3</mount-name>
    <max-listeners>200</max-listeners>
    <bitrate>128</bitrate>
    <burst-size>65536</burst-size>
    <fallback-mount>/offline.mp3</fallback-mount>
    <fallback-override>1</fallback-override>
</mount>

Example static mountpoint block for an Ogg Vorbis lo-fi stream with fallback:

<mount type="normal">
    <mount-name>/lofi.ogg</mount-name>
    <max-listeners>50</max-listeners>
    <fallback-mount>/lofi-fallback.ogg</fallback-mount>
    <fallback-override>1</fallback-override>
</mount>

Fallback mountpoints are the single best feature for a public station: when the live source disconnects, Icecast2 automatically serves an alternate stream so listeners hear “stream offline” music instead of silence. Set <fallback-override>1</fallback-override> if you want fallback to take over even when the source is silent but still connected.

If you want to host two music stations and one talk channel on the same server, just add three <mount> blocks with different <mount-name> entries. That’s the real advantage of Icecast2 over SHOUTcast: one server, many simultaneous Icecast2 server mountpoints, only paying for one VPS.

Connecting a Source Client to Your Icecast2 Server

With mountpoints and passwords set, the next step is feeding live audio into the server. Below are the three source clients I recommend, ordered by typical use case.

VLC (good for ad-hoc live broadcasts). Open VLC, go to Media → Stream, add your input source (file, playlist, capture device, or desktop), and on the destination step choose HTTP, paste the mountpoint URL and password.

http://your-server-ip:8000/stream.mp3
Mountpoint: /stream.mp3
Password: YOUR_SOURCE_PASSWORD

Click Stream. VLC will connect to Icecast and start pushing audio in roughly 2 seconds. If it times out, your source password is wrong or port 8000 isn’t reachable from the source machine.

DarkIce (the standard for 24/7 radio automation). DarkIce is a lightweight daemon that takes audio from ALSA or JACK and pushes it nonstop to Icecast2. Install it with sudo apt install darkice and create /etc/darkice.cfg:

[general]
duration = 0
bufferSecs = 5

[input]
device = hw:0,0
sampleRate = 44100
bitsPerSample = 16
channelCount = 2

[icecast2-0]
bitrateMode = cbr
bitrate = 128
format = mp3
server = localhost
port = 8000
mountPoint = /stream.mp3
password = YOUR_SOURCE_PASSWORD

Restart DarkIce after editing: sudo systemctl restart darkice.

ezStream (for static playlists of MP3 files). EzStream reads a playlist of audio files and streams them sequentially into Icecast2, ideal for automated “radio that just plays MP3s” deployments. Config example:

<ezstream>
  <streams>
    <stream>
      <mountpoint>/stream.mp3</mountpoint>
      <password>YOUR_SOURCE_PASSWORD</password>
      <url>http://localhost:8000/stream.mp3</url>
      <playlist>/etc/ezstream/playlist.txt</playlist>
    </stream>
  </streams>
</ezstream>

Testing Your Icecast2 Server and Mountpoints

Once a source client is connected, verify everything is working. Three checks catch 95% of setup mistakes.

Check 1: the admin interface. Browse to http://your-server-ip:8000/admin/ and log in with username admin and the admin-password from your config. You should see your mount listed under “Mountpoints” with a non-zero current listener count.

Check 2: stats.xsl raw stats. The stats.xsl page at http://your-server-ip:8000/status-json.xsl returns machine-readable XML with every active mountpoint, listener count, and bytes sent. Useful for monitoring scripts.

Check 3: actual playback. Open http://your-server-ip:8000/stream.mp3 directly in VLC, mixxx, browser, or a phone. If audio plays, your entire chain works: source client connects, Icecast2 serves the stream, listeners can connect.

If the admin page shows zero listeners but your source is connected, your listener is most likely connecting from the same public IP as the server without a NAT loopback rule. Test from a phone on cellular data to confirm.

Running Icecast2 at Startup with systemd

The Icecast2 systemd unit is enabled automatically by the apt post-install script, but if you installed Icecast2 from source, compiled it yourself, or run it inside Docker, you may need to enable it manually. systemd is the modern init system on Ubuntu, Debian, CentOS, Arch, and Fedora, and “how do I make Icecast start at boot” is one of the top asked questions on the Icecast forums.

Check current status:

sudo systemctl status icecast2

Enable auto-start on boot:

sudo systemctl enable icecast2
sudo systemctl daemon-reload

Common operational commands you’ll reuse weekly:

  • sudo systemctl start icecast2 — start now
  • sudo systemctl stop icecast2 — stop gracefully
  • sudo systemctl restart icecast2 — restart (use after editing icecast.xml)
  • sudo systemctl reload icecast2 — reload config without dropping listeners (supported in Icecast 2.4.4+)
  • journalctl -u icecast2 -f — stream live logs

The reload command is underrated. It lets you change passwords and listen-socket settings without disconnecting active listeners, which matters when you’re running a station people are tuned into.

Security Best Practices for Production Servers

Default Icecast2 is fine for a five-minute LAN test, but exposing it to the internet requires hardening. I run through this list on every new deployment and have not had a single takeover in the past three years.

1. Change every default password. Source, relay, and admin passwords should all be unique 20+ character random strings. Use openssl rand -hex 24.

2. Bind to a specific address. In your <listen-socket>, set <bind-address>0.0.0.0</bind-address> only if you must listen on all interfaces. For a server behind a reverse proxy, bind to 127.0.0.1 so only nginx or HAProxy can reach Icecast.

3. Put Icecast2 behind a reverse proxy for SSL. Use nginx to terminate HTTPS and stream to listeners over HLS or proxy Icecast’s HTTP output. A minimal nginx snippet:

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

4. Restrict the admin URL. Mount the admin interface on a path or port only accessible to you. Set <adminroot>/secret-admin</adminroot> in the paths section, then bookmark that URL and never share it.

5. Disable the YP directory listing unless you actually want to be listed on Icecast’s public radio directory. Set <directory><yp-url-timeout>0</yp-url-timeout></directory>.

6. Set client and source connection limits. In the <limits> block, cap <clients>500</clients> and <sources>10</sources> to your actual capacity. Limits blunt brute-force and flooding attempts.

7. Run Icecast2 as a dedicated unprivileged user. Most distribution packages already do this. If you built from source, create a system user icecast, chown the config and log directories to that user, and run with User=icecast in your systemd unit.

Troubleshooting Common Icecast2 Problems

Below are the errors I see most often on Icecast forums and in my own deployments, with the actual root cause and fix. If your Icecast2 server mountpoints aren’t working, start here.

“Connection refused” when the source connects. The Icecast service isn’t running, or port 8000 is blocked. Run systemctl status icecast2, then ss -lntp | grep 8000 to confirm it is bound. On cloud VPS providers the default security group or network ACL often blocks 8000; add an inbound rule.

“Mountpoint not found” on listener side. Your Icecast2 server mountpoints block names don’t match the URL the listener used. Names are case-sensitive. /stream.mp3 is not the same as /Stream.mp3. Verify by visiting /status-json.xsl.

“Authentication required” but the password is right. You probably have an <mount> block but the source client’s URL doesn’t include the mountpoint or includes a typo. The default username for source clients is source; check that your VLC/DarkIce username field is set to that, not blank.

Source connects, but listener count stays at 0. Almost always a NAT loopback issue. The listener is trying to connect from inside the same network as the server. Test from outside (phone on cellular, a friend’s house, a remote machine) before debugging anything else.

Stream disconnects whenever the source client stops. This is correct behavior. To keep listeners connected when offline, configure a fallback mountpoint (covered above) so Icecast2 automatically plays a fallback file.

“Config file not found” on startup. Different distributions expect different paths. Debian/Ubuntu uses /etc/icecast2/icecast.xml; Arch uses /etc/icecast.xml; CentOS stream packages sometimes use /etc/icecast2.xml. Check the EnvironmentFile in /lib/systemd/system/icecast2.service if you don’t know which one your install expects.

High CPU usage with many listeners. Cap <clients>, lower the stream bitrate, and ensure your server has enough upload bandwidth. The Icecast2 process itself is light, but the kernel’s TCP stack scales up worker threads with connections.

404 on /admin/ after a fresh install. Restart the service after changing the admin password. Many users edit icecast.xml, reload the browser, and conclude the password is wrong when in fact the running daemon is still using the old password.

Frequently Asked Questions

Which is better, Icecast or Shoutcast?

Icecast2 is open-source, supports more audio formats (Ogg Vorbis, Opus, MP3, WebM), and hosts multiple simultaneous mountpoints on one server. SHOUTcast is closed-source and historically required per-stream licensing. For any new project in 2026, Icecast2 is almost always the right choice, with SHOUTcast only relevant if you must integrate with legacy directory services.

What port does Icecast2 use by default?

Icecast2 listens on TCP port 8000 by default. You can change this in the u0026lt;listen-socketu0026gt; block of icecast.xml. If you change it, remember to update the listen-socket port your source clients and listeners connect to, and open that port on your firewall.

Can I stream multiple mountpoints simultaneously?

Yes. One Icecast2 server instance can run as many mountpoints as your bandwidth allows. Declare each one as a u0026lt;mountu0026gt; block in icecast.xml, or let sources connect dynamically by authenticating with the source-password. This is the main advantage Icecast2 has over SHOUTcast, which historically limited free users to a single stream.

Why does my stream disconnect when the source client stops?

That is normal Icecast2 behavior. Source clients control stream availability; when the source ends, Icecast2 has nothing to send and the stream stops. To keep listeners connected when no one is live, configure a fallback-mount in icecast.xml that points to a looping offline audio file, so listeners hear station ident and music instead of dead air.

Do I need a static IP for Icecast2?

You need a stable public address that listeners can reach. A static IP works, but a dynamic DNS hostname (No-IP, DuckDNS, Cloudflare) also works for home servers. For any listener volume above a few dozen, a VPS with a static IP is more reliable because upstream bandwidth and uptime are guaranteed.

Conclusion

Setting up an Icecast2 server with working mountpoints boils down to four jobs: install the package, edit icecast.xml with strong passwords and at least one declared mountpoint, connect a source client that pushes audio, and verify via the admin interface that listeners can hear it. The whole path from a fresh Ubuntu box to a live MP3 stream takes about 20 minutes on a fresh VPS.

If you’re starting your own station this year, my recommended sequence is: pick a cheap VPS with a static IP, follow the install and icecast.xml walkthrough above, configure one Ogg Vorbis mountpoint and one MP3 mountpoint, get DarkIce running as a system service for 24/7 automation, and put Icecast behind nginx for free SSL. From there you can add relays, fallback mounts, and listener analytics without touching the core config again.

Once your Icecast2 server mountpoints are live, you have a fully self-hosted audio platform with no vendor lock-in and no monthly per-listener fees — exactly what community radio, college stations, and indie DJs have used Icecast for since the early 2000s.

Leave a Comment