Over the years, I’ve tried different ways of hosting, building, and optimizing WordPress websites.

My current setup combines WordPress and Divi 5 with a lightweight server stack built around Amazon Lightsail, OpenLiteSpeed, LiteSpeed Cache, Redis, Cloudflare, and Tailscale.

In this post, I want to share my WordPress Stack 2026, why I chose each part of it, and some of the things I’ve learned while working with 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.

Amazon Lightsail

My WordPress sites are presently hosted on Amazon Lightsail.

I like Lightsail because it gives me more control over the server than traditional shared hosting and keeps the infrastructure pretty true.

I bypassed the usual shared hosting control panels entirely. I’m currently running my WordPress sites directly out of a self-managed Ubuntu server.

I’ve also had the opportunity to learn more about WordPress’s server side rather than only using the interface.

OpenLiteSpeed and OLSPanel

OpenLiteSpeed handles the web server duties since I wanted it to be as fast as possible.

I manage OpenLiteSpeed through OLSPanel, which offers an online interface for managing websites and different parts of my hosting environment. However, I had to install Redis and its PHP modules manually via SSH as they are not part of the OLSPanel installation by default.

This combination gives me the benefits of OpenLiteSpeed without having to manually control the whole thing through the command line.

I still use SSH when I really need to work directly with the server.

WordPress and Divi 5

WordPress is my main CMS, and Divi is my main website builder.

I’ve been building with Divi for years, and lately I have been transitioning my site and my client’s sites over to Divi 5.

My focus is primarily on building and implementing websites visually with Divi, instead of developing custom WordPress themes or plugins.

While WordPress has the freedom to integrate cache, analytics, security, CDN, and other tools around it, Divi gives me the visual flow I want.

LiteSpeed Cache

Because my server runs OpenLiteSpeed, I use LiteSpeed Cache as my WordPress performance plugin.

I use it for various frontend optimization features and for page caching.

One of the most significant benefits is that LiteSpeed Cache is native to the LiteSpeed server, which eliminates the need to employ less efficient PHP opcode caching or page caching methods.

I also use QUIC.cloud for optimization features such as Critical CSS when required.

However, I’ve discovered that enabling every optimization option is not the best thing. Different websites can behave differently, so I opt for testing changes instead of simply turning everything on.

Redis Object Cache

I also run Redis on my server.

For WordPress, I use Redis as a persistent object cache. It can reduce database work by storing frequently requested objects in memory.

I use Redis alongside LiteSpeed Cache because it cannot replace full-page caching.

These cache layers have different purposes in my setup:

• LiteSpeed Cache handles page caching and frontend optimization.
• Redis provides persistent WordPress object caching.
• Cloudflare can cache and deliver content at the edge.

Understanding what each caching layer does has been necessary to configure the stack correctly.

Cloudflare

Cloudflare is in front of my websites.

I use it for DNS, CDN, caching, SSL configuration, and security features.

Because several cache levels are involved, combining Cloudflare and LiteSpeed Cache requires caution.

I spent a lot of time testing cache rules, exclusions, and cache behaviour to ensure logged-in WordPress users and administrative pages are not cached incorrectly.

Cloudflare has become a necessary part of both my WordPress performance and security setup.

Tailscale

One of the more recent additions to my server configuration is Tailscale.

I use it to create private connectivity between my devices and the server for administration.

Tailscale lets me access supported server services over a private network, instead of directly exposing each administration service to the public internet.

It’s been a useful addition to my WordPress hosting and server-management routine, especially since I’ve started managing more of the server environment myself.

Security at Multiple Layers

I do not rely on a single WordPress security plugin for everything.

Instead, I like to think about security at multiple layers.

My setup includes a combination of:

• Cloudflare
• SSL/HTTPS
• WordPress authentication protection
• Private server access through Tailscale
• Two-factor authentication using Duo MFA (for Single WordPress site only) where appropriate
• Cloudflare Turnstile where appropriate

This means security isn’t restricted to what happens within WordPress itself. The server, network access, CDN, and WordPress authentication layers are all involved.

Performance Testing

Adding a caching plugin to your WordPress is not a complete solution to speed up your site or optimize the performance of your website. You usually need more steps and different methods to improve things.

When it comes to testing the performance of my sites, I have some pretty useful tools such as Google PageSpeed Insights, Lighthouse, Debug Bear, and Flying TTFB (for TTFB).

My experience with Divi has revealed that optimizing WordPress performance frequently requires examining factors that go beyond the cache plugin.

The outcome of websites can be affected by numerous things. For example, such features as images, fonts, CSS, JavaScript, third-party services, website builders, server setups, and CDN — all can influence the result. And they all are necessary for building the website.

Whenever you improve something, it has the potential to introduce a negative change to something else. This is why testing is such a crucial part of making any change, before and after the change has been made.

My WordPress Stack in 2026

Here’s what my current stack looks like:

• Infrastructure: Amazon Lightsail
• Operating System: Ubuntu
• Web Server: OpenLiteSpeed
• Server Management: OLSPanel
• CMS: WordPress
• Website Builder: Divi 5
• Caching & Optimization: LiteSpeed Cache
• Additional Optimization: QUIC.cloud
• Object Cache: Redis
• CDN, DNS & Security: Cloudflare
• Private Server Access: Tailscale
• For Testing the Performance: PageSpeed Insights, Lighthouse, DebugBear, and Flying TTFB (for TTFB)

This setup lets me combine the visual WordPress workflow I like with the server-level control I’ve slowly picked up.

What I’ve Learned

The biggest lesson I’ve learned is that WordPress performance isn’t about finding the best plugin.

The website builder, hosting environment, web server, caching system, database, CDN, fonts, images, and third-party scripts all interact mutually.

I’ve also learned that performance optimization involves a lot of testing.

A configuration that works perfectly for one WordPress website might not produce the same results exactly on another.