AzuraCast High CPU and Liquidsoap Overload Fix (August 2026)

If you landed here, your server is probably on fire. Liquidsoap is eating 80 percent of your CPU, listeners are dropping out, and the AzuraCast dashboard is barely responding. I have been there, and this guide walks through every fix I have used to bring AzuraCast high CPU and Liquidsoap overload under control.

AzuraCast is a powerful self-hosted radio platform, but it runs Liquidsoap as its AutoDJ engine, and Liquidsoap is hungry. Every broadcast destination, every ReplayGain tag, every audio processor stacks more load onto your CPU. The good news is that most of these costs are optional and can be reduced or removed without breaking your station.

In this article, I cover a quick diagnostic checklist, six numbered fixes ranked from easiest to most involved, cloud hosting considerations, and long-term monitoring tips. By the end, you will know exactly what is causing your AzuraCast Liquidsoap overload and how to fix it.

Quick Diagnostic Checklist for AzuraCast High CPU

Before changing anything, run through this checklist to isolate the cause. I recommend doing these in order because they take under five minutes combined and will tell you exactly which fix to apply.

Step 1: Check CPU usage per process. SSH into your server and run docker stats if you are using Docker. Look at the azuracast_web and azuracast_stations containers. If Liquidsoap is the top consumer, you are dealing with an AzuraCast Liquidsoap overload issue, not a general system problem.

Step 2: Count your broadcast destinations. Go to each station’s settings, open the Broadcast tab, and count every mount point and remote relay. AzuraCast estimates roughly 10 percent of one CPU core per broadcast destination when the AutoDJ is running. If you have 8 destinations on a 2-core VPS, that alone explains the load.

Step 3: Check if ReplayGain is enabled. In each station’s AutoDJ settings, look for “Use ReplayGain Metadata.” If it is on and your media files lack ReplayGain tags, Liquidsoap will compute them on the fly, which is extremely CPU intensive.

Step 4: Check for audio post-processing. Look at the station’s Liquidsoap configuration for Stereo Tool, master_me, or any custom post-processing block. These plugins process audio in real time and add significant overhead.

Step 5: Check for AutoCue. Newer AzuraCast versions include AutoCue, which analyzes tracks for smooth crossfades. If you just added a large media library, AutoCue may be running analysis in the background and spiking your CPU.

Step 6: Check for the “We must catchup” error. Open your station logs in the AzuraCast dashboard. If you see repeated “We must catchup” messages from Liquidsoap, the audio buffer is overrun and the CPU cannot keep up with real-time encoding.

How Liquidsoap Uses CPU in AzuraCast?

Understanding where the CPU goes makes the fixes much easier to apply. Liquidsoap is the audio processing engine that AzuraCast uses for its AutoDJ. Every time a listener connects, Liquidsoap does not spawn a new process. Instead, it encodes audio once per broadcast destination and Icecast or Shoutcast handles the fan-out to listeners.

This design means your CPU cost scales with the number of broadcast destinations, not the number of listeners. AzuraCast’s own documentation estimates about 10 percent of a single CPU core per broadcast destination when the AutoDJ is actively playing. A station with two local mount points and one remote relay therefore consumes roughly 30 percent of one core just to keep audio flowing.

On top of that baseline, several optional features add per-track or real-time processing overhead. ReplayGain calculations, Stereo Tool DSP processing, master_me normalization, AutoCue analysis, and crossfade detection all add layers of CPU work. When several of these are active at once, even a capable server can hit 70 to 80 percent CPU with zero listeners connected.

I have seen cases on GitHub where users report two Liquidsoap processes running at 40 to 80 percent CPU constantly. In nearly every case, the root cause was a combination of ReplayGain metadata computation and multiple mount points with audio post-processing enabled.

Fix 1: Disable or Pre-Calculate ReplayGain

ReplayGain is the single most common cause of AzuraCast Liquidsoap overload. When “Use ReplayGain Metadata” is enabled in a station’s AutoDJ settings, Liquidsoap reads ReplayGain tags from each track to normalize volume. If the tags are missing, Liquidsoap calculates them on the fly, which is extremely CPU intensive.

I saw a GitHub issue (#6573) where a user had Liquidsoap hogging CPU after enabling ReplayGain with a library full of untagged files. The fix was simple: either disable ReplayGain entirely or pre-calculate the tags.

Option A: Disable ReplayGain entirely. Go to each station, open the AutoDJ tab, open Advanced Configuration, and set “Use ReplayGain Metadata” to Disabled. This removes all ReplayGain processing from Liquidsoap immediately. You may notice some volume variation between tracks, but your CPU usage will drop dramatically.

Option B: Pre-calculate ReplayGain tags with loudgain. If you want volume normalization without the CPU hit, install loudgain on your host and run it against your media library before uploading. The command is:

loudgain -a -k -s e *.mp3

This writes Album ReplayGain tags to each file. When Liquidsoap encounters pre-tagged files, it simply reads the metadata instead of computing it, which costs almost no CPU. This is the best long-term solution if you care about consistent loudness across your station.

Fix 2: Turn Off Audio Post-Processing

Audio post-processing plugins are the second biggest CPU drain after ReplayGain. AzuraCast supports several real-time processors including Stereo Tool, master_me, and custom Liquidsoap effects. These run on every sample of audio in real time, which means they consume CPU continuously while the AutoDJ is active.

The official AzuraCast optimization guide recommends disabling audio post-processing if you are running on limited resources. I agree with this advice. Unless you are running a professional broadcast station that requires loudness compliance, these processors add a lot of cost for marginal benefit.

To disable post-processing, go to each station’s settings and open the Liquidsoap Configuration section. Look for any Stereo Tool, master_me, or custom post-processing blocks. If you find them, remove or comment them out, then restart the station.

If you absolutely need audio processing, consider running it offline instead. You can process your entire media library with a tool like loudgain or a batch DSP script before uploading. This shifts the CPU cost from your streaming server to your workstation, where it is essentially free.

One community tip worth noting: several users on GitHub reported that simply disabling Jingles returned their CPU to normal loads. Jingles can trigger short bursts of real-time processing, especially if crossfades are enabled between jingles and main content. If you use jingles and notice periodic CPU spikes, try disabling them temporarily to confirm.

Fix 3: Reduce AutoCue CPU Overhead

AutoCue is a newer AzuraCast feature that analyzes each track to find optimal crossfade points. It is convenient, but it performs audio analysis on every file in your library, which can cause a significant CPU spike when you first add a large batch of music.

If you recently uploaded a big media library and your CPU spiked, AutoCue analysis is likely the culprit. The good news is that this spike is temporary. Once AutoCue finishes analyzing a file, it caches the result and does not re-analyze it unless the file changes.

To reduce AutoCue overhead, you have two options.

Option A: Disable AutoCue entirely. Go to each station’s settings and disable AutoCue in the AutoDJ configuration. This removes all analysis overhead. You lose automatic crossfade points, but you can set manual crossfade durations instead.

Option B: Let AutoCue finish, then monitor. If you want to keep AutoCue, let the initial analysis complete. Check your system load after 24 to 48 hours. Once all files are analyzed, the ongoing CPU cost drops to near zero. If your server cannot handle the initial spike, consider adding files in smaller batches so the analysis load stays manageable.

Several users on the AzuraCast subreddit reported that disabling AutoCue or pre-computing the analysis values resolved their initial CPU spike immediately. If your library is large and your server is small, disabling AutoCue is the safer choice.

Fix 4: Cut Unnecessary Mount Points

Every broadcast destination in AzuraCast adds about 10 percent of a CPU core to your baseline load. This includes local Icecast mount points, Shoutcast streams, and remote relays. If you have multiple formats (MP3 and AAC), multiple bitrates (128k and 256k), or redundant mount points you are not actually using, you are paying CPU tax for nothing.

Audit your broadcast destinations by opening each station and reviewing the Broadcast tab. Ask yourself: does anyone actually listen on this mount point? Do you need both MP3 and AAC, or can you standardize on one format? Can you remove the 256k stream if 128k covers your audience?

Each destination you remove drops your CPU usage by roughly 10 percent of one core. On a 2-core VPS, removing three unnecessary mount points can cut your total CPU load from 80 percent to 50 percent.

If you need multiple formats or bitrates, consider using AzuraRelay on a separate server. AzuraRelay is a lightweight relay component that takes a single stream from your main AzuraCast server and re-broadcasts it. This offloads the transcoding CPU cost to a second machine, which can be a cheap VPS or even a dedicated relay box.

Fix 5: Disable the Docker Userland Proxy

If you are running AzuraCast in Docker, there is a lesser-known setting that can help: the Docker userland proxy. This proxy intercepts network traffic between containers and the host, adding a layer of processing overhead. For a high-throughput streaming server, this overhead is unnecessary and wasteful.

To disable the userland proxy, create or edit the Docker daemon configuration file at /etc/docker/daemon.json and add the following:

{"userland-proxy": false}

After saving the file, restart the Docker daemon:

sudo systemctl restart docker

This change affects all Docker containers on the host. It removes a layer of user-space network proxying and can improve I/O throughput noticeably for streaming workloads. The official AzuraCast documentation recommends this as a standard optimization step.

Note that disabling the userland proxy is safe for AzuraCast. It does not affect port forwarding or listener connectivity. It simply makes Docker route traffic more efficiently at the kernel level.

Fix 6: Restart Liquidsoap and Clear the System Cache

Sometimes Liquidsoap gets into a bad state where CPU usage climbs gradually over days or weeks of continuous operation. I have seen multiple reports of AzuraCast becoming increasingly CPU intensive after about a week of use, even with no changes to configuration.

This gradual climb is often caused by memory fragmentation, accumulated playback history, or stale cache data. The fix is to restart the affected stations and clear the AzuraCast system cache.

Step 1: Restart the station’s AutoDJ. In the AzuraCast dashboard, go to the station and click “Restart Broadcast.” This restarts the Liquidsoap process for that station without affecting other stations or the AzuraCast web interface. If only one station is causing high CPU, this is the fastest fix.

Step 2: Clear the system cache. If restarting individual stations does not help, clear the AzuraCast application cache. Run the following command from your AzuraCast installation directory:

docker-compose run --rm web cli cache:clear

If you are using the newer Docker Compose V2 syntax:

docker compose run --rm web cli cache:clear

Step 3: Restart all AzuraCast services. If the problem persists, restart the entire AzuraCast stack:

docker-compose down && docker-compose up -d

After restarting, monitor CPU usage for the next 30 minutes. If it returns to normal, the issue was stale state. To prevent recurrence, schedule periodic restarts using a cron job. Many station operators restart their AzuraCast containers weekly during off-peak hours to prevent gradual CPU creep.

One more thing worth checking: playback history. AzuraCast stores detailed playback history in its database, and the amount of stored history can affect database query performance over time. If you do not need months of playback logs, consider keeping less playback history in the system settings to reduce database load.

Cloud Hosting Throttling and AzuraCast Performance

Even after applying all the fixes above, you might still see high CPU if your hosting provider is throttling you. This is a common problem with shared CPU cloud instances from providers like DigitalOcean, Linode, and others.

Shared CPU instances do not guarantee a fixed amount of CPU. Instead, you get a “CPU credit” system: your instance can burst above its baseline for short periods, but sustained high CPU usage burns through credits and gets throttled down to the baseline. For a 24/7 radio station, this is a recipe for trouble.

AzuraCast’s documentation is explicit about this. They recommend dedicated CPU instances for production radio stations because the AutoDJ runs constantly, consuming CPU around the clock. A shared CPU instance that seems powerful enough on paper can get throttled after a few hours of continuous AutoDJ operation.

How to tell if you are being throttled: Watch your CPU usage over a 24-hour period. If it starts at a manageable level and gradually climbs or drops in bursts, your provider is likely throttling. You may also see “We must catchup” errors in Liquidsoap logs when throttling kicks in.

What to do about it: Upgrade to a dedicated CPU instance, or offload some work to a separate AzuraRelay server. A dedicated 2-core instance will outperform a shared 4-core instance for streaming workloads because the CPU is always available at full speed.

RAM matters too. AzuraCast requires a minimum of 512MB of RAM, but in practice you want at least 1GB for a single station and more for multiple stations. If your server is swapping to disk, CPU usage will spike as the system constantly pages memory in and out. Check swap usage with free -h and upgrade RAM if swap is being used heavily.

Advanced Monitoring and Long-Term Prevention

Once you have fixed the immediate CPU issue, set up monitoring so you catch problems before they affect listeners. I recommend three things: process-level monitoring, log review, and scheduled maintenance.

Process-level monitoring. Install a lightweight monitoring tool like htop or Netdata on your server. Set up alerts for CPU usage above 80 percent sustained for more than 5 minutes. This gives you early warning before listeners notice problems. Netdata is particularly useful because it breaks down CPU by Docker container, so you can see exactly which AzuraCast component is spiking.

Log review. Make a habit of checking your station logs weekly. Look for “We must catchup” errors, buffer overrun messages, and any Liquidsoap warnings. These are early indicators that your CPU is struggling to keep up with real-time encoding. Catching them early lets you apply fixes before the station becomes unresponsive.

Scheduled maintenance. Restart your AzuraCast containers weekly during low-traffic hours using a cron job or Docker restart policy. This prevents the gradual CPU creep that many users report after a week or more of continuous operation. Clear the system cache at the same time to keep database queries fast.

Here is a sample cron entry for a weekly restart at 4 AM on Sunday:

0 4 * * 0 cd /var/azuracast && docker-compose restart

Media library hygiene. Pre-calculate ReplayGain tags for all new uploads before adding them to AzuraCast. Add files in smaller batches if AutoCue is enabled. Remove unused media files to reduce database size and scan times. These habits prevent the most common CPU spikes before they happen.

Frequently Asked Questions

Conclusion

AzuraCast high CPU and Liquidsoap overload almost always comes down to a few predictable causes: ReplayGain on untagged files, audio post-processing, AutoCue analysis, too many mount points, stale state, or cloud hosting throttling. Work through the diagnostic checklist first, then apply the numbered fixes in order, and you will see a measurable drop in CPU usage.

For long-term stability, pre-calculate ReplayGain tags, keep audio processing offline, audit your mount points regularly, and schedule weekly container restarts. If you are still hitting limits, move to a dedicated CPU instance or distribute the load with AzuraRelay. Your listeners will thank you for the uninterrupted stream.