Your application runs using a predefined setup. In some situations, you may want to switch to a different setup; for example, to match your website’s needs or preferences.
Cloudways allows you to change the setup for a single application or update multiple applications at the same time.
This includes bulk switching from the Hybrid stack (a mixed setup) to the Lightning stack (a faster, streamlined setup).
This guide explains how to change your application’s setup, how bulk changes work, and what to check before making the switch.
Table of Contents:
What is Webstack?
A web stack is the basic setup your application uses to run. It includes the main parts that help your website work properly, such as:
The system your server runs on
The language your website uses
The place where your data is stored
The service that shows your website to visitors
Together, these parts ensure your website loads, stores information, and functions as expected.
Type of Webstacks
Cloudways currently offers two stacks for your web hosting needs.
Hybrid Stack (Nginx plus Apache2)
Lightning Stack (Nginx Only)
Each stack has its own advantages and limitations. You can choose the stack that suits your website best.
Hybrid Stack
The Hybrid Stack is a setup where multiple services work together to run your website.
In this setup:
One service handles and delivers your website content
Another service helps speed things up by storing copies of pages
A supporting service manages certain website rules and behaviors
This stack is useful if your website depends on special rule files (commonly used by older websites, some plugins, or custom configurations).
Choose the Hybrid Stack if:
Your website uses special rule settings
You rely on features that require those rules
You are unsure and want broader compatibility
Lightning Stack
The Lightning Stack is a simpler and faster setup.
In this setup:
A single main service delivers your website content
A speed-boosting service stores copies of pages for quicker loading
Because fewer services are involved, websites often load faster. This stack works best for websites that do not depend on special rule files.
Choose the Lightning Stack if:
Your website is built using modern standards
You do not use special rule settings
You want better speed and performance
How to Update the Stack for One Application
By default, new applications are created using the Hybrid Stack. If you want to change the setup for a single application, or update multiple applications at the same time, you can switch between the Hybrid Stack and the Lightning Stack by following the steps below.
Step #1 — Navigate to Your Application:
Log in to your Cloudways Platform using your credentials.
From the side bar menu, click on Flexible Icon as shown below and click My Servers.
4. Next, choose the server where your desired application is deployed.
Click the globe icon.
Next, choose your application from the list of all desired applications you have added.
Step #2 — Navigate to Stack Settings:
Under Application Management, select Application Settings
Select Stack setting tab. Here, you'll find the status indicating whether your application is currently configured to the Hybrid Stack or the Lightning Stack (default is Hybrid Stack)
Select Lightning Stack
Click on "Update Now"
5. You will be prompted here about switching stacks. Click "Proceed" to confirm.
How to Change the Stack for Multiple Applications (Bulk Change)
Follow these steps to switch several applications to the Lightning Stack at the same time.
Step #1 — Click “Switch to Lightning Stack”:
Log in to your Cloudways Platform using your credentials.
From the Cloudways main screen, click the “Switch to Lightning Stack” button.
This opens the stack change window.
Step #2 — Select Your Server:
Choose the server that contains your applications. (A server is where your websites/applications run.)
Click the arrow (➝) next to the server name to continue to open the drop down.
Step #3 — Select Applications & Confirm
Tick (✔) the applications you want to update.
Click “Switch To Lightning Stack.”
Cloudways will now apply the changes to all selected applications.
Benchmarks
Configuration:
WordPress App with k6 loadouts.
Varnish Disabled.
Redis - Object Caching Disabled.
Caching Plugins removed.
Test Instances:
DigitalOcean | Basic Series - 4vCPU 8GB (Premium)
Methodology:
To compare performance, we ran a controlled test that mimics how real visitors use a website.
During the test:
Virtual visitors were gradually added over time
Each visitor opened the homepage
They moved to the login page
Logged in
Then browsed different pages and posts
The test measured how the website responded when pages were loaded without using stored copies (meaning every visit requested fresh data from the server).
Test Details
Total duration: 30 minutes
Visitor increase: Started with 1 visitor
Peak load: Reached 1000 visitors over 20 minutes
Sustained load: Peak traffic continued for 10 minutes
Each page visit also loaded supporting files such as images and design elements, similar to how a normal web browser behaves.
The key metrics are:
Total Requests - Number of requests k6 made
Total Errors - Number of error requests
p95 - The 95th percentile response time
Page Cum Avg - Cumulative average response time for Pages (html)
Asset Cum Avg - Cumulative average response time for Assets (css, js, images)
Login Cum Avg - Cumulative average response time for Login (wp-profile.php)
WP-Login Avg Response Time - Average response time for login (301 redirect, which validates credentials)
Stack Type | Total Requests | Total Errors | P95 (ms) | WP-Login Avg Response Time | Page Avg (ms) | Asset Avg (ms) | Login Avg (ms) |
Hybrid | 255190 | 3 | 5734 | 3000 | 3600 | 549 | 3238 |
Lightning | 394437 | 6 | 4620 | 2000 | 2703 | 487 | 2477 |
With the benchmarks, we can see that the lightning stack, compared to the hybrid stack, had
54% more requests served.
19% faster response times.
33% faster WP Login response times.
25% faster page response times.
11% faster average asset response times.
24% faster average login response times.
Stack Performance Testing
To objectively measure the improvements of the new Lightning stack, we have compiled the following comprehensive test cases and step-by-step guidelines:
Note:
These test examples are provided only as a reference. You may use any testing approach that suits your needs.
For a fair comparison:
Run your test before changing the stack
Change the stack
Then run the same test again
This helps you clearly see the difference.
For more reliable results:
Test when only one application is running on the server
Results may differ if:
Other applications are hosted on the same server
Your website is receiving live visitors
Your site uses different themes, plugins, or custom code
Server resources change during testing
Because every website is different, performance results can vary.
Test Case 1: WordPress Admin (Dashboard) Speed Test
Check backend responsiveness and WordPress admin performance.
Log in to your WordPress admin dashboard of your application.
Navigate to:
Dashboard > Home
Posts > All Posts
Pages > All Pages
WooCommerce > Orders (if applicable)
Use your browser’s DevTools (Network tab) to monitor load times and Time to First Byte (TTFB).
Repeat the above steps after switching to the new stack.
Alternative (Plugin-Based Approach):
Install and activate the Query Monitor plugin.
Check:
Page generation time
Number of database queries
Slow or heavy plugins
Compare these metrics before and after switching to the new stack.
Test 2: Reload + CPU Monitoring
Evaluate basic site load times and CPU usage.
Open your application in an incognito browser window.
Open browser DevTools and navigate to the Network tab. Disable caching.
Reload the website 3–5 times, noting load times.
Monitor CPU usage via Cloudways Monitoring: Navigate to Monitoring > Server > CPU tab.
Compare load times and CPU usage on the old stack versus the new stack.
Test 3: ApacheBench (Quick Load Test)
Quick load testing checks server response under simultaneous requests. You can also perform this test via loader.io.
Note that for accurate results, all forms of caching, such as Varnish, Breeze, and Object Cache Pro, should be disabled. Additionally, you should whitelist the IP address from which you will be conducting this test.
Connect to your server via SSH.
Execute the following command: ab -n 50 -c 10 https://yourdomain.com/
Observe and record:
Average response time, request throughput
CPU usage behavior during the test
Repeat the test after migrating to the new stack and compare the results.
FAQs
Q) Should I switch my application over?
We recommend testing first on a clone/stage application and checking compatibility before transitioning the production application. Unless your site has custom rewrite or redirect rules (301 & 302 redirects) added via .htaccess, switching should not cause any compatibility issues.
Q) Is there any cost associated with this?
The new stack is a free improvement, part of our commitment to providing a managed hosting experience that is performant across multiple use cases.
Q) Will switching stacks result in any downtime?
Switching stacks takes a minute and does not result in downtime, as this configuration occurs at the application level.
Q) Which applications are supported?
WordPress, Magento, Laravel, and other PHP applications that don't require htaccess are supported.
Q) Will app settings or configurations be lost?
No, all settings are preserved during the switch to new lighting stack and vice versa.
Q) Can users revert the application stack to hybrid stack?
Yes, you can switch back via application settings -> stack settings.
Q) Are logs and monitoring impacted?
There is no impact on monitoring or logs.
Q) Can apps on the same server use different stacks?
Yes, stack settings are per application; different applications on the same server can utilize a stack better suited to its needs.
Q) Will performance improve automatically?
Results vary based on use case. Users are encouraged to test using real-world scenarios. However, initial private-preview testers have revealed significant performance improvements.
Q) Will team members have access to this?
Generally yes. This is an application-level setting. Hence, any team members having access to applications or servers will have access to this setting for that specific application or server.
Q) If I create a staging application, change its stack, and then push the changes, will this alter the stack for the live application?
No. Pushing changes from staging only applies to application changes such as files and databases; it will not push this change to the live application.
That’s it! We hope this article was helpful.
Need Help?
If you need assistance, feel free to:
Visit the Cloudways Support Center
Chat with us: Need a Hand > Send us a Message
Or create a support ticket anytime.
We're here 24/7 to help you!