Which VPS plan do I need for what I'm running?

You've picked the app. Now four plan cards sit in front of you, labeled For lightweight apps and solo projects and For apps running in production, while your app's docs talk in gigabytes and cores, and the two don't line up on their own. Immich, for example, asks for 6 GB of memory at minimum, which rules out Stack 4 and its 4 GB before you've installed anything.

Each row below puts what the app's makers publish next to the plan that fits it. It's our estimate from the vendor's own docs, read on October 2, 2026. We haven't run these apps on DreamHost servers, though we did run one common pair on our own test machine, further down. Where a vendor publishes no figure, the row says so.

What each plan includes

All four plans include full root access, your choice of Linux OS, Docker and the one-click app library. They differ in cores, memory and disk:

Look at the vCPU column before you look at memory. Stack 8 doubles the memory and disk of Stack 4 but keeps the same 2 vCPU, so an app that's short on CPU has to jump to Stack 16, the first plan with more cores. Stack 32 doubles them again, to 8.

Find your app in the sizing table

Find the row closest to what you run. Start on the plan in its last column. The middle column is what the app's makers publish, linked in the sources below. Each app's VPS Hosting page is linked under the table.

VPS Hosting pages for every app in the table: LAMP Stack, Node.js, PostgreSQL, Docker and Portainer, Dokploy, n8n, GitLab, Supabase, Immich, Pelican Panel, OpenClaw, Hermes Agent, Paperclip, Ghost, Umami, Uptime Kuma.

Immich's minimum is 6 GB, so Stack 4 isn't in its row, even though Immich says a 4 GB system can run with machine learning turned off.

You won't find a user count in most rows, because GitLab is the only vendor here that publishes one: its low-memory setup is written for up to five developers.

Apps on one server share its memory, so add their rows together and leave room for the operating system. Put n8n next to Immich and their minimums come to 10 GB before the operating system takes its share, which was about 300 MiB on our fresh Ubuntu 24.04 test VM. That's more than Stack 8 has, so the pair starts at Stack 16.

What that pair used on our test VM

We ran that pair on a test VM with 2 vCPU and 8 GB of memory, the shape of Stack 8, on October 22, 2026. It was Immich v3.3.5 from Immich's release setup, with machine learning on and no photos, next to n8n 2.44.5 with PostgreSQL from n8n's own Docker Compose files, with no workflows. The VM ran on an arm64 Mac, so it's our test machine, not a DreamHost server.

At rest, the pair used under 2 GB, far below the 10 GB their minimums add up to. Rest isn't the limit, though. In a separate run on the same size of machine, Immich alone reached about 6 GB while it processed an import of just 300 photos. Adding n8n's 0.4 GB at rest to that peak comes to about 6.4 GB, which is arithmetic, since we didn't run both busy at once. That leaves little room on 8 GB, which is why we still start the pair on Stack 16. We ran each setup once, and these were fresh installs with no users, so treat them as floors, not sizing minimums.

Disk can run out before memory does. A photo library or a Git server can fill it while memory still looks fine.

If you're moving a photo library, measure it first and add Immich's margin before you compare it with the plan's disk. GitLab's figure covers only the application, and it asks for repository storage at least as large as all your repositories combined on top of that.

Apps whose makers ask for more than Stack 8

GitLab

GitLab is the hard one. Its own pages give different floors. GitLab's requirements page sets 8 vCPU and 16 GB as the baseline for a single-node install, and only Stack 32 has 8 vCPU. Stack 16 has the 16 GB with half the cores. The same page says GitLab can run with at least 8 GB where memory is tight, and that's the only CPU or memory figure on the page that Stack 8 meets. Its memory-constrained guide goes lower still, to 2 GB plus 1 GB of swap for up to five developers whose repositories stay under 100 MB.

The two pages also split on swap. On a standard install, GitLab says to disable swap or provision enough memory that GitLab never uses it, while the low-memory setup expects the server to use swap during regular operation. For a small team's GitLab server, our guidance is Stack 16, which gives you the baseline memory and 4 of the 8 cores, so it sits below GitLab's baseline and a trial has to show it keeps up. GitLab advises running CI runners on a separate machine from GitLab itself. Plan a second server for your pipelines. A team that needs the full baseline goes to Stack 32. GitLab VPS Hosting includes GitLab CE on every Stack plan.

Supabase

Supabase's self-hosting docs call their minimum of 4 GB, 2 cores and 40 GB of SSD suitable for development and small to medium production workloads, and Stack 4 and Stack 8 both meet it. The recommended spec asks for 4 cores or more, and since Stack 16 is our smallest plan with 4, that's where we'd run a busy production project.

Immich

Stack 8 meets Immich's 8 GB memory recommendation with the minimum 2 cores. Stack 16 meets both recommendations. Its 250 GB disk also holds a bigger library than Stack 8's 150 GB, which can matter as much as memory once you import years of family photos and phone videos.

Palworld and other game servers

Palworld's server guide lists 16 GB of memory and recommends 4 cores, so Stack 16 meets its requirement. It says an 8 GB server boots but is more likely to crash when it runs out of memory, which is why Stack 8 isn't in Palworld's row. The guide also recommends more than 32 GB. Stack 32 has exactly 32 GB and is the largest Stack plan, so a Palworld server that needs the recommended memory belongs on a dedicated machine.

The cost of starting too big

If you start too small, the fix is a plan change: you pick the bigger plan in the panel, and your environment comes with you. Starting too big has no matching fix. DreamHost's Help Center says you can't currently move down to a smaller Stack plan, so its route is to check that your data fits, provision a new server on the smaller plan, move everything across, confirm it works, and cancel the original.

Until then, you pay each month for memory and cores your app doesn't use. DreamHost's Help Center says a VPS doesn't include a 30-day money-back guarantee, so there's no refund window to fall back on. Start on the smallest plan that meets your app's minimum, and change plans when the checks below show it running short.

How to tell you've outgrown your plan

Before you pay for a bigger plan, find out whether memory, CPU or disk is running short, because each one points to a different upgrade. DreamHost's Help Center says the Performance and Logs dashboards are on Managed VPS only, so on a VPS you check from the command line while the app is busy. These commands run the quick ones:

free -h
cat /proc/pressure/memory
uptime
df -h

1. Check available memory

   Run free -h during normal use. The available column estimates how much memory new programs can get without swapping. If it stays near zero, or swap use keeps climbing, the app is probably short on memory. App logs show it too: n8n logs JavaScript heap out of memory when a workflow runs out.

2. Check memory pressure

   Run cat /proc/pressure/memory. The full line is the share of time every running task waited on memory at once, and the kernel docs say a workload that spends extended time in that state is thrashing. If it does, move to the next plan up for more memory: Stack 4 to 8, 8 to 16, or 16 to 32.

3. Compare load with your cores

   Run uptime and read the third number, the 15-minute load average. Load isn't scaled to your core count, so compare it with your plan's vCPU: 2 on Stack 4 and Stack 8, 4 on Stack 16, 8 on Stack 32. As a rule of thumb, we'd treat a 15-minute load that sits above that number for days as a sign you're short on CPU. From Stack 4 or Stack 8, that points to Stack 16.

4. Look at steal time

   Run vmstat 5 and watch the st column, which is time the hypervisor took from your server. As a rule of thumb, if steal stays above a few percent, ask support about it before you pay for a bigger plan.

5. Check disk space
   Run df -h to see how full each filesystem is.
6. Upgrade in the panel

   DreamHost's Help Center gives these steps: go to Manage Account, find your VPS under Active Plans, click Manage, then Select Plan under Change Plan and Submit Order.

Growing swap can be an early warning, too. As one Hacker News commenter pointed out, a monitor on swap use can tell you something's wrong before the kernel starts killing processes for lack of memory.

If a burst of traffic is behind the load, read about handling a traffic spike before you move up.

When another DreamHost product fits better

If you'd rather we managed the server, DreamPress, Managed VPS or Managed Dedicated Server Hosting may suit you better. If you're not sure you need a server at all, start with do you need a VPS at all.

Managed Dedicated gives you a managed server with root, and its Enhanced plan goes up to 128 GB of memory, so read when a dedicated server is the next step once you've outgrown Stack 32. For new or simple sites, Web Hosting is the place to start, and its Launch plan covers 25 websites and an estimated 40k monthly visits. If a MySQL database is what slows down your Managed VPS sites, the MySQL VPS add-on gives it isolated database resources as a separate service.

VPS sizing FAQs