We finally have a first release candidate for EasyEngine v4 tagged RC1.
This release adds support for migrations between EasyEngine versions seamlessly.
You can start testing on a fresh VPS. Currently, we support a limited operating system that includes Ubuntu 14.04, 16.04, 18.04 and Debian 8. Please run the following command:
wget -qO ee rt.cx/ee4 && sudo bash ee
- Seamless self-update for the next EasyEngine version
- Support added for global mysql and redis
- Logs and Confs now made available under site root
- EE shell is now supercharged
- Auth command now has the whitelisting option
- Some commands have been renamed to ensure their consistency
- Minor bugs have been fixed
You will be able to update to next EasyEngine versions just by running
ee cli update. This includes the stable as well as intermediate updates, such as, RC1 to RC2 upgrade. 👋
ee cli update command automatically updates sites for changes, related to that command. For e.g. PHP container has an update, say a security patch,
ee cli update will ensure that all sites using PHP get updated to the latest container image.
Changing the container image on a running site may lead to a downtime of a few seconds, in some cases. Therefore, please plan your update carefully. Ideally, do it when the server CPU load is low.
If you have a large MySQL database, then restarting MySQL will have its own latency. The MySQL restart time is in no way related to EasyEngine or Docker it uses.
Ofcourse, MySQL will not restart all the time, but, only when there is an update available.
Before this release, all sites created with EEv4 had their own mysql and redis container. Redis is used for WordPress sites when full-page caching is enabled.
This was becoming a resource hog. Hence from this release, by default, all sites will use a single global database container and single global redis container.
However, if you wish to have separate mysql or redis containers for a site, you can do that by passing a flag during site create
ee site create example.com --type=wp --local-db --with-local-redis
Now, each site’s PHP and Nginx configuration as well as log files are available under each sites’ root folder.
Earlier, many of them were only present in containers, hence, you cannot see them directly on your filesystem. However, now you can easily view and even edit them per site.
For a site such example.com, logs & confs will be accessible from following paths:
- PHP conf =>
- PHP logs =>
- Nginx conf =>
- Nginx logs =>
Also, configuration and logs of global services like nginx-proxy, mysql and redis are now mounted at
We have updated
ee shell command to add three things.
Non-interactive command execution
ee shell example.com --command="wp core verify-checksums"
Each EE site, except HTML site, has at least PHP, Nginx and Postfix containers. Depending on the way you create a site, the site might have MySQL, Redis and/or Mailhog containers associated with them.
Until now, every time you ran
ee shell, you used to exec shell inside PHP container, except for HTML site type.
Now, you can specify a container using
--service parameter such as:
ee shell example.com --service=nginx
Each docker container has a default Linux user. For PHP & Nginx containers, it’s www-data.
For MySQL, Redis, Mailhog, and Postfix, the default user is root.
You can specify user via
--user parameter such as:
ee shell example.com --user=root
Combing these new parameters
You can combine these newly introduced parameters in any way you like. Such as:
ee shell example.com --service=nginx --command="nginx -t" --user="root"
Auth command in EEv4 now has the option to whitelist an IP, as it was in EEv3.
You can use the following command, which will whitelist the given 2 IPs from auth. You can pass any number of IP addresses, separated by a comma.
ee auth create --ip="184.108.40.206,220.127.116.11"
We ran into one of the two toughest problems of computer science, during this project, many times! We have fixed the naming issue upto some extent, hopefully. 🤞
The following commands were renamed:
ee admin-tools up=>
ee admin-tools enable
ee admin-tools down=>
ee admin-tools disable
ee mailhog up=>
ee mailhog enable
ee mailhog down=>
ee mailhog disable
ee cron add=>
ee cron create
- Site delete now deletes site auth, cron jobs, redirection configs and purges object as well as page cache, if any.
- Site command –cache flag during site creation now enables object cache and also adds the nginx-helper plugin, which helps purge page cache.
- Update default database charset to utf8mb4
- The real IP of users is now correctly forwarded to site’s nginx
- Rename cache keys (full-page cache and object cache now have a separate key prefix)
- You can now run cron as a specific user
- Change wp cron event run to 1hr instead of 5 mins
- All global services have been added into docker-compose.yml
- The installation of admin-tools have been made faster by switching to a zip based installation, instead of the installation method with the previous composer.
We understand that the final beta to the first RC, we took more than a month. But since v3 to v4 is a big change, we want to test v4 on our own sites first. We believe in dogfooding! 🐶
We tagged RC1 and have already moved many of our sites, including this one on EasyEngine v4.. 🎉
We might need one last RC before we can have 4.0. While we will not announce the release dates, we are optimistic about a mid-November 4.0 release.
The only way we can improve quality of final EasyEngine project is by testing early and testing as much as possible. So please test EasyEngine and send us all the feedback you can send via Github issue tracker.