WordOps: the stack chooser that puts a site on Nginx, PHP and Redis in one command

One command chooses the whole stack, including the cache

WordOps is described as a tool that installs and manages a high performance WordPress stack with a few keystrokes, and the README calls it an essential toolset that eases WordPress site and server administration.

The design shows up in the site create flags. Each one is a different stack, and the choice of caching layer is a flag rather than a configuration exercise:

wo site create example.com --wp                # install wordpress with [Current supported PHP release](https://endoflife.date/php) without any page caching
wo site create example.com --wp  --php84       # install wordpress with PHP 8.4  without any page caching
wo site create example.com --wpfc              # install wordpress + nginx fastcgi_cache
wo site create example.com --wpredis           # install wordpress + nginx redis_cache
wo site create example.com --wprocket          # install wordpress with WP-Rocket plugin
wo site create example.com --wpce              # install wordpress with Cache-enabler plugin
wo site create example.com --wpsc              # install wordpress with wp-super-cache plugin

So there are two axes of choice. The first is whether the page cache lives in Nginx, as fastcgi_cache or as redis_cache, or inside WordPress as a plugin, with WP-Rocket, Cache-enabler and wp-super-cache as the three named plugin options, or is absent entirely with the plain --wp flag. The second is the PHP version, with --php84 as an example and a note that the plain --wp uses the current supported PHP release.

That is the product in one screen. A person who knows the difference between a page cache in Nginx and a cache plugin in PHP can express their decision in a single flag, and the tool installs the packages, writes the configuration and sets up the site.

The same flag grammar extends to the other site types. Multisite is --wpsubdir or --wpsubdomain, and each accepts the same cache flags. A plain PHP site is --php with the same version suffixes, and --mysql adds a database with a --php83 example for a specific combination. There is also --html for static sites, and --proxy for something else entirely.

The reverse proxy mode is the least WordPress-shaped feature

One command in the non-WordPress list is worth isolating, because it shows that the tool is a stack builder rather than a WordPress plugin manager.

wo site create example.com --proxy=127.0.0.1:3000 #  create example.com with nginx as reverse-proxy

The site is created with Nginx as a reverse proxy in front of something already listening on a local port. That is the case for a Node, Go or Python application that has its own process manager, and it is the feature that makes WordOps usable on a server that hosts one application as well as WordPress sites.

The README's list of non-WordPress sites is otherwise unsurprising, static and HTML sites with --html, PHP sites with --php and its version suffixes, and --mysql for a site with a database. The proxy option is the one that has no WordPress analogue, and its presence alongside the WordPress site types is a good indicator of how the tool thinks: the site type is the unit, and WordPress is one kind of site rather than the only kind.

The reverse proxy mode also connects to the SSL story, since the feature list includes domain, subdomain and wildcard Let's Encrypt certificates with DNS API support, and any of these sites is a candidate for a certificate. A site created with --proxy therefore gets the same certificate management as a WordPress site.

The other site lifecycle command is site update, and its documented use is switching PHP versions, which is the operation that has to work without a rebuild:

wo site update example.com --php74 # switch to PHP 7.4
wo site update example.com --php85 # switch to PHP 8.5

The versions listed cover 7.4 through 8.5, and the key features section says PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 are supported, so a site can be moved between them in place.

The Nginx build and the security posture are the parts you inherit

Two of the feature bullets describe what you get rather than what you do, and they are the ones with the longest reach.

The first is the custom Nginx build, described as Nginx 1.30.4 with TLS v1.3, HTTP/3 QUIC and Brotli support. This is not the distribution's Nginx. The tool builds its own, which is how HTTP/3 and QUIC end up available on a distribution whose packages would not have them, and it is also a maintenance commitment the user inherits without choosing it.

The second is the hardening claim: hardened WordPress security with strict Nginx location directives, and optimised Nginx configurations with multiple cache backends support. The strict location directives are the part that matters operationally, because a WordPress site served through Nginx is exposed to a set of request patterns that the default configuration does not block, and the file layouts that forbid them are the reason the tool writes its own configuration rather than using the distribution's.

The TLS claim is specific too. The README claims a strong cipher suite, modern TLS protocols and HSTS support, and points at an SSL Labs report for the demo server, with a Grade A+ marking. The report is for demo.wordops.eu, which is the project's own demo instance rather than a site you have installed, so it is evidence about the default configuration and not about a site with extra plugins or a non-default PHP version.

The stack versions are listed in the same style: MariaDB 11.4 LTS and Redis 7.0 alongside the PHP versions, which is a deliberately current set rather than a conservative one. That choice has a consequence for a site that has to run an old plugin, and it is why the version flags exist at all.

Monitoring comes in two forms in the feature list, live Nginx vhost traffic with ngx_vts_module and server monitoring with Netdata, and both are additional software the installer will put on the machine.

A Cement-based CLI with pinned dependencies and a plugin config directory

The implementation is a Python package, and the dependency list tells you it is a structured CLI rather than a script.

cement==2.10.14
pynginxconfig==0.3.4
PyMySQL==1.1.2
psutil==7.0.0
sh==2.2.2
SQLAlchemy==1.4.54
requests>=2.20.0
distro==1.9.0
argcomplete==3.6.3
colorlog==6.10.1

Cement is a framework for command line applications, and it is what gives WordOps its subcommand structure, so wo site create and wo site update are Cement commands rather than argument parsing in a main function. pynginxconfig is a Python library for editing Nginx configuration files, which is how the tool writes its site configs and its strict location directives. sh runs shell commands, psutil reads process and system state, PyMySQL talks to MySQL directly for database work, SQLAlchemy handles the metadata the tool keeps, and distro identifies the running Linux distribution, which matters for a tool whose supported platforms are a specific list of Debian and Ubuntu releases.

The packaging in setup.py shows the plugin structure. The build collects the Nginx configuration templates and the CLI templates by globbing config/plugins.d/*.conf and wo/cli/templates/*.mustache, and the mustache extension is the giveaway that site configuration is rendered from templates. There is also a step that creates /var/log/wo/ and /var/lib/wo/tmp/ when the setup runs as root, so the tool has a log directory and a temporary directory it expects to own.

The package is declared as version 3.23.1, MIT licensed, classified as Development Status 5 - Production/Stable, with a console environment and the keywords nginx automation wordpress deployment CLI.

The root listing also shows an install/ directory, a config/ directory, a wo/ directory for the package itself, docs/, tests/, and setup.cfg. The install/ directory is where the one-step installer lives, and the configuration templates in config/plugins.d/ are how a service such as Nginx, PHP or Redis is described in a way the tool can install and configure.

The supported platform list and the release calendar are both narrow

Two constraints in the README determine whether the tool applies to you at all, and both are easy to miss.

The first is the operating system. The recommended list is Ubuntu 24.04 LTS, known as Noble, and Ubuntu 22.04 LTS, Jammy. Also compatible are Debian 11 Bullseye, Debian 12 Bookworm and Debian 13 Trixie. Raspbian 11 is listed for testing purpose only, which is a way of saying it is not a supported platform.

That list is short in a way that matters, because it is Debian-derived only. There is no RHEL, no Rocky, no Alpine, and no Fedora, and the installation method is a script fetched with wget and run with sudo bash, which is an apt-shaped procedure. The tool's use of the distro package to identify the running system, and its background of migration from EasyEngine v3 support, both point to a tool built for a specific family of distributions.

The second is the release cycle, stated as a feature: WordOps stable releases are published in June and December. The release history shows v3.23.1 as a maintenance release on 2026-08-07, v3.23.0 as a stable release on 2026-08-06, and v3.22.0 as a stable release on 2024-12-06.

That history is worth reading carefully. A stable release in December 2024, then a stable release in August 2026, and the documentation says stable releases are published in June and December. The August 2026 stable release is close to the June slot, and there was no December 2025 release in the list, so the schedule has slipped or a release was skipped. The last push was on 2026-08-07, the same day as the maintenance release, so the repository is current with its latest tag.

The practical consequence is that a two-release-a-year cadence means a security fix in Nginx, PHP or MariaDB waits for the next stable release, and an operator who wants the newest upstream versions is not going to get them from this tool on demand.

Where WordOps is the wrong tool

The limits follow from the shape of the tool, and they are mostly about scale and about what it does not manage.

The first is that it manages a server, not a fleet. Every command in the README operates on one machine, and the site creation is an installation of packages plus a configuration of files on the local host. A team with twenty servers is going to run it from a configuration management system that already knows how to install Nginx, PHP and MariaDB, and the difference is that WordOps writes configs that WordOps understands. There is no remote mode described, and no inventory of managed hosts.

The second is the upgrade path for WordPress itself and for the stack beneath it. The tool installs and configures the stack, and it will switch the PHP version of a site, but the README does not describe keeping the operating system packages, the Nginx build or WordPress core up to date, beyond the fact that a maintenance release exists. An operator still has to watch for upstream security advisories and decide when to take a new stable release.

The third is the custom Nginx build as a long-term commitment. Compiling your own Nginx means the distribution's security updates do not apply to it, and the tool has to rebuild it. The HTTP/3 and QUIC support is the reason, and that is a real benefit, but it also means a component that the package manager no longer tracks.

The fourth is that the demo dashboard and the monitoring add surface area. The feature list mentions a WordOps dashboard with server status and monitoring, and Netdata plus the ngx_vts_module for traffic. Every one of those is another thing running on the server, and the dashboard in particular is a web interface into the machine that a team will need to think about locking down.

The fifth is the narrow platform support, already covered, and the sixth is the version floor. The tool ships PHP 7.4 through 8.5, but a WordPress site with an old plugin may need an old PHP, and a site pinned to a PHP version the tool will not offer is a site that has fallen outside the managed set. The migration story from EasyEngine v3 exists for people coming from that tool, and for everyone else the tool assumes a fresh Ubuntu or Debian server.

Editorial conclusion

WordOps is worth adopting for a small team that hosts WordPress on a single Ubuntu or Debian server and wants a repeatable stack with a chosen cache backend, because the site create flags cover the combinations that are otherwise a day of configuration. It is the wrong tool for a fleet, for a non-WordPress application that needs anything beyond a reverse proxy, and for anyone who needs to run WordPress on a platform outside the listed distributions, since the installer is written around apt and systemd. Before installing, read the installation guide for the alternative methods, decide which cache plugin or backend you actually want rather than accepting the default, and check the release schedule, because the stable line ships in June and December.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. WordOps/WordOps on GitHub