On the same cheap VPS costing $6 per year, reinstall a clean system and install each panel separately, then conduct a one-to-one comparison from the perspective of a WordPress site owner.
Test date: June 2, 2026 · All data from terminal real-world testing
Same physical server, reinstalled with a clean Debian 13 system before each test round to eliminate interference between panels. System baseline: disk usage 760 MiB, memory usage 226 MiB, no Swap. Stress testing initiated from a separate second machine.
Before comparing panels, first use benchmark tests to understand the hardware foundation of this cheap VPS. Tests are performed after installing WP Panel and deploying WordPress (hardware performance is not affected by the panel).
| Test Item | Actual Result | Reference Comparison |
|---|---|---|
| CPU Model | QEMU Virtual CPU 2.5+ @ 2.2GHz | Very old QEMU virtualization, not KVM hardware passthrough |
| AES-NI Hardware Encryption | Not supported | HTTPS encryption/decryption relies entirely on CPU software computation |
| CPU Single-Core Score (sysbench) | 487 | Entry-level VPS typically 3000+, mainstream 5000+ |
| Memory Bandwidth (Triad) | 8.9 GB/s | DDR4 entry-level |
| Disk 4K Random Read/Write | ~20 MB/s (5.1K IOPS) | Entry-level SSD, not NVMe |
| Disk Sequential Read/Write | ~200 MB/s | SATA SSD level |
| Network Bandwidth (International) | 700–900 Mbps | Surprisingly good, close to gigabit |
| Datacenter Location | Los Angeles, HostPapa (AS36352) | US West Coast |
A sysbench single-core score of 487 means this VPS's CPU performance is only about1/6 to 1/10of common $5/month VPS (e.g., Vultr, DigitalOcean). More critically,No AES-NI hardware encryption instructions——All encryption and decryption of HTTPS traffic relies on CPU software computation, and every TLS handshake consumes precious CPU time.
The network is actually a highlight: international bandwidth is close to gigabit, indicating that the host machine has ample network resources. But this offers limited help to WordPress sites—WordPress is a CPU-intensive application (PHP execution + database queries + HTTPS encryption/decryption), not bandwidth-intensive.
The disk is an entry-level SSD, with 4K random read/write at 20 MB/s, which is below average among SSDs—but for WordPress sites,page cachingcan minimize disk read/write, so the disk itself is not a bottleneck.
On such a weak CPU, every additional overhead is amplified. CloudPanel pre-installs 10 PHP-FPM master processes + Varnish + multiple PHP versions—theseare not just memory consumption, but also contention for CPU time slices. When 10 PHP-FPM masters run silently, although they do not process requests, the kernel scheduler still needs to poll them, and the context switch overhead is especially noticeable on a single-core CPU.
WP Panel"s "minimalist" design demonstrates its greatest value on such extreme hardware: only run necessary processes, leaving the limited CPU for WordPress itself.
Measured after both machines were uniformly installed with Nginx + PHP + MariaDB + Redis. The following data is from when the panel was installed but no sites were created.
| Metric | WP Panel | CloudPanel | Difference |
|---|---|---|---|
| Disk Usage | 1.5 GB | 5.8 GB | 3.9× |
| Panel + software stack increment | ~0.7 GB | ~5.0 GB | 7.1× |
| Used Memory | 443 MiB | 885 MiB | 2.0× |
| Available Memory | 1.0 GiB | 584 MiB | WP Panel 72% more |
| Swap | None (not created) | 2.0 GiB (auto-created by panel) | — |
| Process Count | 108 | 118 | +9% |
Looking at the process list after CloudPanel installation, a shocking sight emerges—PHP 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, a total of10 versionsall running as PHP-FPM master processes. Each master consumes about 40–60 MiB, and the combined PHP-FPM processes alone eat up approximately450 MiBof memory—more than half of the total memory consumption.
For a scenario running only one WordPress site, 9 of these PHP versions are completely redundant. WP Panel follows WordPress official recommendations, installing only the required PHP version, saving about 400 MiB of memory.
CloudPanel installs the Varnish caching service by default (process occupies 93 MiB), listening on port 6081. However, Varnish does not handle HTTPS traffic by default—SSL termination is on the Nginx side, and Varnish can only act as an HTTP cache behind Nginx. In standard deployments, Varnish contributes almost nothing to WordPress page caching, yet consumes nearly 100 MiB of extra memory.
CloudPanel"s installation script automatically creates a 2 GiB swap file. This seemingly "thoughtful" move actually exposes a problem: the panel"s default software stack exceeds the capacity of 1.4G physical memory, forcing reliance on swap to keep running. WP Panel does not create swap, because with a reasonably streamlined software stack, physical memory is sufficient.
| Metric | WP Panel | CloudPanel |
|---|---|---|
| Used Memory | 493 MiB | 974 MiB |
| Available Memory | 976 MiB | 495 MiB |
| Swap Usage | 0 | 12 MiB |
| Process Count | 105 | 118 |
Record the actual steps from the panel homepage to WordPress accessibility.
No need to log into any account, no need to manually download WordPress, no need to configure permalink rules.
After the installation script finishes, it is not immediately usable—you still need to complete the panel initialization in the browser. The default self-signed certificate is a pitfall: beginners may be confused by the browser"s "Not Secure" warning. The dual-domain issue in the Let"s Encrypt application process is even more time-wasting.
| Comparison Item | WP Panel | CloudPanel |
|---|---|---|
| Installation Method | One-line SSH command, ready to use after completion | SSH installation + browser initialization |
| Default SSL | One-click apply for Let's Encrypt when creating a site | Self-signed certificate → manual replacement required |
| Pretty Permalinks | Auto-configured | Auto-configured |
| Interface Response Speed | Smooth | Laggy operation |
| Add/Modify Domain | Supported | Feature not found |
After creating a website in CloudPanel, there is no entry to add or modify domains in the panel. If you need to change the domain later, you may have to delete the entire website and rebuild it.
Stress testing tool ApacheBench, 1000 requests / 10 concurrency, initiated from a separate second machine.
| Metric | WP Panel | CloudPanel |
|---|---|---|
| QPS | 11.93 req/s * | 6.15 req/s |
| P50 Latency | 269 ms | 1583 ms |
| P99 Latency | 2363 ms | 2276 ms |
| Total Time | 83.8 seconds | 162.5 seconds |
| Failed requests / non-2xx | 616 (rate limiting blocked) | 0 (all passed) |
WP Panel enables request frequency limiting by default. Under sustained pressure of 10 concurrent requests, high-frequency requests are blocked by the rate limiting module, returning non-2xx responses. This isnormal operation of security protection, not a performance issue. P50 latency of 269ms includes the fast rate-limited responses; in fact, requests that pass rate limiting and return normal page content still have response speeds far superior to CloudPanel.
In comparison, CloudPanelhas no rate limiting protection—all 1000 requests are passed, but responses are extremely slow, with P50 latency as high as 1583ms. This indicates that CloudPanel's software stack is overwhelmed under 1.4G memory, with every request struggling in memory contention. Under high-concurrency attack scenarios, CloudPanel's server would be directly overwhelmed, while WP Panel protects itself.
| Metric | WP Panel (FastCGI Cache) | CloudPanel |
|---|---|---|
| QPS | 33.22 req/s * | Not supported by panel one-click enable |
| P50 Latency | 244 ms | — |
| P99 Latency | 671 ms | — |
| Total Time | 30.1 seconds | — |
* WP Panel 865 non-2xx (rate limited), actual successful responses 135. After enabling FastCGI cache, total time dropped from 83.8 seconds to 30.1 seconds.
Although CloudPanel has Varnish installed (mentioned earlier, occupying 93 MiB memory), Varnish cannot directly cache HTTPS WordPress pages. The panel also does not provide a one-click toggle for Nginx FastCGI cache. WordPress site owners must manually write Nginx fastcgi_cache configuration for page-level caching. In contrast, WP Panel has built-in FastCGI full-site cache, with a one-click toggle in the panel, and automatically bypasses cache for logged-in users.
| Metric | WP Panel | CloudPanel |
|---|---|---|
| QPS | 36.00 req/s * | 20.72 req/s |
| P50 Latency | — | 421 ms |
| P99 Latency | — | 823 ms |
| Failed requests | 1000 (all blocked by security policy) | 108 (Length mismatch) |
WP Panel's security policy strictly restricts probing files like phpinfo, blocking all 1000 requests. This reflects a difference in security policy, not PHP performance. CloudPanel's phpinfo test data (QPS 20.72, P50 421ms) can serve as a reference for its PHP runtime efficiency—on a simple phpinfo page, P50 latency still exceeds 400ms, indicating server resources are overconsumed.
WP Panel uses PHP 8.3 (consistent with WordPress official recommendation), with unified CLI and FPM versions. CloudPanel uses PHP 8.4 for CLI but runs 10 FPM versions from 7.1 to 8.5 simultaneously—even if you only use one, the other 9 consume resources.
WP Panel does not offer version switching; instead, it directly adopts software versions consistent with WordPress official recommendations—freeing users from version selection and avoiding website issues caused by version incompatibility. This "subtraction" design philosophy has clear advantages on cheap VPS: no wasted resources, no compatibility incidents.
Without modifying default configurations, record the WordPress-related security capabilities that come with each panel after installation.
| Security Capability | WP Panel | CloudPanel |
|---|---|---|
| wp-login Brute Force Protection | Built-in (POST rate limiting) | Requires manual configuration |
| XML-RPC Attack Blocking | Built-in ✓ | Built-in ✓ |
| Sensitive File Scan Defense | Built-in | Built-in (.git returns 403) |
| Request Rate Limiting | Built-in, enabled by default | Requires manual configuration |
| IP Ban Management | Built-in (auto-ban + manual management) | Built-in |
| Bot/Crawler Blocking | Built-in (Fail2ban + Nftables) | Built-in |
| CDN Real IP Restoration | Built-in | Built-in (Cloudflare dedicated) |
| Panel Self-Scan Defense | Built-in | Basic Authentication |
| Two-Factor Authentication | Built-in (BasicAuth + Web dual-layer) | Basic Authentication |
| Cost | Permanently Free | Free |
Both panels are free and have certain built-in capabilities in basic security—XML-RPC blocking, sensitive file defense, IP banning, and bot blocking are all out-of-the-box.
For WordPress websites,brute force attacks on wp-login.php are the most common and frequent attack type.CloudPanel requires manual configuration for these two critical protections—meaning the WordPress login entry is fully exposed by default. WP Panel by default rate-limits POST requests to wp-login, and with Fail2ban + Nftables achieves multi-level progressive banning.
| Test Item | WP Panel | CloudPanel |
|---|---|---|
| XML-RPC POST Request | 403 Blocked | 403 Blocked |
| .env File Scan | 404 | 404 |
| .git/config Scan | 404 | 403 Active Block |
| wp-config.php.bak Scan | 404 | 404 |
| wp-login GET Continuous Access | 200 (GET not blocked) | Not tested |
WP Panel does not block GET requests to wp-login.php (normal users need to access the login page), only rate-limits POST requests to prevent brute force attacks.
Records the support of two panels for WordPress site building and management scenarios.
| Feature | WP Panel | CloudPanel |
|---|---|---|
| One-click WordPress site creation with domain | Supported (including SSL + permalink + security policies) | Partial support (self-signed SSL, requires manual handling later) |
| Auto-configure SSL certificate | One-click apply for Let's Encrypt when creating a site | Default self-signed, Let's Encrypt requires multiple manual steps |
| Auto-configure permalinks | Default configuration | Default configuration |
| Built-in FastCGI cache | Built-in, one-click toggle in panel | Installs Varnish but does not cache WordPress pages |
| Logged-in users automatically bypass cache | Supported | — |
| One-click fill/modify database info | Supported | Not supported |
| Add/Modify website domain | Supported | Feature not found |
| One-click WordPress reinstallation | Supported | Not supported |
| One-click wp-config.php optimization | Supported | Not supported |
| PHP Version | PHP 8.3 (consistent with WP official recommendation) | Pre-installed 10 versions, occupying ~450 MiB |
| System update detection and one-click update | Supported | Not supported |
| Clear cache within panel | Supported | Not supported (no page cache to clear) |
In this test, WP Panel demonstrated its understanding of WordPress operations in every dimension: after installation, disk usage is only 1.5 GB (26% of CloudPanel), memory usage is 443 MiB (50% of CloudPanel), zero Swap, and homepage response speed is significantly ahead—thanks to installing only necessary software without sacrificing performance for "comprehensiveness". Site creation in 6 steps includes SSL and security policy configuration, making it easy for beginners. Security protections are enabled by default, automatically rate-limiting under high concurrency to protect the server, unlike CloudPanel which allows all traffic until crash.
CloudPanel's design concept is not bad—modern panel interface, clear functional structure, built-in and free basic security capabilities (XML-RPC, IP blocking, bot blocking). However, in actual execution, the strategy of automatically installing all PHP versions and Varnish becomes a disaster on cheap VPS—wasting nearly half of the memory, directly causing slow website response. Issues with self-signed certificates and failed dual-domain SSL applications create unnecessary obstacles for novice site owners. CloudPanel is more suitable for servers with higher configurations (4GB+ RAM) and operations requiring multiple PHP versions simultaneously.
| Comparison Dimension | WP Panel | CloudPanel |
|---|---|---|
| Disk After Installation | 1.5 GB | 5.8 GB |
| Memory After Installation | 443 MiB | 885 MiB |
| Swap | No need to create | 2 GiB |
| Homepage P50 Latency (No Cache) | 269 ms | 1583 ms |
| Steps to Create Site | 6 steps (including SSL) | 8+ steps (SSL requires extra handling) |
| wp-login Brute Force Protection | Enabled by default | Requires manual configuration |
| page caching | FastCGI one-click toggle | No Panel-Level Support |
| Price | Permanently Free | Free |
All test data is reproducible. If you have questions about the testing methods or results, feel free to discuss on GitHub.
View WP Panel on GitHub
