EasyEngine: nginx, PHP and WordPress sites from one root CLI

A control panel that only speaks CLI

EasyEngine's own description is a command-line control panel for nginx, managing WordPress sites that run on nginx, PHP, MySQL and Let's Encrypt. The repository README is narrower, framing it as making nginx easy to manage, and describing nginx as a fast web-server software that consumes little memory as concurrent user volume rises.

The audience is a server administrator who would otherwise write Docker Compose files by hand. Composing nginx, PHP-FPM, MySQL and a certificate client for a new site is four services and about eighty lines of YAML that you write again for every domain. EasyEngine turns that into a command with a domain argument.

That framing explains the project shape. It is a PHP CLI distributed as a phar, built on top of the wp-cli framework rather than from scratch, and it talks to Docker and Docker Compose on the host. The requirements list is explicit about what has to be present first: Docker, Docker-Compose, PHP CLI at 7.4 or newer, and three PHP modules, `curl`, `sqlite3` and `pcntl`.

The `pcntl` requirement is a clue worth noting. Process control functions are what let a CLI supervise background work, and EasyEngine ships an `ee cron` command among others, so its scheduling runs through PHP rather than through the host's cron daemon.

Two install paths, and neither pins a version

On Linux the README leads with a one-liner installer.

wget -qO ee https://rt.cx/ee4 && sudo bash ee

The README says the script installs all the dependencies, and that it has been tested on Ubuntu 20.04, 22.04 and 24.04 and Debian 11 and 12. It also says that if the script does not work for your distribution you can install the dependencies by hand and fetch the phar directly.

wget -O /usr/local/bin/ee https://raw.githubusercontent.com/EasyEngine/easyengine-builds/master/phar/easyengine.phar
chmod +x /usr/local/bin/ee

That second command deserves attention from anyone who cares about reproducible installs. The URL points at a `master` branch in a separate repository, `easyengine-builds`, not at a tagged release, so two machines that run it a week apart can end up with different binaries. There is no checksum in the command and no version argument. The releases are real and numbered, v4.13.0 on 2026-09-28 after v4.12.0 on 2026-07-08, but the documented install path does not reference them.

The tested-distribution list is another thing to verify rather than trust. The README does not say when that list was last refreshed, and it names distributions and versions that sit behind the current 4.13 release line.

Creating a site is the whole tutorial

A WordPress site is one command.

ee site create example.com --type=wp

Everything else is a variation on that. Adding caching, a WordPress multisite on subdirectories, or dropping to a plain HTML site are all flags on the same command.

ee site create example.com --type=wp --cache
ee site create example.com --type=wp --mu=subdir --cache
ee site create example.com

The last one is the one to try first if you are evaluating the tool, because it exercises the nginx and Docker Compose path without a database or a PHP application behind it.

Once the site exists, `ee shell` drops you into it.

ee shell example.com

The README's framing for that is worth repeating exactly, because it is unusually candid about where the value is: want to play around with your new site. Interactive exploration is the intended use, not just a fallback.

Help is available at three levels, and the README recommends it rather than hiding it.

ee help site create --type=wp

There is also a Bash and ZSH completion script at `utils/ee-completion.bash`. On zsh it needs `bashcompinit` loaded first, which is the usual friction point when reusing a Bash completion file.

One repository for the framework, ten more for the commands

The development section explains the architecture better than any diagram would. Development is done entirely on GitHub, wp-cli is used as a base framework, and this repository holds the main core.

Then the sentence that matters: all top-level commands except `ee cli`, meaning `ee site` and `ee shell`, live in their own repositories. A separate repo per command, released separately, all bundled by default into one distribution.

The bundled list has ten entries, each with its own repository: site, with php and wp site types, plus admin-tools, auth, config, cron, dash, log, mailhog, service and shell.

Three of those names tell you what this tool actually is. `service` is about managing the Docker services a site runs on, `mailhog` is a mail catcher so WordPress does not send real mail from a staging site, and `dash` is a dashboard view of running sites. Those are the unglamorous jobs that make a hosting workflow repeatable.

The split does have a cost. An upgrade is not one version bump, it is a question about whether the site command and the shell command you rely on are compatible with the core you are running.

Root privileges, stated in a warning

The README carries this note: EasyEngine will currently only run with root privileges.

That single line changes how you have to deploy it, and it interacts with the installer. The documented Linux path is `sudo bash ee`, and the phar is written into `/usr/local/bin/ee`, both of which imply a root shell to begin with. EasyEngine writes to system paths, generates nginx configuration that nginx itself has to read, and manages containers, so it cannot simply be dropped into an unprivileged user account.

The consequence for a team is that EasyEngine lives on the server, not in a developer's shell on a laptop or inside a CI runner. Any attempt to script it as a non-root user fails immediately rather than partially, which is at least a clean failure mode.

The requirement is not a criticism of the design so much as a description of it. Managing nginx and Docker for arbitrary domains is a system-administration task, and the tool reflects that. It does mean the security boundary is the root account, and any policy that forbids root in your environment rules the tool out before its features are considered.

The promised plugin ecosystem has not arrived

The README's development section ends with a forward-looking line, that in future the community will be able to make their own packages and commands.

Present tense is worth measuring against. The repository listing shows `docs/`, `templates/`, `migrations/`, `features/`, `tests/` and `utils/` inside the core, and a `php/` directory, but no `packages/` or `plugins/` directory holding third-party commands. Everything currently shipped comes from the EasyEngine organisation's own repositories.

That is not a criticism of the project, which is actively maintained, with the last push on 2026-09-28 and the default branch set to `develop` rather than `main`. It is a signal about what adopting it means today. If you need a command that does not exist, you are writing it against an interface that is still settling, not filling in a gap in a mature extension API.

The repository also ships `img-versions.json`, which maps image versions for the container assets the tool pulls, and a `VERSION` file alongside `composer.json` and `composer.lock`. Those are the kinds of files that exist when a project has to keep container assets and PHP code in step, which is a fair amount of machinery to be carrying.

EasyEngine against a hand-written compose file

The real alternative is the one this project replaces: write the Docker Compose stack yourself and use a provisioning tool for the parts that repeat.

The difference in approach is where the knowledge lives. A hand-written compose file puts every decision in a file you can read, diff and review, including the nginx server block, the PHP-FPM socket, the MySQL credentials and the volume layout. Nothing needs root beyond the initial setup, nothing is hidden behind a PHP CLI, and the stack behaves like any other container set.

EasyEngine inverts that. The decisions are encoded in the site-type repositories and the core framework, and you get a stable interface, consistent behaviour across sites, and commands like `ee cron` and `ee service` that would each be a project of their own if you wrote them. What you give up is the file you can read, in exchange for a tool whose own files you would have to read instead.

The tie-breaker is usually operational. If you run a handful of WordPress sites on one server and want them reproducible, EasyEngine saves real work. If you need to inspect, patch or migrate the nginx configuration for one site, a compose file you own is faster to reason about.

Editorial conclusion

Adopt EasyEngine on a Linux server where you run a handful of WordPress sites and want them reproducible without maintaining compose files, and pin the phar version yourself because the documented install fetches a master branch with no checksum. Do not adopt it in an environment that forbids root, or where you need to read and diff the nginx configuration for one site. Verify first that your distribution appears in the tested list of Ubuntu 20.04, 22.04, 24.04 and Debian 11, 12, because the README does not say when that list was refreshed.

Frequently asked questions

Official sources

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