Membership sites collapse in a specific and predictable way.
Beta testing goes well. A few dozen members navigate the site without issue. The site feels fast. Everything seems ready.
Launch day arrives. Five hundred members receive the launch email and log in within the first hour. The site slows. Checkout times out. New sign-ups fail. The site goes down.
The cause is always the same. Every logged-in member bypasses page caching and generates a full PHP and database request. Five hundred simultaneous members equals five hundred simultaneous uncached PHP requests. The PHP worker pool exhausts. Requests queue. The site becomes unresponsive.
No amount of caching plugin configuration fixes this. The solution is PHP worker sizing, Redis object caching, and a host that lets you configure both before you need them.
What Running a Membership Site Actually Requires
Every page load for a logged-in member runs: a user authentication check, a membership status check, a content restriction check, and all standard WordPress queries. On a MemberPress or Restrict Content Pro installation, that is 50 to 80 database queries per page, none of which can be page-cached.
Redis object caching stores the results of these repeated queries. The second time the system checks whether a user has access to a course, it reads the answer from Redis in microseconds instead of querying MySQL again.
PHP workers sized for your concurrent member count prevent the queue that takes the site offline. The number to calculate: average PHP requests per second during a login surge multiplied by the average PHP execution time in seconds equals the minimum workers needed.
Reliable session storage keeps members logged in across requests. File-based PHP sessions are lost when a server restarts. Redis-backed sessions persist through maintenance events.
Quick Comparison
| Provider | Redis | PHP Workers Config | Session Storage | Payment Gateway Support | Best For |
|---|---|---|---|---|---|
| Kinsta | Built-in | Configurable | Redis-backed | Unrestricted | Managed large membership sites |
| Liquid Web | Available | Configurable | Configurable | Unrestricted | High-volume subscription business |
| Cloudways | Built-in | Configurable | Redis-backed | Unrestricted | Scalable membership infrastructure |
| WP Engine | Available | Standard | Standard | Unrestricted | Enterprise membership platforms |
| Pressable | Via plugin | Standard | Standard | Unrestricted | Mid-size membership communities |
| ScalaHosting | Available | Configurable | Configurable | Unrestricted | Value managed membership hosting |
Kinsta
Who it is for: Membership sites and subscription businesses that need high concurrent authenticated session handling with managed infrastructure and no server administration overhead.
Kinsta’s container-isolated architecture gives each site its own PHP-FPM pool. The pool worker count is configurable through the MyKinsta dashboard. For a membership site expecting 1,000 concurrent authenticated members, configuring the PHP worker count appropriately before launch prevents the queue exhaustion that brings down under-provisioned membership sites.
Redis object caching is built in and pre-configured for WordPress. The object cache handles WooCommerce Subscriptions, MemberPress, and Restrict Content Pro object lookups efficiently because these plugins follow standard WordPress caching conventions.
Kinsta’s automatic cache bypass for authenticated users and WooCommerce sessions means the staging-to-production promotion of the cache configuration is handled correctly without manual cache rule verification.
The 300-second PHP execution time default covers background jobs that membership platforms trigger: certificate generation, bulk email dispatch, recurring payment processing.
Liquid Web
Who it is for: Enterprise membership businesses, online communities with significant user counts, and subscription businesses where downtime during billing cycles has direct revenue consequences.
Liquid Web handles the subscription business model specifically. Their managed infrastructure includes the PHP-FPM pool tuning, MySQL buffer pool sizing, and Redis configuration that membership sites need without requiring you to understand and implement these settings yourself.
For subscription businesses with monthly billing cycles, the predictable traffic pattern creates known load peaks. Liquid Web’s managed team can configure the infrastructure for these patterns proactively rather than reactively.
Recurring payment gateway reliability depends on unrestricted outbound connections to Stripe, PayPal, Authorize.net, and other processors. Liquid Web does not restrict outbound HTTP traffic.
Cloudways
Who it is for: Membership site operators who need to scale infrastructure as their membership grows, with manageable cost at each growth stage.
Cloudways server resizing without migration is practically relevant for growing membership sites. Launch on a $22 per month server. At 1,000 members, resize to $50 per month. At 5,000 members, resize to $100 per month. Each resize happens without a site migration or DNS change.
The Cloudways managed database add-on separates MySQL onto its own server when the membership site outgrows the shared resources of a single-server configuration. This is the most cost-effective path to database isolation for growing membership sites.
Redis is included and pre-configured. The Redis cache handles object caching for MemberPress, LifterLMS, LearnDash, and similar plugins without additional configuration
WP Engine
Who it is for: Enterprise membership platforms and media companies with paid subscriber tiers who need an SLA-backed managed platform and enterprise support for their subscription infrastructure.
WP Engine’s enterprise plans include the dedicated resources and support response times that subscription businesses require when payment processing infrastructure is involved. Their platform handles the cache bypass logic for membership plugins automatically, with configurations tested against common membership and subscription plugins.
For membership sites with compliance requirements (handling financial data, healthcare memberships, or children’s content), WP Engine’s security certifications and compliance documentation are relevant considerations.
Pressable
Pressable covers mid-size membership sites that have not yet hit the PHP worker saturation that requires the premium managed tier.
The reliable managed infrastructure and clean staging environment for testing membership plugin updates makes it a practical choice for sites in the 100 to 500 concurrent member range.
ScalaHosting
Who it is for: Growing membership sites that need more than shared hosting provides but are not yet at the scale requiring the premium managed tier.
ScalaHosting managed VPS provides the server-level access to configure PHP-FPM pool sizes, Redis memory allocation, and MySQL settings specifically for membership site query patterns. NVMe storage handles the read-heavy user capability checking that runs on every authenticated page load.
For membership sites with predictable, moderate concurrent user counts (under 500 simultaneous members), ScalaHosting managed VPS at $30 to $60 per month provides appropriate resources without the premium of Kinsta or Liquid Web.
Membership Plugins and Their Hosting Impact
MemberPress and Restrict Content Pro follow standard WordPress caching conventions. Redis object caching works effectively with both.
WooCommerce Subscriptions adds ecommerce query patterns on top of membership authentication. Sites running WooCommerce Subscriptions share the database and PHP load patterns of large WooCommerce stores. The WooCommerce hosting guide covers the specific database considerations that apply to subscription-based stores.
Membership sites that include online courses or learning pathways have additional hosting requirements for course progress storage, quiz results, and certificate generation. Those requirements are covered in the online course platform hosting guide.
Frequently Asked Questions
How do I calculate the PHP workers I need for my member base?
During a typical logged-in session, a member generates approximately one PHP request every 10 to 30 seconds as they navigate. A member actively using a course or resource generates requests more frequently. As a rough starting point: (expected concurrent members) x (average PHP execution time in seconds) divided by the typical time between requests gives the minimum worker count. A 30-worker pool handles roughly 50 to 100 simultaneously active members on a typical MemberPress installation.
Why do membership sites often slow down specifically on launch day?
Beta testing spreads member activity over days and weeks. Launch day concentrates sign-ups and logins into hours. A launch email to 2,000 subscribers might drive 400 simultaneous logins within the first 30 minutes. The PHP worker pool, sized for beta patterns, exhausts immediately. The fix is pre-sizing workers for the launch event before the email goes out, not after the site slows.
Can Redis sessions fix members getting logged out after server maintenance?
Yes. File-based PHP sessions are stored on the web server disk. A server restart or PHP-FPM reload loses all active sessions. Members get logged out. Redis-backed sessions store the session data in Redis, which persists through PHP-FPM restarts. Configure session.save_handler = redis in php.ini to move sessions to Redis.
How do I prevent member sessions from expiring during the hosting maintenance window?
Use Redis or database-backed PHP session storage. File-based sessions are lost when a server restarts. Redis-backed sessions persist across server restarts because session data lives in Redis, not on the web server’s disk. Configure PHP with session.save_handler = redis and session.save_path = tcp://127.0.0.1:6379. Sessions survive maintenance without members needing to log in again.
