Every time someone asks “will this run on a 1 GB VPS?” the answer is a guess, or a vendor minimum that was written to be safe rather than accurate. So I measured it.

Same box, same method, every app: install, start it, let it settle for 60s at idle with no clients connected, then sum the RSS of the whole process tree. No Docker overhead in the numbers — these are the apps themselves.

App Idle RSS Version
File Browser 16 MB 2.31.2
Gotify 20 MB 2.6.1
ntfy 27 MB 2.11.0
PocketBase 31 MB 0.22.21
Beszel 39 MB 0.9.1
Caddy 40 MB 2.8.4
Navidrome 47 MB 0.63.2
Syncthing 57 MB 2.1.3
Prometheus 70 MB 2.53.2
MinIO 132 MB 2024 release
Uptime Kuma 136 MB 2.5.0
Gitea 158 MB 1.24.4
Grafana 172 MB 11.2.0
Forgejo 173 MB 7.0.9
Prowlarr 188 MB 2.5.2.5491
code-server 191 MB 4.131.0
Lidarr 191 MB 3.1.0.4875
Radarr 192 MB 6.3.0.10514
Sonarr 193 MB 4.0.19.2979

Things I did not expect:

  • The *arr apps are all the same size. Sonarr, Radarr, Lidarr and Prowlarr land within 5 MB of each other (188–193 MB). That is not a coincidence and it is not the app — it is the .NET runtime setting the floor. Which also means the folklore of “budget ~2 GB for an *arr stack” is roughly right, and I say that as someone who started this expecting to debunk it.
  • Go binaries are absurdly cheap. File Browser, Gotify, ntfy, PocketBase, Caddy and Navidrome together idle at about 181 MB — less than one Sonarr.
  • Grafana’s 512 MB minimum is honest. At 172 MB idle it has real headroom needs once dashboards start querying. Not every vendor minimum is padding.
  • Node apps cost you. Uptime Kuma at 136 MB is ~8x File Browser for a job that is not 8x harder.

Caveats, because they matter: this is idle RSS, not what you need under load. Databases, media transcoding and indexing all blow past these numbers. Treat it as the floor, not the budget. My own rule of thumb from this: sum the idle figures, add ~300 MB for the OS, then add 30% headroom — that has matched what actually fits so far.

Raw data is free under CC BY 4.0 (CSV and JSON), plus per-app pages with the exact commands used so you can reproduce or dispute any number:

https://smeltworks.com/smallserver/

CSV direct: https://smeltworks.com/smallserver/smallserver-dataset.csv

Happy to take corrections — if a number looks wrong for your setup I would rather fix it than defend it. Also taking requests for what to measure next; Jellyfin and Immich are the two I keep getting asked for.

  • non_burglar@lemmy.worldEnglish
    6·
    3 days ago

    So, couple things here:

    1. Most VPS have elastic memory, meaning they can borrow burst ram from the host for short periods. This means you 1GB vps can probably run at 1.5GB or even two during some demanding jobs for a short time. And depends on the provider.
    2. You don’t document how you installed any of these.
    3. .net core doesn’t work that way, it’s not “running” underneath the arr stack. There is some init stuff that happens when you first start a .net app, setting up DLLs, paths in /opt and such, but there isn’t a resident “layer” involved.
    4. My arr stack executables never, ever exceed 700MB, 2GB is more than enough and pretty conservative. I’ve watched these metrics since the days when radarr and sonarr were backed by mono. You do need some mem space to store temporary show/movie metadata, but it’s trivial.
    5. As others have said, peak demand is what you want to know, not base requirement.

    Generally, I like where you’re taking this, but I think some more experience with how processes and memory work will help you a lot.

    • smallserverdata@lemmy.mlOPEnglish
      14·
      3 days ago

      Taking these in order.

      Point 3 first, because you are right and I was sloppy. There is no resident .NET layer sitting under the *arr apps. What I actually observed is four apps landing within 5 MB of each other, and the cause is that each process loads its own copy of the same runtime assemblies, not that something shared is running underneath. My wording implied a shared layer that does not exist. I will correct that on the site.

      Point 2: the exact binary, flags and health check for each app are on its page on the site, but you are right that none of that was in the post, and the post is what most people read. Short version: every app is the upstream release binary run directly, no distro packages, no containers, so the numbers exclude container overhead.

      Point 1: fair, and it undercuts how I framed the sizing rule. On a provider that allows bursting, a floor matters less than I implied.

      Point 4 is the useful one for me. 700 MB for a whole *arr stack under real use is a much better number than anything I published, and it comes from someone who has watched it since the mono days. If you have a rough split per app I will put it up as a reported real-world figure alongside my measured idle ones, credited to you.

      Point 5: agreed, and it is what I am fixing right now.

      • phlaym@discuss.tchncs.deEnglish
        1·
        3 days ago

        Short version: every app is the upstream release binary run directly

        I’m still utterly dumbfounded, why you used Forgejo v/ which is not even supported anymore, instead of the current v15 (LTS) or v16. Where did you find these binaries?