VPS with 4 GB RAM and 2 vCPU

The Starter plan is Devoster's 4 GB option. There is exactly one plan at this size, so there is nothing to compare inside the range:

• 2 vCPU on hosts with Intel Xeon Gold 6138 processors.
• 4 GB RAM and 75 GB NVMe storage.
• KVM virtualization with your own kernel and full root access.
• 1 Gbps port with unlimited bandwidth, in a datacenter in Utah, USA.
• Linux images: Ubuntu 24.04, 22.04 and 20.04, Debian 12, AlmaLinux 10.
• Nightly backups with the last 3 days kept, and one snapshot slot, at no extra cost.

At $7.99/mo it works out to about $2.00 per GB of RAM. Larger plans are cheaper per GB (Advanced is about $1.75), but only if you will actually use the memory. The plan is unmanaged: we run the hardware and network, you run the operating system and everything on it.

"Is 4 GB enough?" depends on a budget, not a feeling. On a typical single-app server, memory splits four ways:

• The operating system. A minimal Ubuntu or Debian server with SSH, systemd and a firewall uses a few hundred MB.
• The database. MySQL and MariaDB ship with a 128 MB InnoDB buffer pool and PostgreSQL with 128 MB of shared_buffers. Those defaults are deliberately small; on a 4 GB box you would usually raise them to somewhere around 0.5 to 1 GB so your hot data stays in memory.
• The application. PHP-FPM workers, a Node.js process, Python workers or a JVM. This is the part that varies most and the part that spikes.
• Page cache. Whatever is left, Linux uses to cache files from disk, including database files. Memory that looks "used" by cache is doing useful work, and when it shrinks, disk reads go up.

A sensible plan for 4 GB is roughly: under 0.5 GB for the OS, up to 1 GB for the database, 1.5 GB for the app at its busiest, and at least 1 GB left for cache and spikes. These are planning figures, not measurements of your app. Check yours with free -m (watch the available column, not free) and ps aux --sort=-rss | head under real load.

With that budget in mind, these fit comfortably, each as the main job of the server:

• One busy WordPress or WooCommerce site with MariaDB, PHP-FPM and a Redis object cache, or several low-traffic WordPress sites. Our article on how many websites a VPS can host works through the arithmetic per site.
• A web application with its database: a Node.js, Python, Go or PHP app with Postgres or MySQL and Redis.
• n8n with Postgres behind a reverse proxy. n8n's own Docker Compose guide asks for 2 vCPUs and 4 GB, which is exactly this plan. See n8n VPS hosting.
• A Docker Compose stack of three to six services: proxy, app, database, cache, a background worker. See Docker VPS hosting.
• A self-hosting toolbox: a password manager server, an uptime monitor, a WireGuard VPN and a lightweight Git server together. Each of these is small; four of them are still small.
• A staging copy of a production app that runs on a bigger server.
• A small game server such as vanilla Minecraft for a group of friends, with a 2 to 3 GB heap. Modpacks are a different story.

• Elasticsearch or OpenSearch next to anything else. They run on the JVM and also rely on the OS page cache for search performance. On 4 GB they compete with your app and database for the same memory.
• GitLab self-managed. It bundles its own Postgres, Redis, web workers and background jobs. It can be squeezed onto a small server with tuning, but it leaves nothing for anything else.
• Several busy WooCommerce stores on one server. Each one wants its own PHP-FPM workers at peak, and peaks tend to coincide.
• Building Docker images or large frontends on the server while production runs. A dependency install or bundler run can take a gigabyte or more on its own for a few minutes.
• Local language models. There is no GPU, and even small quantized models want more memory than the whole plan.
• Modded game servers or servers for more than a handful of players.

None of these is impossible on 4 GB in a demo. They are what makes a 4 GB server start swapping in production.

For database-backed web apps, memory usually runs out before CPU does. Two vCPUs handle a lot of requests when responses come from cache; they become the limit when work is CPU-bound: image resizing, PDF generation, compression, heavy PHP or Python per request, or builds.

The signal for CPU is a load average that sits above 2 for long stretches while memory is fine. Before you blame your own code, check the st column in top or vmstat 1: that is time your VPS wanted the CPU and the host gave it to someone else. Our guide to CPU steal time explains how to read it and what counts as normal. On Devoster, vCPUs are threads on the host's Xeon Gold 6138 processors, not dedicated physical cores.

Upgrade when you see one of these, not before:

• The OOM killer has fired. dmesg | grep -i oom or journalctl -k | grep -i oom shows a process was killed for memory.
• Swap is busy, not just used. A little swap in use is harmless. Non-zero si/so columns in vmstat 1 during normal traffic means the server is paging.
• Available memory stays under about 500 MB at peak, so the database is losing its page cache.
• You are adding a second app, switching n8n to queue mode, or bringing a search engine into the stack.

Basic (3 vCPU / 6 GB / 100 GB, $10.99/mo) is the next step when you need a bit more of everything. Advanced (4 vCPU / 8 GB / 125 GB, $13.99/mo) is the step when you are consolidating several workloads; see 8 GB RAM VPS. Upgrades are done from the Devoster panel: the disk grows and the VPS reboots to pick up the new size. Plans can't be shrunk in place, which is a good reason to start at 4 GB and grow rather than start at 8 and hope.

The reverse check is worth doing too. If free -m shows well under 1.5 GB in use at your busiest hour, the Micro plan (1 vCPU / 2 GB, $4.49/mo) may be all you need.

• You have one WordPress site and no interest in running Linux. Devoster's web hosting handles the server for you and is cheaper than a VPS for that job.
• You need someone else to manage the server. This plan is unmanaged; OS updates, security and backups beyond the included ones are yours.
• Your users are mostly in Europe or Israel and every millisecond counts. The server is in Utah, USA. For APIs, automation and most sites behind a CDN that's fine; for latency-sensitive interactive apps aimed at another continent, it isn't ideal.
• Your workload is on the "doesn't fit" list above. Start at 8 GB instead of upgrading under pressure.

To see all eight plans side by side, go to Devoster VPS hosting. Before your first deploy, work through the VPS security hardening checklist.