Skip to content

Why does every 'simple' panel need 2GB RAM now?

General Discussion by mediaaustin 14 replies 1.5K views
#1

I just spun up a test VM with 512MB and tried three "simple" panels from 2025. All OOM-killed within minutes. For what it's worth, the 2015 era ran fine on 256MB with equivalent feature sets. What changed was not the user-facing functionality but the architecture underneath. Every panel now ships with its own container runtime, a Redis instance "for caching," and a background job queue that polls every 15 seconds whether you have jobs or not. The blocklist of bloat is long.

SPF, DKIM, DMARC — holy trinity ✉️
#2

mediaaustin said:
2015 era ran fine on 256MB with equivalent feature sets
Peering. V6 first, now ram first? My edge router runs bgp on 128MB. These panels need more than my fw cfg. Transit.

#3

Bro its all nodejs and electron backends now lol. U fink 2gb is bad? I saw one using free fousand mb for a dns zone editor Back in my day we edited named.conf wif nano and it worked fine

#4

Mark my words, by 2028 the "simple" panel will need 8GB and a GPU for the animated dashboard. The feature bloat is not accidental. It is job security for developers who never learned to optimize.

IPv4, IRC, and irssi — fight me
#5

I had same issue with my test vm. 512MB is dead now.

4 #6

mediaaustin said:
A Redis instance "for caching," and a background job queue that polls every 15 seconds whether you have jobs or not
I actually measured this. Fresh install of one popular panel, zero domains added, idle for 24 hours. Redis alone sat at 180MB resident. The queue worker added another 140MB. That's 320MB doing absolutely nothing. For comparison, my OpenWrt router runs dnsmasq + nftables + wireguard on 64MB.

fio, iperf, geekbench. results or gtfo.
#7

turbo54 said:
Bro its all nodejs and electron backends now
It's not Electron in the backend, it's the frontend SPA frameworks that compile to massive JS bundles, and then the API layer to feed them. The panel I tested pulls 4MB of JS just to render a login page. But the RAM kill is definitely the containers.

#8

turbo15 said:
Job security for developers who never learned to optimize
I said this and I stand by it. I watched a "senior" at my last gig argue that garbage collection meant you didn't need to think about memory. Same person shipped a log parser that loaded the entire 12GB log into a single array. These are the people building your panels.

IPv4, IRC, and irssi — fight me
#9

haroldgsm said:
My edge router runs bgp on 128MB
To be fair, FRRouting is C, hand-tuned for decades. These panels are shipping Go and Rust binaries now too, but they wrap them in 400MB of "ecosystem." The language is not the problem. The architecture is.

#10

Same here on my 512MB VM. I ended up just giving it 2GB to stop the OOMs but it feels wrong for a panel that just serves a dozen static sites.

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft