Research Report 12 min read April 2026

Managed WordPress Hosting for Developers: Infrastructure Reference 2026

Most managed WordPress hosts offer SSH, WP-CLI, and staging. The differences that matter for developer workflow — per-site PHP versioning, infrastructure transparency, cache control APIs, deployment integration — are in the layers below the feature checklist.

Technical reference based on LiteSpeed Enterprise documentation, WordPress deployment engineering patterns, and managed hosting infrastructure analysis. Specific figures for WP Pro Host plans are accurate at time of publication.

Key Findings

What the infrastructure analysis shows

Four technical findings shape the developer-hosting relationship. Each one has a direct effect on workflow quality, build reliability, and what you can commit to in client deliverables.

Most managed hosting restrictions exist to protect shared tenants — not because the access is inherently dangerous

Restrictions on PHP configuration, resource limits, and process access on shared managed hosting exist to prevent one account from affecting others. On container-isolated dedicated infrastructure, those same operations are safe — and the restrictions are removed. The capability difference is architectural, not policy-based.

LiteSpeed LSAPI handles the same PHP worker count with lower memory overhead than PHP-FPM

For equivalent PHP worker allocation, LSAPI uses less memory per worker than PHP-FPM and restarts crashed workers faster. On a resource-constrained plan this is meaningful — the same worker count is more efficient. For WooCommerce or membership sites with complex plugin stacks, this is the difference between consistent and variable concurrency behaviour.

Per-site PHP version control is a workflow requirement, not a nice-to-have

An agency or freelancer managing client sites across different projects cannot be on a single PHP version. PHP 8.3 for a legacy WooCommerce configuration, PHP 8.5 for a new Bricks build — both on the same account. The alternative is separate hosting accounts, which multiplies cost and management overhead.

Staging that runs on different infrastructure from production produces unreliable test results

If staging runs on a shared cloud and production runs on dedicated bare-metal, a performance test on staging is not predictive of production behaviour. A plugin that runs acceptably on staging may hit PHP worker limits on production under real concurrent load. Real staging parity requires matching infrastructure, not just matching files and database.

The restrictions on shared managed hosting are not arbitrary — they are load-balancing decisions made on behalf of other tenants. Dedicated isolated infrastructure removes the shared-tenant problem, and with it, most of the restrictions.
— Core principle, WP Pro Host infrastructure analysis

Named Framework

The Developer Hosting Capability Model™

WP Pro Host Framework

Developer capability in managed WordPress hosting operates across three layers. The first is now commoditised. The layers that meaningfully affect developer workflow and build quality are the second and third.

1

Access Layer

Table stakes — most managed hosts now provide

Includes

  • SSH access (key-based)
  • SFTP file transfer
  • WP-CLI server-side
  • Basic cron job support

The baseline that every developer expects. SSH, SFTP, and WP-CLI are now standard across most managed WordPress providers — their absence is a disqualifier, but their presence is not a differentiator. The gap between providers emerges at the layers above.

2

Environment Control

Provided by fewer hosts — significant workflow impact

Includes

  • PHP versioning per site (8.1–8.3)
  • Configurable PHP limits per site
  • Staging with real server parity
  • Independent staging DNS

The layer where developer experience diverges significantly. Per-site PHP version control means different clients can run different PHP versions on the same account without a support ticket. Staging environments that run on identical infrastructure to production — same web server, same PHP version, same caching configuration — produce reliable test results.

3

Infrastructure Transparency

Provided by very few — determines genuine build quality

Includes

  • Published server specs (CPU, RAM, NVMe)
  • Defined PHP worker allocation per plan
  • Cache control API (QUIC.cloud / LSCWP)
  • Enhance CP API for site management
  • CI/CD deployment integration

The layer that separates a developer-grade managed host from a managed host that developers can tolerate. Published resource allocation means you can specify infrastructure in client proposals and SLAs. Cache control APIs mean deployment workflows can include cache purge steps. Enhance CP API enables programmatic site creation and management for multi-client operations.

On shared hosting, access restrictions protect other customers. On isolated dedicated infrastructure, those restrictions aren't necessary — so they don't exist.

The key mistake most developer hosting comparisons make

They compare feature checklists: SSH ✓, WP-CLI ✓, staging ✓.

The relevant comparison is the depth of each feature — and whether the restrictions that make those features "managed" are necessary, or just inherited from a shared environment.

Infrastructure Specification

The server stack — actual specifications

Most managed hosts describe infrastructure in marketing language. These are the actual specifications for WP Pro Host's production servers.

Server Specification

CPU AMD Ryzen 9 7950X3D — 16 cores / 32 threads, 4.2–5.7GHz boost
L3 Cache 128MB 3D V-Cache — reduces PHP memory latency measurably at scale
RAM 128GB ECC DDR5 — ECC corrects single-bit errors; no swap under normal load
Storage Dual NVMe Gen 5 in RAID 1 — ~14,000 MB/s sequential; random IOPS ~2M
Web server LiteSpeed Enterprise — LSAPI, native LSCache, HTTP/3, QUIC
PHP 8.3, 8.4, 8.5 — selectable per site via Enhance CP; OPcache enabled
Object cache Redis — infrastructure-level, not plugin-installed; configurable per site
Control panel Enhance CP v12 — container isolation, API access, per-site configuration
CDN QUIC.cloud — 30+ PoPs, LiteSpeed-native, WordPress-aware cache invalidation
Outbound mail Native Postfix — SMTP via mail.wp-pro-host.com:587; SPF/DKIM configured

PHP Worker Allocation by Plan

PHP workers determine how many concurrent uncached requests can be processed in parallel. Each additional concurrent uncached request beyond the worker count queues — producing the latency spikes visible under load testing.

Worker counts are fixed per plan. Additional workers can be added on Scale and Elite plans via the scaling policy.

Why this matters Worker count is the primary variable in concurrency behaviour. For WooCommerce, membership sites, or any application with significant uncached traffic, worker allocation is the specification to evaluate first.

Resource Allocation by Plan

Plan Sites PHP Workers RAM Storage Price
Launch 1 4 512MB 10GB £25/mo
Grow 3 8 1GB 25GB £45/mo
Scale 10 16 2GB 50GB £85/mo
Elite 30 32 4GB 100GB £175/mo

PHP Handler Reference

LiteSpeed LSAPI vs PHP-FPM: what actually changes

From a PHP application perspective, LSAPI and PHP-FPM are functionally identical — your code behaves the same way. The differences are at the process and caching layer, and they are operationally significant for WordPress at scale.

Aspect PHP-FPM LiteSpeed LSAPI
Memory per worker Higher — each FPM worker maintains its own process memory allocation regardless of idle state Lower — LSAPI shares memory more efficiently across the worker pool under mixed load
Worker restart on crash Managed by FPM pool configuration — restart delay depends on pm.emergency_restart settings Faster restart — LiteSpeed manages worker lifecycle directly without FPM pool manager overhead
Cached page handling Cached pages served via PHP (via plugin) or web server (if Nginx is configured as reverse proxy) Cached pages served directly by LiteSpeed web server — PHP worker is not invoked, database is not queried
HTTP/3 and QUIC Supported when Nginx or Apache is configured as proxy — requires additional configuration Native — HTTP/3 active by default; no additional configuration required
Code compatibility Standard PHP behaviour — all WordPress plugins and themes function as expected Identical PHP behaviour — code compatibility is complete; performance difference is at the process level only
.htaccess rewrite rules Supported on Apache + PHP-FPM; Nginx requires separate configuration syntax Fully supported — LiteSpeed is Apache .htaccess compatible; standard WordPress rewrite rules work unchanged

Code compatibility between PHP-FPM and LSAPI is complete. No plugin or theme modifications are needed when migrating to LiteSpeed. The performance difference is at the process management layer only.

LiteSpeed Cache request flow

Request arrives

Browser → LiteSpeed Enterprise (HTTP/3 or HTTP/2)

Cache check

LiteSpeed checks LSCache for a valid cached response

Cache hit (anonymous page)

Response served directly from web server — PHP worker not invoked, database not queried. TTFB: microseconds.

Cache miss (uncached / logged-in)

Request passed to LSAPI → PHP worker → WordPress → Database. Response cached for subsequent requests (if cacheable).

Deployment Reference

Standard deployment workflow with WP-CLI

A repeatable deployment sequence for WordPress on LiteSpeed managed hosting. Each step addresses a specific concern — database schema alignment, rewrite rules, cache coherency. Automate via GitHub Actions or a bash script on the server.

Deployment Step WP-CLI / SSH Command Notes
1. Put site in maintenance mode wp maintenance-mode activate Optional for minor updates; essential for database schema changes or major plugin updates
2. Deploy files via rsync rsync -avz --delete ./build/ user@server:/path/to/site/ Exclude wp-config.php and uploads directory; use --dry-run first to verify
3. Run database updates wp core update-db && wp plugin update --all Applies any pending database schema changes from core or plugin updates
4. Flush rewrites wp rewrite flush Required after adding custom post types or changing permalink structure
5. Purge LiteSpeed cache wp litespeed-purge all Ensures visitors immediately receive updated content; cached pages are stale after a deployment
6. Warm the cache wp litespeed-crawler start Optional — pre-warms the cache so first visitors do not trigger PHP execution on every page
7. Deactivate maintenance mode wp maintenance-mode deactivate Site is live; verify with a logged-out browser session to confirm cached pages are serving correctly

This sequence applies to theme/plugin deployments. Database schema changes require additional care — always back up before running wp core update-db on production.

GitHub Actions — production deployment

.github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy files via rsync
        uses: burnett01/rsync-deployments@6.0.0
        with:
          switches: -avz --delete --exclude='.env' --exclude='wp-config.php'
          path: ./
          remote_path: /var/www/your-site/public_html/
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Run post-deploy commands
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/your-site/public_html
            wp core update-db --allow-root
            wp rewrite flush --allow-root
            wp litespeed-purge all --allow-root

Store SSH_HOST, SSH_USER, and SSH_PRIVATE_KEY as GitHub repository secrets. The private key should correspond to an SSH key added to Enhance CP for your account.

Cache Control Reference

LiteSpeed cache control for developers

LiteSpeed Cache operates at the web server layer. Cache management via WP-CLI, .htaccess directives, and the QUIC.cloud API gives developers precise control over what is cached, what is excluded, and when the cache is invalidated.

WP-CLI cache management

Essential commands for deployment and maintenance workflows.

# Purge all cached pages
wp litespeed-purge all

# Purge a specific URL
wp litespeed-purge url https://yourdomain.com/page/

# Start the crawler (pre-warms cache after purge)
wp litespeed-crawler start

# Check crawler status
wp litespeed-crawler status

.htaccess cache exclusion rules

Exclude specific URLs, query strings, or user states from caching. Applies at the web server level — more reliable than plugin-based exclusions for dynamic endpoints.

# Exclude a specific path from cache
<IfModule LiteSpeed>
RewriteRule ^api/ - [E=Cache-Control:no-cache]
</IfModule>

# Exclude requests with specific query strings
<IfModule LiteSpeed>
RewriteCond %{QUERY_STRING} nocache=1
RewriteRule .* - [E=Cache-Control:no-cache]
</IfModule>

# Exclude specific cookies (logged-in users excluded by default)
<IfModule LiteSpeed>
RewriteCond %{HTTP_COOKIE} custom_session_cookie
RewriteRule .* - [E=Cache-Control:no-cache]
</IfModule>

QUIC.cloud CDN cache purge via API

Programmatic cache purge for CDN-layer cached assets. Useful for deployment pipelines that need to invalidate CDN cache independently of the origin server.

# Purge a specific URL from QUIC.cloud CDN
curl -X POST https://api.quic.cloud/v1/purge \
  -H "Content-Type: application/json" \
  -H "X-QC-Token: YOUR_API_TOKEN" \
  -d '{"urls": ["https://yourdomain.com/page/"]}'

# Purge all CDN-cached content for a domain
curl -X POST https://api.quic.cloud/v1/purge/all \
  -H "X-QC-Token: YOUR_API_TOKEN" \
  -d '{"domain": "yourdomain.com"}'

Developer Capability Comparison

Developer capability across hosting tiers

The table below maps capability availability across hosting tiers. The gap is largest at the infrastructure transparency layer — the capabilities that affect what you can commit to clients.

Developer Capability Score by Hosting Tier

Composite developer capability score (0–100) across the three layers of the Developer Hosting Capability Model™. Budget managed hosting covers Layer 1. Mid-tier adds Layer 2 partially. Dedicated managed hosting covers all three layers.

Directional illustration. Score reflects coverage across access, environment control, and infrastructure transparency layers.

Why this matters The capability gap between mid-tier and dedicated managed hosting is largest at the infrastructure transparency layer — which is also the layer that affects client-facing deliverables.

Capability Budget / Shared Managed Mid-tier Managed Dedicated Managed
SSH access
WP-CLI
SFTP
Per-site PHP version control Partial
Configurable PHP limits Partial
Staging with server parity
LiteSpeed Enterprise + LSAPI
Redis (infrastructure-level) Optional
Published worker allocation
Enhance CP API access
QUIC.cloud CDN API
Container isolation Partial
CI/CD deployment support Limited

— = not available. Partial = available with configuration or on higher sub-tiers. ✓ = available by default. Tiers are illustrative — specific providers vary.

API Reference

Enhance CP API for programmatic site management

The Enhance CP API enables programmatic management of WordPress sites, SSL certificates, and DNS records. Relevant for agencies managing multiple client deployments or automated site provisioning workflows.

Site provisioning

Create new WordPress installations, configure SSL, set PHP version, and configure domain routing via the API. Useful for agencies that provision client environments programmatically rather than through the control panel.

SSL certificate management

Request, renew, and manage Let's Encrypt certificates via API. Useful for automated certificate provisioning in multi-site workflows or when managing a large number of client domains.

Resource monitoring

Access PHP worker usage, bandwidth, and storage metrics via the API. Enables custom dashboards, automated alerts when resource usage approaches plan limits, and client-facing reporting tools.

User and permission management

Create collaborator accounts with scoped permissions — client access to staging review, developer access to specific sites, read-only access for monitoring. Role-based access without sharing full account credentials.

Full Enhance CP API documentation is available at apidocs.enhance.com. Authentication uses API keys generated from the control panel.

Questions about the infrastructure or a specific workflow?

We're happy to discuss WP-CLI scripts, CI/CD configuration, LiteSpeed cache rules, or any other technical integration before you commit to migrating.

Final Insight

Developer hosting is not just hosting with an SSH key. It's infrastructure you can reason about, build on, and commit to in client work.

You should be able to state the PHP worker count in a client proposal. You should be able to tell a client's IT team what PHP versions you support. You should be able to include a cache purge step in your deployment script without asking a support team.

These are table stakes for professional development work — but they require infrastructure transparency that most shared managed hosting deliberately withholds, because transparent resource allocation on a shared server would make the resource constraints obvious.

On isolated dedicated infrastructure, the transparency is straightforward because the resources are fixed. What's in the spec is what your sites have — not a share of a pool that contracts under load from neighbours.

The best managed hosting for developers is infrastructure that behaves predictably, exposes the right controls, and gets out of the way.

SSH, WP-CLI, PHP 8.3–8.5 per site, staging, Redis, LiteSpeed Enterprise

16 PHP workers on Scale, 32 on Elite. Published specs you can build on. From £25/mo — free migration included.