Introducing .htaccess Caching in MAx Cache: 20% faster Apache page loads. Mar 19, 2026 4:15:29 PM Director of CloudLinux OS department Hosting servers with Apache can now handle 18% more traffic with 20% faster response times, without any configuration changes. Today CloudLinux Inc. is announcing the beta release of .htaccess cache, a new feature in MAx Cache that compiles .htaccess files into memory, eliminating the per-request disk I/O that slows down every page load on a server. This new feature builds on the MAx Cache for Apache module CloudLinux Inc. released in December 2025 and the MAx Cache for Nginx module that followed in early 2026. If you already run MAx Cache for Apache, you get .htaccess caching with a single package update. No new packages, no new configuration. This release also adds CloudLinux 10 support across the entire MAx Cache stack: Apache module, Nginx module, and .htaccess caching... Why .htaccess Files Are a Performance Problem On hosting servers with Apache, .htaccess files are everywhere. WordPress uses them for permalinks. AccelerateWP uses them for caching rules. Security plugins, control panels, and custom configurations all add their own directives. The problem is that Apache re-reads and re-parses these files on every single request. It walks the directory tree from top to bottom, opening each .htaccess along the way. A single page load can trigger half a dozen disk reads before Apache even begins serving content. Multiply that by every visitor, every page, every site on the server, and the overhead adds up fast. How .htaccess Caching Works It compiles .htaccess files once and keeps the result in memory. On subsequent requests, Apache applies the cached rules directly. No disk reads, no re-parsing. The cache fills itself automatically as traffic arrives. There is no startup cost and nothing to pre-configure. The first request to any path compiles its .htaccess chain into memory, and every request after that skips the disk entirely. Instant Change Detection Caching is only useful if changes still take effect immediately. The new feature includes a lightweight watcher daemon (htcache-watchd) that monitors the filesystem for .htaccess changes in real time. When a WordPress admin updates permalink settings or a control panel modifies access rules, the watcher picks up the change and signals Apache to recompile, typically within milliseconds. On CloudLinux 9 and 10, the watcher detects all types of changes: edits, deletes, renames, and moves. On CloudLinux 7 and 8, the watcher detects edits in real time, while a periodic fallback check catches deletes and renames (default: 60 seconds). Performance Gains CloudLinux Inc. benchmarked .htaccess caching on a 3,000-vhost server with 100 concurrent users, which is representative of a production shared-hosting environment. All tests ran over HTTPS with Apache Worker MPM. With a realistic workload (page + all assets) When each page load includes CSS, JS, and images (~78 static asset requests per page), .htaccess caching adds on top of MAx Cache page caching: * +18% requests per second (19,660 | 23,172 RPS) * 20% faster average TTFB (25.7 | 20.5 ms), 20% faster at p95 * 22% less CPU per request (39,332 | 30,568 μs) The gain is large because .htaccess elimination speeds up every request, both cached pages and static assets alike. With ~78 asset requests per page, the savings multiply across the entire page load. What .htaccess Caching Costs ~19 MB shared memory for 300 active domains (~65 KB per domain). Memory scales with active sites, not total configured sites. Inactive domains consume nothing. What This Means for Hosting Providers * Higher hosting density: 18% more throughput and 22% less CPU per request means more sites on the same hardware. The cost: ~65 KB shared memory per active domain. * Faster page loads: 20% lower TTFB translates directly into better user experience, even for requests that still go through PHP. * Zero configuration: .htaccess caching is on by default. The watcher starts automatically. Most servers need no tuning at all. Better Together: MAx Cache Page Caching + .htaccess Caching The MAx Cache page caching and .htaccess caching engines tackle different bottlenecks, and they stack: * .htaccess caching eliminates the disk I/O cost of reading .htaccess files on every request. * MAx Cache page cache eliminates PHP execution for cached WordPress pages. On a server running both, a request for a cached page never touches the disk for .htaccess and never invokes PHP. The entire response is served from memory. OS Support .htaccess caching supports CloudLinux 7, 8, 9, and 10. This release also brings full CloudLinux 10 support to both MAx Cache for Apache and MAx Cache for Nginx. How to Get Started The feature ships inside the ea-apache24-mod_maxcache package. If you already have MAx Cache for Apache, just update the package, and .htaccess caching enables itself automatically. New Installation * To install packages, run the following commands: yum install libmaxcache maxcache-htcache-watchd -enablerepo=cloudlinux-updates-testing yum install ea-apache24-mod_maxcache -enablerepo=cl-ea4-testing That's it. After installation: * The module loads into Apache automatically. * The filesystem watcher starts monitoring for .htaccess changes. * .htaccess caching is enabled by default. No additional steps required. For advanced configuration options, see the documentation. Looking for Feedback CloudLinux Inc. is eager to hear how .htaccess caching performs in your hosting environment. As this is a beta release, your feedback helps CloudLinux Inc. refine the feature before general availability. Please share your experience through the CloudLinux Feature Portal. Follow its blog for updates on its progress and the latest releases.

CloudLinux is heading to CloudFest 2026! Mar 4, 2026 1:36:02 PM Thando Sikhosana is a Marketing Coordinator within the Hosting Marketing team at CloudLinux. CloudFest 2026 is just around the corner, and the CloudLinux team is excited to once again join the global hosting community for one of the industry's most anticipated events. From 24 - 26 March 2026, CloudLinux will be attending CloudFest at Europa Park in Rust, Germany, connecting with hosting providers, infrastructure operators, and technology partners from across the world. If you are attending CloudFest this year, CloudLinux Inc. invite you to visit the CloudLinux team at Booth F02 to meet the team and learn what's next for CloudLinux OS and Imunify360. A Spotlight Session from CloudLinux CEO Igor Seletskiy One of the highlights for CloudLinux this year will be a main stage spotlight session presented by its CEO, Igor Seletskiy. Session Title More Revenue, Same Servers: What's Next from CloudLinux & Imunify Date and Time 24 March 2026 15:10 to 15:30 CET As hosting providers continue to navigate rising costs, competitive pricing pressures, and evolving customer expectations, unlocking more value from existing infrastructure has become increasingly important. In this 20 minute main stage session, Igor will share CloudLinux's perspective on how hosting providers can increase revenue potential while maintaining the stability and security their customers expect. The session will highlight the broader direction of the CloudLinux ecosystem, including developments across CloudLinux OS and Imunify, and how hosting companies can continue building sustainable, profitable platforms in a rapidly evolving hosting landscape. Attendees will also get a glimpse into what lies ahead for CloudLinux and how the company continues to support hosting providers as their infrastructure, security, and monetization strategies evolve. CloudLinux in the Modern Security Stack Tour CloudLinux will also participate in the Modern Security Stack Tour on Tuesday, 24 March. This guided tour brings together ecosystem partners covering different layers of the modern security stack, helping attendees understand how real world defence is built and integrated across cloud and hosted environments. During the tour, attendees will visit the CloudLinux booth to learn how CloudLinux OS and Imunify360 help hosting providers strengthen platform security while maintaining performance and stability. CloudLinux Tour Stop 24 March 15:03 to 15:08 The tour is designed for security leaders, infrastructure architects, and platform operators responsible for building layered and integrated defence across cloud and hosted environments. Meet the CloudLinux Team at Booth F02 Throughout the event, the CloudLinux team will be available at Booth F02 to discuss how its platform helps hosting providers deliver secure, stable, and profitable hosting environments. Whether you are looking to improve server stability, strengthen security, or unlock new monetization opportunities within your hosting stack, CloudLinux Inc. would be happy to connect and explore how CloudLinux can support your goals. Let's Connect at CloudFest If you are attending CloudFest 2026, stop by Booth F02 to meet the team and learn more about what's coming next for CloudLinux and Imunify. You can also reach out to schedule time with its sales team ahead of the event. | [email protected] CloudLinux Inc. look forward to seeing you in Rust!

MAx Cache now available for Nginx: server-level WordPress caching, completely bypassing PHP. Feb 17, 2026 2:27:55 PM Director of CloudLinux OS department In December 2025, CloudLinux Inc. released MAx Cache for Apache, a native module that serves cached WordPress pages directly from the web server without invoking PHP. Today, CloudLinux Inc. is bringing that same capability to Nginx with a purpose-built module that delivers even greater performance gains than the Apache version. MAx Cache for Nginx works alongside AccelerateWP: hosting providers deploy it at the server level, and site owners enable it through the AccelerateWP plugin in WordPress. The PHP Performance Bottleneck Running PHP is expensive. Traditional WordPress caching solutions still require PHP to handle routing decisions, process headers, and determine which cached page to serve, even when the content is already static. That overhead adds up, especially under high traffic. MAx Cache moves all of that logic out of PHP and into the web server itself. Routing decisions and cache-key computation happen in C, so PHP runs only on cache misses. CloudLinux Inc. first delivered this for Apache. Now, the Nginx implementation takes it further by leveraging Nginx's event-driven architecture and a shared-memory configuration approach that eliminates file I/O entirely on the request path. Performance Gains In its internal benchmarks, MAx Cache for Nginx delivers: * ~3x increase in requests per second (RPS) * ~6x improvement in Time to First Byte (TTFB) * ~5x reduction in CPU, memory, and load for PHP page serving These gains exceed what CloudLinux Inc. measured with the Apache module (~2x RPS, ~2x TTFB). The difference reflects the combined effect of Nginx's efficient event-driven architecture and MAx Cache's shared-memory configuration, which avoids disk I/O on every request. CloudLinux Inc. expect these gains to be even more pronounced under high concurrency. What This Means for Hosting Providers MAx Cache for Nginx is included with all CloudLinux licenses at no additional cost. For hosting providers running Nginx, the benefits are twofold. On the server side, lower CPU and memory consumption means higher hosting density. On the customer side, faster page loads and improved TTFB translate to a better experience for the people visiting your customers' sites. Faster sites mean happier end customers, lower churn, and fewer performance-related support tickets. Combined with AccelerateWP, MAx Cache delivers WordPress performance that plugin-only caching solutions cannot match. Plugins still route every request through PHP, even cached ones. MAx Cache bypasses PHP entirely for cached pages. That is a server-level optimization no WordPress plugin can replicate. How It Works Nginx is a fundamentally different web server from Apache. It doesn't read .htaccess files, doesn't support per-directory configuration overrides, and uses a different request processing model. Porting the Apache module directly wouldn't work. Instead, MAx Cache for Nginx shares the same core caching logic but uses a purpose-built configuration and request-handling architecture designed for Nginx. Shared Core Library Both the Apache and Nginx modules use libmaxcache, a shared C library that handles: * Device detection (mobile, tablet, desktop) * WebP support detection * WordPress user authentication state * Dynamic cookie suffix computation * Query string normalization with allowed/ignored parameters This shared library ensures that both modules produce bit-for-bit identical cache paths, so the same cached pages work regardless of which web server is in front. Dynamic Configuration via Shared Memory Nginx doesn't read .htaccess files or support per-directory configuration overrides, so MAx Cache for Nginx introduces maxcache-configd, a lightweight configuration daemon that bridges the gap: * When a WordPress administrator enables or configures MAx Cache through AccelerateWP, the plugin writes its configuration to .htaccess (as it does for Apache) and sends a notification to the daemon via a Unix socket. * maxcache-configd parses the .htaccess directives and writes the parsed configuration into shared memory (/dev/shm/maxcache_config). * The Nginx module reads configuration directly from shared memory with zero file I/O. This means configuration updates take effect immediately without requiring an Nginx restart or reload. When a site owner toggles MAx Cache in their WordPress dashboard, the change is live within milliseconds. Technical Highlights * Server-level routing in C: All cache-key computation and routing decisions happen in a native Nginx module, not in PHP. * No PHP execution on cache hits: Nginx serves cached pages directly. PHP-FPM is never invoked for cached requests. * Zero file I/O on the request path: Configuration is read from shared memory, not from disk. Cache files are served via Nginx's optimized static file handling. * Automatic configuration updates: Changes propagate through shared memory with no Nginx restarts or reloads required. * Full cache-key support: Device detection, WebP variants, gzip pre-compressed files, SSL/HTTPS variants, logged-in user cache separation, dynamic cookies, and normalized query strings. * Subrequest-aware: The module correctly bypasses the cache for internal subrequests such as auth_request and SSI includes. * AccelerateWP compatibility: Works with the same AccelerateWP plugin interface that hosting providers and site owners already use. How to Get Started This first release of MAx Cache for Nginx is available as a beta for early adopters who want to test it in real hosting environments. It currently supports cPanel on CloudLinux 7/8/9 Shared Pro, Admin, and Solo editions using ea-nginx in reverse proxy mode or standalone mode. In order for MAx Cache to function on a website, it needs to be deployed at the server level, and also activated in AccelerateWP by the WordPress administrator at the website level. Installation steps for hosting providers * To install packages, run the following commands: yum install accelerate-wp cloudlinux-site-optimization-module libmaxcache libmaxcache-configd -enablerepo=cloudlinux-updates-testing yum install ea-nginx-maxcache -enablerepo=cl-ea4-testing The maxcache-configd daemon will start automatically after installation and begin managing configurations for all enabled domains. * Enable MAx Cache for all available domains: cloudlinux-awp-admin maxcache -enable -all MAx Cache default state in AccelerateWP: 1. On websites where AccelerateWP is already present when MAx Cache is deployed on the server, MAx Cache is turned off by default at the website level. 2. On websites where AccelerateWP is installed after MAx Cache is deployed on the server, MAx Cache is turned on by default at the website level. Activation steps for website owners Once MAx Cache is successfully installed on the server, website owners can activate it for their websites with the following steps: * Update the AccelerateWP plugin to the latest version: * Log in to WordPress Admin Dashboard. * Navigate to Plugins > Installed Plugins. * Find AccelerateWP in the list of plugins and if there is a newer version available, click on "update now." * Wait until the update is completed. * To turn on MAx Cache: * In the WordPress Admin Dashboard, navigate to AccelerateWP > Settings > Add-Ons. * Click on the toggle next to the MAx Cache feature to activate it. CloudLinux Inc. recommend enabling auto-updates for AccelerateWP to ensure all improvements and fixes are applied immediately. Here are the steps for WordPress admins: 1. In the WordPress Admin Dashboard, navigate to Plugins > Installed Plugins. 2. Find the AccelerateWP plugin in the list and click the "Enable auto-updates" link on the right. (The link will change to "Disable auto-updates," indicating it is now active.) Looking for Feedback CloudLinux Inc. is eager to hear how MAx Cache performs in your hosting environment. As this is a beta release, your feedback is invaluable in helping CloudLinux Inc. refine the module before general availability. Please use the CloudLinux Feature Portal to provide any feedback or ideas. Follow its blog for updates on its progress and the latest releases.