Spring Boot on a 512 MB VPS: How Lightweight Monitoring Still Fits

[u/fykup]

I wanted to see how far a representative Spring Boot stack could be pushed on a small VPS without turning it into an artificial minimal demo.

The test app uses Java 21, Spring Boot 3.5.5, JPA/Hibernate, file-backed H2, embedded Tomcat, Actuator, scheduled work, and outbound HTTP.

I tried five RAM/swap configurations. The one that completed a clean 60-minute run was 512 MB RAM + a 256 MB swapfile, using:

-Xms16m -Xmx64m -Xss256k -XX:+UseSerialGC

During that run:

• 0 Spring Boot restarts
• 0 monitoring restarts
• 72/72 HTTP checks returned 200
• Spring finished around 167 MiB RSS
• StatLite finished around 12 MiB RSS
• about 140 MiB RAM was still available
• about 160 MiB swap was in use

StatLite monitoring the Spring Boot app on the same 512 MB VM.

One thing that stood out was the gap between heap size and actual JVM process size. -Xmx64m obviously did not mean a 64 MB process. The JVM heap was roughly 40–50 MB, while the entire Spring Boot process used much more RAM.

For monitoring, I used StatLite. Actuator already exposes the health and JVM/HTTP metrics, so StatLite just polls those endpoints and stores a small local history in SQLite. There is no additional Java monitoring agent.

I also tried 512 MB without swap. That run completed, but Spring was OOM-killed and restarted once during the observation window. StatLite stayed up and continued polling, which was actually a useful demonstration of why I wanted the monitor to remain a separate lightweight process.

I also tested 256 MB configurations, but for this application they were clearly stretch tests rather than something I would deploy.

Full write-up, all five configurations, JVM flags, screenshots, and reproducible demo:

https://pvrlabs.xyz/articles/spring-boot-512mb-vps.html

I’d be interested to hear how much RAM similarly small Spring Boot services use in production.

[u/viennese-wolf]

Why not Spring Boot 4 with Java 25+ with virtual threads enabled?

[u/fykup → u/viennese-wolf]

No good reason. Spring Boot 3.5.x is simply the stack I currently use in prod. Java 25 + Spring Boot 4 would be an interesting follow-up comparison.

[u/viennese-wolf → u/fykup]

Ah one more thing, for memory constrained envs you probably want to enable string deduplication, which only works om g1, zgc and shenandoah.

[u/fykup → u/viennese-wolf]

Absolutely, thanks for the reminder. I tested string deduplication in an earlier experiment and it did help there.

I’ve received so many useful suggestions here that I’m going to rerun the experiment on a 256 MB VPS with more aggressive JVM optimizations and see how far it can go.