How Much VPS You Actually Need

The short answer

How much RAM does a VPS need depends entirely on the memory pressure your specific processes create, not on a generic industry standard. For a single independent developer running a mixed stack of dynamic Node.js applications, static assets, and a shared database, 12GB is a practical baseline that prevents thrashing during peak loads.

Memory allocation is a finite resource where every process competes for space. If the kernel cannot satisfy a memory request from a running process, it begins swapping active pages to disk. This transition from RAM to disk changes the latency of your system from nanoseconds to milliseconds, effectively halting the application until the swap completes. The goal is not to have "enough" RAM in an abstract sense, but to ensure the working set of your most active components fits within physical memory.

Used versus available

A common mistake is reading the "used" column in system monitoring tools and assuming that is the memory actually consumed by applications. Linux manages memory aggressively, using free RAM for disk caches and buffers to speed up file access. This memory is considered "available" because the kernel can reclaim it instantly if a process needs it. The metric that matters is the "available" memory, which represents what is truly free for new allocations.

If your available memory drops near zero, the system is under pressure. At this point, the kernel starts evicting cache pages. While this is normal behaviour, if it happens constantly, your applications will experience latency spikes as they wait for data to be read back from disk. You are not broken by having high "used" memory; you are in trouble when "available" memory stays low under load. Monitoring tools that only show total usage mislead developers into thinking they need more hardware when they simply need to understand how the OS manages the cache.

Static versus dynamic loads

Static sites like GamingCap and Invoiceful, which are served directly from disk by Caddy, have a negligible memory footprint. They do not maintain server-side state or run interpreters. Their memory usage is limited to the file system cache, which is beneficial. The heavy lifters are the dynamic services. A Next.js process serving multiple hosts and a separate Node.js process for scheduling tools like Instalaz maintain large heaps in memory. These heaps hold application state, compiled code, and active data structures.

These processes do not release memory back to the OS immediately after a request completes. The garbage collector reclaims objects, but the allocated heap size often remains high to avoid frequent resizing. This means your baseline memory usage will stay elevated even when traffic is low. You must size your VPS for the accumulated heap sizes of all running Node.js processes, plus the shared PostgreSQL database. The database is particularly sensitive because it caches data in RAM to serve queries quickly. If the database and the application servers compete for the same limited pool, performance degrades for everyone.

Practical sizing

For a setup involving a shared database and multiple Node.js services, 12GB of RAM allows for headroom. This capacity ensures that the database can cache its most frequently accessed tables without forcing the application servers to swap. It also accommodates the scheduled systemd services that run periodically, which may spike memory usage temporarily. If you are running fewer services, or if those services are lighter, you might get away with 8GB. However, the margin of error is small. Once you hit the swap threshold, the degradation is not linear; it is a cliff edge where the system becomes unusable.

Start with a configuration that covers your known processes and monitor the available memory over a full week of typical traffic. If the available memory consistently stays above 1GB, you are safe. If it hovers near zero, you need more RAM or you need to optimize your application memory usage. The hardware is not the final solution, but it is the necessary foundation for the software to behave predictably. For those interested in how a small team manages diverse products, you can see the film publication at PracandyFlix, which runs on this same infrastructure.