Over the years, I have tried different ways of hosting, building and optimizing WordPress websites. My current setup combines WordPress and Divi with a lightweight server stack and several performance and security tools.
In this post, I want to share the WordPress stack I currently use in 2026 and why I chose each part of it.
This isn’t necessarily the best stack for every WordPress website. It’s simply the setup that currently works well for my websites and the type of work I do.
AWS Lightsail
I currently host my WordPress websites on AWS Lightsail.
I like Lightsail because it gives me more control over the server than traditional shared hosting while keeping the setup relatively straightforward.
Instead of using a traditional shared hosting control panel, I run my own Ubuntu server and manage the WordPress hosting environment myself.
OpenLiteSpeed + OLSPanel
For the web server, I use OpenLiteSpeed.
I manage OpenLiteSpeed through OLSPanel, which gives me a web-based interface for managing websites and other parts of the hosting environment.
This combination gives me the benefits of OpenLiteSpeed without requiring me to manage everything manually from the command line.
I still use SSH when I need to work directly with the server.
WordPress + Divi 5
WordPress is my primary CMS, and Divi is my main website builder.
I have worked with Divi for several years, and I am now working with Divi 5 on my websites.
I mainly use Divi for building and implementing websites rather than developing custom WordPress themes or plugins.
LiteSpeed Cache
Because the server runs OpenLiteSpeed, I use LiteSpeed Cache as my primary WordPress performance plugin.
I use it for page caching and several frontend optimization features.
One advantage of this setup is that LiteSpeed Cache can work directly with the LiteSpeed server rather than relying only on PHP-based page caching.
I also use QUIC.cloud for features such as Critical CSS when required.
Redis Object Cache
Redis is also running on my server.
I use Redis as a persistent object cache for WordPress. This can reduce repeated database work by keeping frequently requested objects in memory.
Redis isn’t a replacement for page caching, so I use it alongside LiteSpeed Cache.
Cloudflare
Cloudflare sits in front of my websites.
I use it for DNS, CDN and caching, as well as security features.
Combining Cloudflare with LiteSpeed Cache requires some care because there are multiple caching layers involved. I have spent quite a bit of time testing cache rules, exclusions and cache behaviour to make sure logged-in WordPress users and administrative pages aren’t cached incorrectly.
Tailscale
Tailscale is one of the more recent additions to my server setup.
I use it to create private connectivity to my server for administration. This allows me to access services privately rather than exposing every administrative service directly to the public internet.
It has become a useful addition to my WordPress hosting and server-management workflow.
Security
I don’t rely on a single WordPress security plugin for everything.
My setup uses security at different layers, including Cloudflare, SSL, WordPress authentication protection and private server access through Tailscale.
Depending on the website, I have also worked with two-factor authentication and Cloudflare Turnstile.
Performance Testing
Installing a cache plugin doesn’t automatically mean a website is fast.
I test my websites using tools such as Google PageSpeed Insights, Lighthouse and DebugBear.
Working with Divi has taught me that performance optimization often involves looking beyond the cache plugin. Images, fonts, CSS, JavaScript, third-party services, the server and CDN configuration can all affect the final result.
My Current Stack
So, my current WordPress stack looks roughly like this:
Infrastructure: AWS Lightsail + Ubuntu
Server: OpenLiteSpeed + OLSPanel
CMS: WordPress
Builder: Divi 5
Caching/Optimization: LiteSpeed Cache + QUIC.cloud
Object Cache: Redis
CDN/DNS/Security: Cloudflare
Private Server Access: Tailscale
Performance Testing: PageSpeed Insights + Lighthouse + DebugBear
This stack gives me a balance between the visual WordPress workflow I prefer and the server-level control I have gradually learned to manage.
What I’ve Learned
One of the biggest things I’ve learned is that WordPress performance isn’t about finding one “best” plugin.
The website builder, hosting environment, web server, caching, database, CDN, fonts, images and third-party scripts all interact with each other.
I’m still experimenting with and improving this setup as WordPress, Divi 5 and the tools around them continue to evolve.
This is my current stack in 2026, and I’m looking forward to sharing more of what I learn about WordPress, Divi and web performance here on DEV.