How to Choose a VPS Configuration (2026): What 1 Core/1 GB, 2 Cores/2 GB, and 2 Cores/4 GB Can Actually Run

The following is capacity planning advice, not a vendor performance promise. CPU model, overselling level, disk I/O, network route, and software configuration all change the result.

If you don't want to do any resource estimation at all, start personal projects directly at 2 cores/2 GB; if you plan to run WordPress + database + Redis, or around 5 lightweight containers, 2 cores/4 GB is usually less hassle.

The "5 containers" here is not a hard metric. An idle Caddy container and a Java search service can differ in resource consumption by dozens of times. What really matters is the program inside the container, not the number of containers.

Many articles like to write "WordPress minimum 1 GB" or "Docker minimum 2 GB," which look certain but are often not actually official statements.

1 GB of memory is best suited to projects with "a single task, few services, and small data."

I would use it for:

• Nginx/Caddy static sites;
• Personal navigation pages, status pages;
• Lightweight monitoring like Uptime Kuma, with not too many monitors;
• Small Telegram/Discord bots;
• Personal WireGuard nodes;
• Temporary development and command-line tasks;
• Lightweight API gateways that only forward requests and don't run models locally.

Not recommended to run simultaneously on 1 GB:

• BaoTa/1Panel + WordPress + MySQL;
• Multiple automation tasks requiring Chromium;
• Java applications;
• GitLab, a full monitoring suite, or a multi-service AI platform;
• Docker environments without log size limits.

If you've already bought 1 GB, you can use ZRAM or Swap to give burst memory a buffer, but they are not free memory. Continuous swapping will slow down the disk, and eventually you still need to reduce services or upgrade. For specific configuration, see: How to Optimize a Low-Memory VPS with ZRAM and Swap (2026).

The point of 2 GB is not "double the performance," but that the operating system, logs, database, and applications no longer have to squeeze into the last few hundred MB.

This tier is better suited to:

• A single low-traffic WordPress;
• Personal blogs like Typecho, Ghost;
• Caddy/Nginx + application + small database;
• 2–4 lightweight Docker services;
• Small Git, Webhook, automation tasks;
• Development and testing environments.

When running WordPress, I would limit the number of plugins, enable OPcache, limit PHP-FPM child processes, and set MySQL caches appropriate for a small-memory machine. As traffic grows, first look at slow queries, PHP-FPM queues, and cache hit rates—don't blindly add cores the moment it slows down.

If you're already on 2 GB but WordPress is still slow, see: What to Do When WordPress Is Slow on a VPS (2026).

4 GB won't automatically make a website faster, but it leaves room for database caches, Redis, build tasks, and container restarts.

Common uses include:

• WordPress + MySQL/MariaDB + Redis + Caddy;
• 5–10 low-load containers;
• Two or three sites with low traffic;
• Node.js/Python API + PostgreSQL;
• Combinations like n8n, Directus, Uptime Kuma;
• Small team testing environments.

"5–10" is still only a planning range for lightweight services. When containers include browsers, Elasticsearch, model inference, or large numbers of concurrent tasks, 4 GB can just as easily run out quickly.

This tier suits people who don't want to migrate every time they add a service. When the monthly price difference is acceptable, I'd rather leave about 25% memory headroom than have the machine run at 95% year-round.

Production Docker Compose should also limit per-container resources, to avoid one abnormal task dragging down the whole machine: How to Configure Docker Compose for Production on a VPS (2026).

Once you reach 8 GB or even 16 GB, the question is no longer just "buy bigger."

If the application, database, object storage, and backups are all on one machine, any single system failure will take them all down together. Once the business starts to matter, consider:

• Separating application and database;
• Putting large files in object storage;
• Putting backups with a different provider or in a different region;
• Using hourly instances separately for build tasks;
• Leaving an independent small node for monitoring and status pages.

Scaling up a single machine has the advantages of simplicity and low internal network latency; splitting has the advantages of clear failure boundaries and more flexible scaling. Small projects don't need to adopt a complex cluster early for the sake of "architectural correctness," but when the database already eats half the memory, it's time to do the math seriously.

"4 cores" only says how many vCPUs are allocated, not how fast each core is, nor how long you can continuously occupy them.

Before buying, at least confirm:

• CPU model and generation;
• Shared CPU or dedicated CPU;
• Whether obvious steal time is visible;
• Whether the vendor limits sustained high CPU;
• ARM or x86, and whether the software is compatible.

2 cores of a high-frequency new CPU may actually compile and respond to PHP more comfortably than shared 4 cores on an old platform. If load is unchanged during evening peak but performance drops noticeably, check overselling and neighbor contention: How to Judge VPS Overselling (2026).

ARM plans are often attractively priced, but closed-source panels, old images, and software that only ships amd64 binaries may not support them. Before buying, see: Is an ARM VPS Worth Buying (2026).

20 GB looks like enough for the system and a website, but Docker images, build caches, databases, backups, and logs will slowly eat it up.

I would reserve:

• System, packages, and basic logs: at least 8–12 GB;
• Docker images and container layers: an extra 10–30 GB depending on the application;
• Database: plan 2–3 times the current data volume for growth and temporary space;
• Local backups: don't keep only one copy, and certainly don't treat it as off-site backup.

For databases and container environments, prefer SSD/NVMe. With the same nominal capacity, sustained write and random I/O can differ greatly; after ordering for important business, you should run fio, but don't do destructive tests during production peak hours.

A 1 Gbps port doesn't mean unlimited data per month. The port is the instantaneous ceiling; the traffic package determines how much can be transferred in a month.

A simple estimate:

月出站流量 ≈ 页面平均大小 × 月页面浏览量 × 未命中 CDN 的比例

For example, with an average page size of 1 MB and 100,000 views per month, all served directly from the origin, that's about 100 GB. If images go through a CDN and browser cache hits, origin traffic will be much lower; video, downloads, and backups will rapidly amplify traffic.

When traffic is tight, monitor first—don't wait until the suspension email arrives: VPS Traffic Monitoring and Over-Quota Alerts (2026).

Below is a snapshot of the Directus plan library as of July 18, 2026, used only to show how the 1 GB, 2 GB, and 4 GB tiers compare, and not as a performance endorsement. Prices, stock, network routes, and renewal rules change; the checkout page prevails before ordering.

For cheap plans, pay even more attention to virtualization, refunds, renewals, data center, and CPU usage policy. Before buying an annual machine for the first time, it's advisable to first find a monthly plan or test IP to verify the network route; no matter how cheap the machine, important data must have off-site backups.

Don't decide to upgrade based on "it feels slow." Observe continuously for several days first, including business peak hours.

# 内存、可用内存和 Swap
free -h

# 每秒观察运行队列、换页和 CPU 等待
vmstat 1

# Docker 容器实时资源占用
docker stats

# 磁盘空间与文件系统
df -h

# 磁盘延迟、队列和利用率，需要安装 sysstat
iostat -xz 1

# 最近是否发生 OOM
journalctl -k --since "24 hours ago" | grep -i -E "oom|out of memory|killed process"

Signals that you need to upgrade are usually:

• Available memory stays very low during peak hours, with continuous Swap in/out;
• OOM Kill appears in logs;
• CPU is maxed out for long periods, and the run queue stays above the vCPU count;
• iowait and disk latency stay high;
• Remaining disk space is below 15%–20%;
• Containers restart repeatedly due to memory limits;
• Resources are still insufficient after optimizing code, caching, and queries.

A single spike doesn't mean you must upgrade. Backups, updates, log compression, and scheduled tasks can all briefly raise load; judge based on duration and business impact.

• Does the workload need x86 or support ARM;
• Is the CPU shared or dedicated, and is there a sustained usage limit;
• Does memory include usable Swap, and can it be upgraded later without loss;
• Is storage NVMe, SSD, or HDD;
• Is traffic one-way, two-way, or unlimited with fair use;
• Is port bandwidth shared, and how is overage traffic billed;
• Is IPv4 included, and how are extra IPs charged;
• What is the evening-peak route from the data center to target users;
• Rules for refunds, renewals, migration, and IP changes;
• Is there a console, rescue mode, snapshots, and backups;
• Have you tested the same data center before paying annually;
• Does important data have an off-site recovery plan.

For static sites, monitoring, or small tools only, I'd buy 1 GB, provided the service is single, logs are controlled, and data is backed up.

For personal blogs and low-traffic WordPress, I'd start at 2 cores/2 GB; if I plan to install a panel, Redis, multiple containers, or don't want to migrate again in a few months, I'd go straight to 2 cores/4 GB.

Once the business reaches 8 GB or more, I wouldn't just look at "a bigger single machine," but would also evaluate whether the database, object storage, backups, and monitoring should be split apart. Choosing the right configuration isn't about buying the biggest once, but about giving the current workload headroom while not locking yourself out of future upgrades.