AdminsForum: WordPress + Varnish 9.1 isolated training example
Verified on Ubuntu 22.04 amd64, aaPanel Nginx 1.30.5, PHP 8.5.11 and MariaDB.
This is a manual training example, NOT the aaPanel addon installer, a managed service, or a production integration.

Root directory: /opt/af-wp-varnish-20261020
Private ports: 127.0.0.1:18190 front; :18191 origin; :18192 cache; :18193 management.
New database: af_wp_varnish_20261020; new DB user afwpvarnish20@localhost.
WordPress users are randomly generated and saved only in root-readable private-users.json.
Setup reads aaPanel's stored MySQL root credential locally to create the separate database/user. It does not print it.
setup-wordpress.py intentionally refuses to overwrite an existing wp-config.php or database.
Do not change the root path, port numbers or DB names in only one file. Stop if any conflict exists.

Inspect all scripts before running. On the declared prepared aaPanel lab:
sudo python3 setup-engine.py
sudo python3 setup-wordpress.py
sudo install -m 0644 runtime.py /opt/af-wp-varnish-20261020/runtime.py
sudo python3 /opt/af-wp-varnish-20261020/runtime.py prepare
sudo python3 /opt/af-wp-varnish-20261020/runtime.py start
sudo python3 verify-wordpress.py
sudo python3 /opt/af-wp-varnish-20261020/runtime.py stop

verify-wordpress.py changes only the dedicated lab's demonstration post, creates a private session-check endpoint and uses the generated disposable accounts. It does not measure performance. It verifies caching, exclusions, two-user privacy and manual invalidation. It does not test WooCommerce, HTTPS or production aaPanel routing.
The example MU plugin explicitly opts only anonymous front-page and post responses into a 60-second public policy; do not copy it into an arbitrary plugin/store/session-based application.
Files remain after stopping; no automatic database, user or website deletion is performed.
Copyright AdminsForum | adminsforum.com
