In a high-density web hosting environment, the modern developer’s toolkit—Node.js, NPM, Composer, and Redis—is no longer an optional “extra” but a baseline requirement for deploying performant PHP and JavaScript applications. However, on a cPanel infrastructure hardened with CloudLinux and Virtual Environments (LVE), providing these tools globally presents a unique challenge: balancing developer flexibility with the strict isolation of CageFS.

This article outlines the professional approach to orchestrating a global development stack. We will move beyond basic installations to focus on the systematic configuration of symlinks, the mapping of CageFS paths, and the critical security layers required to prevent “noisy neighbor” syndrome in a multi-tenant ecosystem.

Core Components of the Stack

  • Node.js & NPM: Providing both EA-Nodejs (cPanel native) and Alt-Nodejs (CloudLinux Selector) versions to cater to different application requirements.
  • Composer: The industry standard for PHP dependency management, optimized for global execution.
  • Redis: Leveraging a persistent, in-memory data structure store to drastically reduce database load and improve application response times.
  • CageFS Integration: Ensuring that while these tools are “global,” they remain securely encapsulated within each user’s private environment.

Why Global Access Matters

Without global configuration, users are often forced into manual path exports or local installations that consume unnecessary disk space and create support overhead. By centralizing these binaries, you ensure:

  • Standardization: Every user operates on the same vetted versions.
  • Simplicity: Commands like node -v or composer install “just work” out of the box.
  • Performance: Proper CageFS mapping ensures no latency penalty when entering the virtualized environment.
Continue reading

I had recently to assist a customer who had a website built using the Hostinger Website Builder (a WYSIWYG platform, besides their WordPress plans). This builder generates static HTML/JS/CSS pages, potentially with some dynamic features like forms.

To assist the customer with their transition to a different technology, we provided them with a static version of their website as a temporary solution until their new platform was fully developed. During this process, I explored various methods, including:

  • Brute archiving downloads: This involved using tools like wget and HTTrack, as well as other software or browser-based solutions.
  • Hostinger’s WordPress export option: Located within the builder under “settings > export to a WordPress site” this feature was also tested. However, it was determined that the theme elements and formatting would require significant rework, making it impractical for a temporary page.

After evaluating different options and considering the underlying web technologies used by the builder, I ultimately found SingleFile to be the most efficient solution.

https://github.com/gildas-lormeau/SingleFile

SingleFile is available as both a web extension and a CLI tool. It proved to be highly effective, requiring only minor adjustments to the URLs.

Picking the perfect web server is like choosing the right car for a road trip—it’s not just about speed, but also how well it fits your journey. Whether you’re a WordPress enthusiast, a DevOps pro managing Kubernetes, or a beginner launching a blog, there’s a web server for you. Apache and Nginx are the old reliables, but LiteSpeed, OpenLiteSpeed, Caddy, and Traefik are shaking things up with modern features. Let’s dive into the pros, cons, and best use cases for each to help you decide.
Continue reading

After experiencing an international peering issue that affected some websites for a few hours, we deployed a new experimental service for web hosting named AlwaysUp. This free and optional service can be activated by the customers to ensure their websites will always be accessible. It’s particularly useful for websites that require high read-only availability, such as blogs, magazines, and newspapers. These sites may not be ready to invest in an expensive infrastructure/architecture or in an full-cache CDN, but they can tolerate not being able to edit their content in the event of a failure.


When the service is up, the requests are handled with RR DNS to either the master or the failover, which are geographically distant from each other. The failover proxies the requests to the master and caches them if they don’t include cookies. In case of a failure in reaching the service, the DNS will direct the requests to the failover, which has already cached most of the active pages.

شاركنا قبل أسبوعين في برمجان التطبيقات القرآنية، كوننا نعمل على مشاريع في هذا المجال، وهو تحدٍ استمر لنحو يومين وكان يجب فيها العمل على فكرة محددة تخدم مساقات معينة هي التلعيب والذكاء الاصطناعي وإنترنت الأشياء والواقع الممتد. وينبغي تطوير نموذج تجريبي لها.

Continue reading