For months, my home server ran nine apps on 2 GB of RAM. I kept expecting something to break. It didn’t.

Load average sat around 0.2. Apps loaded. Nobody complained. I started to think 2 GB was just enough, and left it at that.

Then one afternoon my three-year-old pressed the play button on Kids Player. Nothing happened.

She pressed it again. Still nothing. About twelve seconds later, the audio started.

It happened the next day. And the day after that.

I asked for a diagnosis

I use two Claude Code sessions — one on my main machine for the blog, one on a separate machine that holds the app code. They pass notes through a shared folder on the NAS. I sent a message asking the app-side session to look at the server’s memory state while the problem was happening. The numbers came back a little while later.

RAM:   1.7 GB total  —  1.0 GB used  —  457 MB free
Swap:  3.0 GB total  —  1.3 GB used
CPU load average: 0.23
Disk: 38% full

CPU was fine. Disk was fine. Network was fine. The problem was swap.

What was happening under the hood

DS224+ uses something called zram: it sets aside four compressed swap partitions inside RAM itself — each 263 MB, about 1 GB total. When real RAM fills up, the NAS quietly compresses older data into these partitions. It buys time. On 2 GB, it buys quite a lot.

But zram has a limit. All four partitions were nearly full — each sitting at around 252 MB used. When the last of that space ran out, the NAS had nowhere left to go except the hard drive (/dev/md1, a physical disk partition, 2 GB). And hard drive random I/O is slow. That’s the twelve-second wait.

At the time, 25 containers were running. The Cloudflare Tunnel process alone ran as nine instances — about 20 MB each, roughly 180 MB just for tunnels. Add DSM’s own processes and background tasks, and 2 GB was quietly full for a long time before anyone noticed.

Why Kids Player triggered it

Most of the apps serve text or small API responses. Kids Player streams audio files on demand. When my daughter pressed play, the Node.js backend needed memory to read and buffer the file. There was none free. The process swapped to disk. She waited.

The diagnosis said: after a RAM upgrade, that wait should drop to under one second.

Why it took months to show up

What surprised me was how long things had been fine. Nine apps, two people using them at most at any given time, months of uptime. The NAS had been managing silently with zram compression, slowly filling the swap without a single error or warning.

It held up right until something actually needed memory in a hurry.

I’ve heard people say 2 GB is not enough for a Synology NAS with even a few Docker containers. I ran nine apps for months with no obvious problem. I think the honest answer is: it depends on what the apps do, and how many people are using them at once. For my use case — a family of three, personal apps, light traffic — 2 GB lasted longer than expected.

But it did have a limit. My daughter found it.

The next step

The DS224+ has one empty SO-DIMM slot. The official Synology spec says the maximum is 6 GB: the built-in 2 GB plus a 4 GB module. But Gemini and Claude Code both told me an 8 GB module would work, giving 10 GB total. Community reports agree.

I decided to order the 8 GB module. Whether 10 GB actually works is still an open question. I’ll find out when it arrives.

How I chose the module, how I safely shut down the NAS to check the slot, and what I actually ordered — that’s the next post.