Choosing the right VPS plan size for your workload

"Which plan should I order?" is the most-asked pre-sales question. The honest answer depends on the workload — over-provisioning wastes money, under-provisioning causes the project to fail. This article gives sizing rules of thumb for the typical use cases LYLIX customers deploy.

The four constraints, in order of impact

1. RAM — the hardest constraint to fix after the fact. Run out of RAM and your VPS thrashes (or worse, OOM-kills your processes). Bump up first when sizing.
2. CPU — easier to add later via plan upgrade. Most workloads spike rather than sustain; sizing for average + headroom usually works.
3. Disk — easy to underestimate if you don't think about logs, caches, database growth. Plan for 2× your current need.
4. Bandwidth — unmetered on LYLIX, so usually not a sizing concern. Becomes relevant if you're streaming media or running heavy outbound (mail, file distribution).

Common workloads with sizing

Personal website / blog (Ghost, WordPress, static)

• 1 GB RAM, 1 vCPU, 20-30 GB disk.
• Handles thousands of visitors/day before needing more.
• WordPress with heavy plugins is the variable — easily 2 GB if you load up.

Self-hosted apps (Vaultwarden, Uptime Kuma, Healthchecks)

• 1 GB RAM, 1 vCPU each. Sometimes you can share one VPS across several small apps via Docker.
• 20-30 GB disk plenty.

Heavier self-hosted (Nextcloud, Mastodon, Matrix)

• 4 GB RAM minimum, 2 vCPU. 8 GB and 4 vCPU is more comfortable.
• Storage scales with usage — Nextcloud with 100 GB of files, Mastodon with extensive media cache, all add up.
• Mastodon specifically: 8 GB is realistic for a small instance with active federation.

Mail server (Postfix + Dovecot, single domain, < 20 users)

• 2 GB RAM, 1-2 vCPU. Mail is mostly I/O, not CPU.
• Storage: estimate ~5 GB per heavy user (long mail history with attachments), 1-2 GB per light user.

PBX VPS (FreePBX or FusionPBX, < 20 extensions)

• 2 GB RAM, 2 vCPU. Lower can work but the GUI feels slow.
• Storage: 30-50 GB. CDRs accumulate but slowly.
• Per concurrent call: ~30 kbps bandwidth + minimal CPU. Sizing concern is rarely calls themselves; it's the GUI + recording storage.

PBX VPS with call recording

• Same RAM / CPU as above.
• Storage: ~30 MB per hour of recorded call. 50 hours/day average call volume = 1.5 GB/day = ~550 GB/year. Plan accordingly.
• For most installations, off-host recording storage (S3-compatible) is the right answer past a few months of retention.

ViciDial / call center (small, 5-20 agents)

• 4 GB RAM, 2-4 vCPU. ViciDial's MariaDB is the load driver.
• Storage: depends on call recording retention — 100 GB is the floor; 500 GB if you keep months of recordings on-box.
• Smaller-than-recommended plans tend to demo fine but break under real campaign load — size for the live workload, not the trial.

Database server (PostgreSQL or MariaDB, dedicated)

• 4 GB RAM minimum (database engines hate small RAM). 8-16 GB for serious work.
• vCPU scales with query workload — 2-4 for typical web-backed DBs.
• Disk: working set size + room for indexes + growth. Database that's currently 20 GB will be 50 GB in a year.

Game server (Minecraft, Factorio, etc.)

• Minecraft vanilla, < 10 players: 2 GB RAM, 1-2 vCPU.
• Modded Minecraft, < 10 players: 6-8 GB RAM.
• Factorio megabase: needs the fastest single-core CPU possible — game scales poorly across cores. The vCPU count matters less than the per-core performance.

How to tell you've under-sized

• RAM: free -h shows used + buffers approaching total; swap is being touched regularly; OOM messages in dmesg.
• CPU: uptime load average sustained above the vCPU count; vmstat 1 shows "wa" (I/O wait) or "sy" (system) spending lots of time.
• Disk: df -h shows the root filesystem above 80%; iostat shows queue depth above 5 sustained.

Right-sizing strategy

Order small, upgrade if needed. Plan upgrades take effect on next reboot; see the upgrading your VPS plan article for the exact mechanics and what each resource change requires.

If you're not sure, pick the plan one tier above the rule of thumb above. Cheap insurance against the project failing to ship while you re-architect for a bigger box.