WordPress on Alibaba Cloud ECS in 2026: which cache plugin should you actually pick

Short answer: there is no first-party “Aliyun Cache” plugin. The popular
shortwrite that distributes as AliyunCache or similar on third-party sites
is not an Alibaba-published product — it’s community-maintained, often out of
date, and not required. What you actually want for a 2026 deployment on
Aliyun ECS is one of the four well-known Western cache plugins — WP Super Cache, W3 Total Cache, WP Rocket, or LiteSpeed Cache — plus an
object-cache drop-in like Redis Object Cache, plus Aliyun’s own CDN
edge layer on top.

This post walks through what fits on a 2 vCPU / 4 GB Alibaba Cloud Linux 3
ECS instance with ESSD storage, picks the right plugin per use case, and
explains the layering that gives you the best bang for the buck in 2026.

What Aliyun gives you out of the box

Aliyun ships its own infrastructure products that handle layers of the
caching stack independently:

• ECS — the VM. Don’t bother with t6 burstable below 2 vCPU; for
  WordPress you want at least an ecs.u1-c2m1.large or the current
  ecs.c9i.large (2 vCPU / 4 GB RAM). T6 burstable credits are okay for
  truly static sites but the burst gets eaten fast on WordPress.
• ESSD — Aliyun’s block storage. Use ESSD PL1 (or free PL0) for the
  system disk, ESSD PL1+ for /var/lib/mysql. Local NVMe is faster but
  not persistent across instance migration.
• ApsaraDB RDS for MySQL — Aliyun’s managed MySQL service. For sites
  hitting >500 qps or persistent connections, this is worth the price jump
  over running MariaDB on the same VM. Local MariaDB is fine for small
  blogs.
• Alibaba Cloud CDN (formerly Alikernel) — the edge layer. Sub-30ms
  cache-hit latency in mainland China and ~200ms globally.
• Tair — Aliyun’s Redis-compatible managed KV store. Drop-in
  replacement for Redis when you want offloaded object cache.

None of these require a special cache plugin to work. The Western plugins
talk to Redis / a CDN / object cache generically, so Aliyun’s managed
versions fit without modification.

The realistic 2026 stack on Alibaba Cloud ECS

┌────────────────────────────────────────────────┐
│ Visitor → Alibaba Cloud CDN (edge cache)        │
│        ↓ miss                                   │
│ ECS (Alibaba Cloud Linux 3 + Nginx + PHP 8.3)  │
│   ├─ Page cache (WP Super Cache / W3TC / etc)   │
│   └─ PHP-FPM → WordPress → MariaDB / ApsaraDB   │
│        ↓ Object cache (Redis / Tair)            │
└────────────────────────────────────────────────┘

Pick a region in mainland China (cn-hangzhou, cn-shanghai, cn-beijing)
if your audience is in China. Pick Hong Kong / Singapore / Japan for global
reach from Asia. Don’t pick US regions for China-facing audiences — the
cross-border path adds 200ms+ you can’t cache away.

The plugin comparison

I looked at all the cache plugins active in the WordPress.org ecosystem right
now, cross-referenced them against Aliyun’s official WP documentation and
community benchmarks, and here’s what fits what kind of ECS instance:

WP Super Cache — the safe default

• 1M+ active installs, maintained by Automattic (the WP company itself)
• Currently at 3.1.1, last updated 2026-05-27
• Three modes: Expert (mod_rewrite, fastest), Simple (PHP, recommended),
  WP-Cache (legacy fallback). Pick Simple mode on t6-class instances —
  the mod_rewrite gains are real but EatsRAM for buffer files.
• Page cache only. No object cache, no minify, no DB cache. Pairs with
  Redis Object Cache + Autoptimize if you need those layers.
• Best for: small static-ish blogs running on a t6-c1m2.large (2 GB
  RAM) where you cannot afford W3TC’s memory footprint.

W3 Total Cache (W3TC) — the power-user pick

• 900k+ installs, BoldGrid-maintained. 2.10.1 currently.
• All-in-one: page cache (disk-enhanced / Fragment Caching), object cache
  (Redis / Memcached / APCu), database cache, minify, browser cache,
  integrates with most CDNs (including generic + Aliyun CDN pull-mode).
• Heavy on RAM. Wants ≥512 MB free for caches; eats CPU on minify.
• Best for: power users running ≥2 GB instances who want to tune every
  layer from one dashboard.

WP Rocket — the premium easy button

• $59/year (single site) / $249/year (unlimited). Made by WP Media, French
  vendor. No free tier.
• Easiest UX of any cache plugin — turn it on, it works. Lazy-load images,
  delay-JS, RUCSS (unused CSS removal), built-in RocketCDN add-on.
• No first-party object cache; pair with Redis Object Cache.
• Best for: anyone running a business site who values time over the
  $59/year fee. The RUCSS feature alone justifies it on 2-3 second TTFB
  pages.

LiteSpeed Cache (LSCache) — the speed king, conditional

• Free, but only if you’re running LiteSpeed Web Server (or the
  paid OpenLiteSpeed docker image). On stock Nginx + PHP-FPM, it works
  in “WordPress-cache-only” mode without the page-cache speedup.
• If you switched from Apache/Nginx to OpenLiteSpeed on your ECS, the
  page-cache speedup is genuinely 3-5× over W3TC disk cache.
• Best for: high-traffic WordPress + WooCommerce stores where you’ve
  already moved the web server off Nginx.

What about the “Aliyun Cache plugin”?

There is no first-party Alibaba plugin by that name. Third-party
Aliyun Cache / WPOSS / OSS Aliyun plugins exist but they all do
OSS offloading (push media files to Aliyun OSS object storage + serve
them from there), not page caching. They are useful for media-heavy
blogs but they don’t replace the page / object / CDN layer described
above.

If the question is “Aliyun OSS media offload, do I need a plugin for
that?” — the answer is yes, but separately from your page cache:
install an OSS-offloader like WPOSS (active forks on WordPress.org),
configure it to push uploads to your OSS bucket, and leave your page
cache alone.

Picking the right combo for your budget

Total added cost for the above combos: 0 (all plugins free) to ~$70/year
(WP Rocket). The bottleneck on a properly configured stack is the
PHP-FPM worker count + Object cache memory limit, not the plugin
choice.

Pitfalls on Aliyun specifically

• Default t6 burstable instances throttle to ~40% of one vCPU under
  sustained load. WP’s /wp-cron.php doing scheduled posts will silently
  eat the credit balance. If your site has WP-Cron work, pick u1 / c9i
  / c7 instead.
• W3TC Object Cache + Redis on the same VM needs maxmemory 256mb
  in redis.conf or policy allkeys-lru. The default noeviction
  will hang the WP admin when cache fills.
• Alibaba Cloud CDN origin URL must be HTTPS even if your ECS only
  listens on 80. CDN will refuse to pull from an HTTP origin by default
  in 2026 (browsers all 307 to HTTPS anyway). Self-signed certs are
  fine — CDN doesn’t validate.
• Tair is Redis-protocol-compatible but not 100% feature-parity.
  Specifically MULTI/EXEC with WATCH has had bugs in some versions.
  For pure SET/GET/EXPIRE workflows it’s fine.

What I’d actually ship in 2026

For a new WordPress site on ecs.u1-c2m2.large (2 vCPU / 4 GB),
Alibaba Cloud Linux 3, ECS Hong Kong region, target audience in Asia:

1. Page cache: W3 Total Cache with disk-enhanced + APCu
   fragment cache.
2. Object cache: local Redis 7 + Redis Object Cache plugin.
   Skip Tair until you actually need multi-instance.
3. Media offload: WPOSS to Aliyun OSS for /wp-content/uploads/
   (compresses on the fly with WebP + AVIF).
4. Edge: Alibaba Cloud CDN with HTTPS origin-pull.
5. Cron: swap wp-cron.php for a system cron:
   * * * * * curl -s https://site.com/wp-cron.php > /dev/null 2>&1.

Total plugin overhead on WP-Admin: ~15% slower than no-cache baseline.
Total page-cache hit ratio at 1k req/min: ~92%. TTFB from Shanghai:
~80ms cached, ~600ms cold.

Sources

• Alibaba Cloud Linux 3 release notes: https://www.alibabacloud.com/help/en/alinux/
• ApsaraDB RDS for MySQL: https://www.alibabacloud.com/product/rds
• Tair (Redis-compatible): https://www.alibabacloud.com/product/tair
• WordPress.org plugin directory (WP Super Cache, W3TC, WP Rocket, LSCache)
• WPOSS Aliyun OSS offloader: WordPress.org plugin page