Most WordPress hosts run Apache + mod_php or nginx + php-fpm. The RoamerHost WordPress image is roamerhost/wordpress-ols — OLS stands for OpenLiteSpeed, paired with lsphp 8.2.
The 30-second version
| Question | Answer |
|---|---|
| Why not Apache | It handles more concurrency on the same resources |
| What it means for you | Less likely to choke at peak traffic |
| Do you have to configure it | No, the environment is already tuned |
| Any compatibility issues | The vast majority of plugins and themes work fine |
| What to watch for | .htaccess rules brought over from Apache need verifying |
What OpenLiteSpeed actually changes
OpenLiteSpeed is the open-source edition of LiteSpeed Web Server, built on an event-driven architecture. For a WordPress site, there are three differences that matter directly:
- Event-driven rather than process-per-request: Apache’s prefork mode gives every connection its own process, which eats memory. OpenLiteSpeed handles connections in an event loop, so the same memory supports far more simultaneous connections. Inside a container with a fixed resource ceiling, you really feel that difference.
- Native .htaccess compatibility: this is the biggest difference from nginx. Plenty of plugins in the WordPress ecosystem write to
.htaccess(caching plugins, security plugins, hotlink protection), and nginx ignores it entirely while OpenLiteSpeed supports it directly. When you migrate in, you do not have to rewrite your rewrite rules. - lsphp instead of php-fpm: LiteSpeed’s own PHP SAPI talks to the server over a dedicated protocol, removing a layer of FastCGI translation.
One shared, read-only configuration mount
This is the more unusual part of the architecture. The LiteSpeed server configuration, the vhost templates and the lsphp ini settings are a single shared copy for the whole platform, mounted read-only into every WordPress container.
The benefit is straightforward: tune once and every site benefits at the same time, with no per-site config edits. And because the mount is read-only, no process inside a container can tamper with the server configuration.
The trade-off is worth stating too: you cannot change PHP ini settings yourself. If a plugin of yours needs an unusual memory_limit or max_execution_time, you have to tell us and we adjust it on the platform side. That is the bargain of fully managed hosting — you do not have to run operations, but you also cannot dig into the foundations.
Resource changes without rebuilding the container
When you upgrade a plan, the platform has a dedicated command that hot-applies the new CPU, memory and PHP tuning to an existing site without rebuilding the container. That means upgrading does not take your site down for a container rebuild, and the data volume is never unmounted and remounted.
Plan specs
| Plan | Price (billed yearly) | CPU | Storage |
|---|---|---|---|
| WordPress Basic | NT$3,588 (avg. NT$299/mo) | 1.5 cores | 10 GB |
| WP × Roamer AI Pro (includes Business-tier Roamer AI) | NT$11,988 (avg. NT$999/mo) | 2 cores | 10 GB |
Memory is a hard ceiling with no swap (--memory and --memory-swap are set to the same value), so everything reserved for you is physical memory, with no disk standing in for it.
Three places you will actually notice it
1. Behavior at peak
The difference is not “how much faster it is normally”, it is whether it holds up when a lot of people arrive at once. With one person browsing, you cannot tell the two servers apart; you see it in the few minutes after an ad campaign starts or a newsletter goes out.
2. Serving static files
For files that need no computation — images, CSS, JavaScript — how efficiently they are served feeds straight into total page load time. This difference is more visible on image-heavy sites.
3. You do not have to tune it
If you self-host, tuning web server parameters is a subject in itself — worker counts, connection limits, cache rules. In a managed environment that is already configured, and this is really the most valuable part: it is not “we use a better server”, it is “you do not have to become a server administrator”.
Where this stops being a marketing line
“We use a faster server” is the kind of claim that easily turns into hot air, so here is the limit of it: the choice of web server will not make a site with thirty plugins fast.
What it affects is how many people the machine can serve at once for the same amount of work. The work itself — what the plugins are doing, how many database queries run — has not gone down.
What to check when migrating from Apache
Most .htaccess rules are compatible, but not all of them. After migrating, pay special attention to anything you added yourself: redirect rules, hotlink protection, IP blocks, cache headers.
When these break they do not throw an error, they simply stop taking effect. If redirects from old URLs are broken, SEO starts sliding, and you only notice it in the traffic numbers weeks later. The full migration checklist is in migrating from shared hosting.
FAQ
Q: Do I need to understand any of this?
No. This article explains “why”, it is not asking you to do anything. The environment is already tuned.
Q: Will my plugins be incompatible?
The vast majority of plugins and themes work normally, because they interact with WordPress, not with the web server. What behaves differently is anything that depends directly on server-specific behavior, and there are not many plugins like that.
Q: Do I still need a caching plugin?
It depends on the kind of site. Full-page caching pays off hugely on pure content sites; on a store the critical pages cannot be cached, so object caching is what you feel. See Redis object caching.
Q: Can I change the web server configuration?
Managed environments do not open up server-level configuration — that is the price of a uniform environment. If you need full control you need a VPS; the boundary is covered in the limits of managed hosting.
Q: My site is still slow. What now?
The web server is rarely the bottleneck. Check your plugin count and whether object caching is on first — those two usually matter far more. Disabling half your plugins and testing speed is the fastest way to find the answer.
Sources and further reading
Server specs and caching behavior are as documented officially:
Further reading
- WordPress Redis object cache: two invisible optimizations you can feel
- An introduction to RoamerHost WordPress hosting
- Attaching a custom domain and SSL
Want someone to build it for you?
When requirements go beyond what plugins can do, someone has to touch code. Roamer Tech takes on advanced WordPress development:
