How Much RAM Does Lavalink Need?
What drives Lavalink's memory and CPU use, realistic sizing by concurrent players, how to size the JVM heap, and how to read the node's stats before you upgrade.
On this page
“How much RAM does my Lavalink node need?” has a more useful answer than for most software, because Lavalink’s resource use is driven by one main factor: how many players are playing at the same time. This article explains what uses memory and CPU on a node, gives realistic sizing, and shows how to measure your own.
What drives resource use
The JVM baseline
Lavalink is a Java application. Before a single track plays, the JVM, Lavalink and its plugins occupy a baseline of memory — typically a couple of hundred megabytes. That baseline is why very small nodes are tight: most of the memory is already spoken for.
Concurrent players
Each active player holds audio buffers (controlled by frameBufferDurationMs and bufferDurationMs in application.yml), decoding state and encoder state. More players playing at once means more memory and — more importantly — more CPU for decoding, filtering and Opus encoding.
The number of servers your bot is in doesn’t matter much. A bot in 5,000 servers with 20 people listening at once needs a smaller node than a bot in 500 servers with 200 listening.
Track loading
Resolving tracks — especially large playlists and albums — creates many objects at once. LavaSrc mirroring adds searches per track. A node that constantly loads big playlists needs more headroom than one that mostly plays single tracks.
Filters and resampling
Filters like timescale and rotation add CPU per frame, and resampling (when a source’s sample rate differs from Discord’s 48 kHz) costs CPU depending on resamplingQuality. These affect CPU far more than memory.
Rough sizing
These are starting points, not guarantees — your sources, filters and playlist habits shift them:
| Node RAM | Suits | Example plan |
|---|---|---|
| 512 MB | Small bots, a handful of concurrent players | Managed Starter, self-managed Basic |
| 1 GB | Growing bots, multiple guilds with queues | Managed Premium, self-managed Pro |
| 2 GB | Busy bots, full plugin stack, frequent playlists | Managed Elite, self-managed Ultra |
| 4 GB | High-traffic public bots, large queues | Managed Apex |
| 6 GB+ | Very large bots, or consolidating several nodes | Managed Enterprise or custom |
For CPU, the rule of thumb is simple: more concurrent players and more filters need more cores. Kerit Cloud’s managed plans scale CPU with RAM — 100% (one core) on Starter up to 500% on Enterprise — and self-managed plans from 1 to 4 vCPUs. See the managed and self-managed plan pages.
Sizing the heap
On a self-managed node you choose the Java heap with -Xmx. The heap is only part of the JVM’s memory — metaspace, thread stacks and native buffers need room too — so never set the heap equal to the server’s total RAM.
| Server RAM | Suggested -Xmx |
|---|---|
| 512 MB | 350–400M |
| 1 GB | 700–750M |
| 2 GB | 1400–1500M |
| 4 GB | 3000M |
In containers, -XX:MaxRAMPercentage=75 sizes the heap from the container’s memory limit automatically. JVM tuning for Lavalink covers garbage collector choices as well.
On managed plans, heap and GC are tuned for you.
Measure your node
Lavalink reports its own statistics. Query them directly:
curl -s -H "Authorization: your-password" http://your-node:2333/v4/stats
The response includes:
playersandplayingPlayers— total players and how many are actively playing.playingPlayersis the number that drives load.memory—used,free,allocatedandreservableheap memory.cpu—cores,systemLoadandlavalinkLoad.frameStats— per minute, framessent,nulledanddeficit.
Client libraries receive the same stats over the WebSocket every minute, so you can log them from your bot.
Reading frameStats
frameStats is the best early warning of an overloaded node. Each player should send about 3,000 frames per minute (50 per second). deficit counts frames that should have been sent but weren’t; nulled counts frames that were empty. Occasional small numbers are normal. Consistently high deficits mean listeners are hearing stutters — usually from CPU starvation, garbage collection pauses or network problems.
Watch these signs
lavalinkLoadhigh and deficits rising — the node needs more CPU, fewer filters, or lower encoding and resampling quality.- Heap
usedclose toreservable, frequent GC warnings in the log — the heap is too small. - Memory climbs steadily and never levels off — look for a plugin or configuration issue, and keep Lavalink and plugins updated.
For continuous graphs, enable Prometheus metrics — see monitoring Lavalink with Prometheus and Grafana.
Scale up or scale out?
When one node isn’t enough, you have two options:
- Scale up — move to a bigger plan. Simple, and on Kerit Cloud managed upgrades are live, with no downtime or reconfiguration.
- Scale out — run several nodes and spread players across them. More resilient (one node failing doesn’t stop all music) and useful for placing nodes in different regions. See running multiple Lavalink nodes.
Many bots scale up until a single node reaches a comfortable size, then add a second node for resilience.
Keep the bot and node separate
Don’t size a node by adding it to your bot’s server as an afterthought. Running Lavalink and a busy bot in the same process space — or on one small server — makes them compete for CPU, and a spike in one affects the other. Dedicated nodes are easier to size and monitor. Running a music bot explains the split.
Summary
Lavalink’s needs are driven by concurrent playing players, playlist loading, filters and resampling — not by how many servers your bot is in. 512 MB suits small bots with a handful of listeners, 1–2 GB suits growing and busy bots, and 4 GB or more suits high-traffic public bots. Size the heap at about 70–75% of RAM, watch playingPlayers, CPU load and frame deficits in /v4/stats, and scale up or out when deficits appear.