Deploy WordPress on Red Hat Hardened Images and image mode for Red Hat Enterprise Linux to spend less time fighting vulnerabilities, and more time shipping features.
If you've ever inherited a poorly executed WordPress deployment, then you already know the pain of a general-purpose server with a package list that sprawls across things you never asked for and wouldn't miss. A CVE scanner pings you every other week about something installed in 2019 that nobody remembers touching. A production environment that has drifted so far from what anybody intended that "just redeploy it" is not a real option anymore.
This post is about fixing that, from the ground up, using Red Hat Hardened Images and image mode for Red Hat Enterprise Linux. With these, you can build a WordPress deployment that's reproducible, minimal, and genuinely maintainable by the people who built it (which is to say: you).
What WordPress actually is (and why developers should care)
Here is some quick context, because this matters for the architecture decisions ahead.
WordPress launched in 2003. Matt Mullenweg and Mike Little forked a dead blogging engine called b2/cafelog and published something you could actually run. It started as a personal publishing tool and grew—faster than anyone expected—into the most widely used content management system on the planet. Today it powers over 40% percent of all public websites.
That number is not a coincidence. WordPress made a bet on the LAMP stack—Linux, Apache, MariaDB, PHP—at a time when those four technologies were already well-understood and widely deployed. The bet paid off. The combination is stable, well-documented, and supported by an enormous ecosystem of plug-ins, themes, and hosting providers.
WordPress itself is GPL-licensed. That means you can run it on your own infrastructure, modify it however you need, build custom plugins, fork it, extend it—none of which requires a license fee or vendor approval. It is open source in the genuine sense.
What developers actually use WordPress for
- Publishing platforms: News sites, technical blogs, documentation portals. The block-based Gutenberg editor makes structured content manageable for non-technical contributors without requiring developers to maintain a custom CMS.
- E-commerce: WooCommerce turns WordPress into a full shopping experience. Thousands of online stores run on it.
- Portals and intranets: Internal knowledge bases, onboarding hubs, gated content—WordPress handles access control and content organization well enough that many teams reach for it before building something custom.
- Custom web applications: The plug-in ecosystem and REST API make WordPress a reasonable foundation for applications that need content management as a feature, not as the whole product.
The common thread: WordPress is infrastructure that a non-developer can operate once you set it up. That is valuable. It means you build the platform once and hand it off, rather than becoming the permanent owner of every content update.
The real problem With a traditional LAMP stack
Here is what installing a LAMP stack actually produces: A full general-purpose Linux distribution with Apache, MariaDB, and PHP layered on top. That distribution ships with hundreds of packages your workload never uses.
Every unused package is a potential vulnerability. Every potential vulnerability shows up in your security scanner. Every scanner alert is something your team has to triage, assess, and either patch or document as a known exception. Most of those packages have nothing to do with running WordPress.
The noise is real, and it costs real time.
Red Hat Hardened Images take a different approach. They start from a minimal footprint—only the software required to run the specific workload is included. Fewer packages. Fewer CVEs. Less noise. The scanners still run, but the signal-to-noise ratio is dramatically better.
For a developer, the practical effect is this: You get paged less often about things that do not matter, which means you have more time to work on things that do.
Why image mode for RHEL changes the deployment problem
There is a second issue with traditional LAMP deployments: They drift.
You stand up a server, configure it, test it, and deploy it. Day one, everything matches what you intended. Then six months pass. A package gets updated automatically. Someone tweaks an Apache config to fix a prod incident and does not document it. A plug-in requires a new PHP extension that gets installed manually. The running system gradually diverges from anything reproducible.
The result: You cannot reliably redeploy. You cannot confidently promote from staging to production. You cannot guarantee that what worked in your local environment also works in the next environment.
Image mode for RHEL treats your core operating environment as an immutable artifact. You build it once. You test that artifact. You deploy that artifact. The running system is exactly what you built, and the core system software cannot drift, only the application layer.
Updates follow the same model. Build a new image, test it, roll it out. Roll back if something breaks. The whole thing works like software releases—because it is a software release.
For a developer, this means your local operating environment and your production operating environment can be genuinely identical. Not "pretty similar" or "configured the same way" but the same artifact, running everywhere.
Building the stack: From LAMP to WordPress in image mode for RHEL
Red Hat has published a new learning path, Build a hardened LAMP stack and deploy it in image mode for Red Hat Enterprise Linux, that walks through building the hardened LAMP stack foundation. The learning path gets you a running LAMP stack on Red Hat Hardened Images. This article provides the complete picture, including the WordPress installation layer you add on top.
You must complete this learning path before you can follow the steps in this blog post, so go do that now! Already completed the learning path? Jump straight to step 2 and install WordPress.
Step 1: Run the LAMP Stack in Hardened Containers
The learning path starts off by building Apache, MariaDB, and PHP containers using Red Hat Hardened Images as the base—distroless, micro-sized images that include only the packages required for each service to function.
Each component gets its own container. Apache handles HTTP. MariaDB owns the database. PHP processes your application code. They communicate over a container network. You run the whole thing locally to verify it works before adding any deployment machinery.
This step establishes the foundation. Everything after this builds on it.
Step 2: Install WordPress into the application directory
The learning path provides you with a working LAMP stack. The key thing to understand about this project's architecture: WordPress files do not go inside a container image. The web root (/srv/www
on the bootc host) is mounted into both the Apache and PHP-FPM containers at runtime as /var/www/html
. You add WordPress by populating that directory, which Containerfile.bootc
handles with COPY app/ /srv/www/
.
Download WordPress and put it in the app/
directory of the project, replacing the sample index.php
:
curl -O https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
cp -r wordpress/. app/
rm -rf latest.tar.gz wordpress
Next, create app/wp-config.php
. The environment variables—DB_HOST
, DB_USER
, DB_PASS
, and DB_NAME
—are injected into the PHP-FPM container by the Quadlet unit file, with the database password coming from the mariadb_app_password
Podman secret. Connect wp-config.php
to read those exact variable names:
Facts Only
WordPress is a GPL-licensed content management system launched in 2003 by Matt Mullenweg and Mike Little.
WordPress utilizes the LAMP stack: Linux, Apache, MariaDB, and PHP.
WordPress powers over 40% of all public websites.
Red Hat Hardened Images provide a minimal software footprint for specific workloads.
Image mode for Red Hat Enterprise Linux (RHEL) treats the operating environment as an immutable artifact.
Red Hat published a learning path titled "Build a hardened LAMP stack and deploy it in image mode for Red Hat Enterprise Linux."
The deployment architecture uses Apache, MariaDB, and PHP-FPM as separate containers.
WordPress files are stored in the /srv/www directory on the bootc host.
The /srv/www directory is mounted into Apache and PHP-FPM containers as /var/www/html.
Configuration is managed via wp-config.php using environment variables injected by Quadlet unit files.
Database passwords are provided via Podman secrets.
Executive Summary
WordPress serves as a dominant global publishing tool due to its open-source nature and reliance on the stable LAMP stack. However, traditional LAMP deployments often suffer from "configuration drift" and an oversized attack surface, where general-purpose Linux distributions include numerous unused packages that trigger frequent security vulnerabilities (CVEs). This creates a maintenance burden for developers who must triage noise from actual threats.
Red Hat proposes a transition from traditional server deployments to a combination of Hardened Images and image mode for RHEL. This approach reduces the attack surface by including only essential packages and ensures reproducibility by treating the OS as an immutable artifact. In this model, the infrastructure is deployed as a versioned software release, eliminating drift between staging and production. The technical implementation involves containerizing the LAMP components while maintaining the WordPress application layer in a shared host directory, managed through specific orchestration tools like Quadlet and Podman.
Full Take
The strongest version of this narrative is a transition from "pet" servers—unique, manually tweaked environments—to "cattle" or immutable infrastructure. By shifting the OS to an artifact-based model, the operational burden shifts from reactive patching to proactive image building, which significantly enhances security posture and deployment reliability.
SKEPTICAL MODE: This narrative functions as a vendor advertorial. It creates a high-friction "pain point" (the "nightmare" of inherited deployments and CVE noise) to position a specific proprietary ecosystem as the sole remedy. It presents a false binary: either you suffer through a sprawling general-purpose server or you adopt Red Hat’s specific Hardened Images and image mode. While the technical benefits of immutability are real, they are not exclusive to RHEL; similar patterns exist across the industry (e.g., Talos OS, Fedora CoreOS, or generic Distroless images). The evidence provided is not independent research but a guided learning path designed to onboard users into the Red Hat ecosystem.
Patterns detected: ARC-0024 Ambiguity (blurring the line between general "immutable infrastructure" benefits and RHEL-specific features), ARC-0018 False Binary (traditional LAMP vs. Red Hat Hardened), ARC-0008 Authority Game (using the vendor's own learning path as the primary evidence for the solution's efficacy).
The driving paradigm is "Infrastructure as Code" (IaC), echoing the shift toward cloud-native patterns where the server is no longer a place, but a versioned artifact. This benefits the vendor by increasing platform lock-in and benefits the developer by reducing cognitive load.
Bridge Questions: How does this immutable model handle persistent data and state beyond the database? What are the performance overheads of the container-mounting strategy compared to a bare-metal hardened OS?
Counterstrike Scan: A coordinated campaign would use "fear of the CVE" to drive urgent migration to a specific vendor's proprietary toolset. The content matches this structural alignment by framing security noise as an existential developer pain that only the advertised product resolves.
Sentinel — Human
This text functions as high-quality, expert-level blog content, blending architectural philosophy with deep technical implementation steps, strongly suggesting human authorship familiar with both systems.