+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel)
+---- Forum: aaPanel Addons & Plugins (https://adminsforum.com/Forum-aapanel-addons-plugins)
+----- Forum: Varnish Cache for aaPanel (https://adminsforum.com/Forum-varnish-cache-for-aapanel)
+----- Thread: Guide Install Varnish Cache in aaPanel: Closed Lab Preview (/Thread-guide-install-varnish-cache-in-aapanel-closed-lab-preview)
Install Varnish Cache in aaPanel: Closed Lab Preview - DEV - 10-24-2026
Updated 24 October 2026 | Varnish Cache by Adminforum 0.6.0-lab | Verified scope: one audited WordPress/Nginx website.
This guide covers Varnish Cache by Adminforum 0.6.0-lab, the development build tested on our existing aaPanel lab. It explains how its control files are validated and how the audited WordPress website is added and enabled.
This is not a clean-server installation recipe. The current native integration is restricted in code to blog.adminslab.com, aaPanel site ID 11, using Nginx/PHP and the WordPress template. Its Varnish binaries and runtime dependencies were already prepared on this lab. Copying the control files to another server will not produce a supported working installation. A portable installer and the full aaPanel webserver matrix remain release gates.
1. Check the tested environment
Operating system: Ubuntu 22.04 lab VPS
aaPanel: 8.0.7; multi-webserver feature enabled
Website assignment: Nginx 1.30.6
WordPress PHP: 8.5.12
WordPress: 7.1.3
Varnish: 9.1.0
Dedicated cache capacity: 32 MiB
Having Apache or OpenLiteSpeed installed does not establish addon compatibility with those website assignments. aaPanel supports per-site server choices and proxy combinations; each requires its own integration tests. See aaPanel Multi-WebServer Hosting.
Before a closed test, retain a private copy of the plugin files and the site's native configuration. Confirm that WordPress works over valid HTTPS, that the website is assigned to the audited engine, and that the application/database can be recovered. Keep the lab's noindex and outgoing-mail guard in place.
2. Validate the installed control files
The current lab control directory is:
Code:
/www/server/panel/plugin/af_varnishFor an operator already working in this prepared lab, the installation-validation command is:
Code:
bash /www/server/panel/plugin/af_varnish/install.sh installIt validates the known control files and their permissions. It does not download or install the Varnish engine, prepare a fresh server, start caching or rewrite a registered website. On this test run, it completed while the existing native cache stayed enabled and its public route remained unchanged.
Use a reviewed build supplied for the specific lab. There is no public download link for the current native build in this guide. Do not substitute an older preview archive and assume it includes the current native controls.
3. Open the addon
1. Sign in as the primary aaPanel administrator.
2. Open **Home → Software → Varnish Cache by Adminforum**.
3. Confirm that the addon loads and website discovery completes.
4. If an update appears to use older code, reopen the addon. A panel-process refresh may be required by the operator after deployment; this is separate from rebooting the VPS or restarting website services.
4. Add the audited WordPress website
1. Choose **Add website**.
2. Select the existing `blog.adminslab.com` website from aaPanel.
3. Choose **WordPress** as the application template.
4. Choose **Add website** to save it in the addon workspace.
Adding a website does not enable caching. The template identifies the application; it does not mean that every application or server mode has a working adapter.
5. Enable caching and verify the route
For the audited lab website, open Websites and choose Enable caching in the managed WordPress control card. Wait for the operation and verification to finish.
The addon creates a dedicated private Varnish service and a site-specific origin handoff while retaining the native HTTPS frontend. It keeps an original-route backup and configuration fingerprints. It does not require a global webserver switch.
Successful activation shows Varnish: active. The green state requires both a verified managed process and a successful HTTPS response through the cache route. A website simply returning HTTP 200 is insufficient.
Open Dashboard to check request counters, hit rate, traffic readings, memory, version and uptime. Use a logged-out request to a cacheable public post to confirm a MISS followed by a HIT. See the configuration guide.
6. Disable safely before removal
Use Disable caching and wait for the native direct route to be restored. Only then remove the website from the addon list. Removing it from the addon list does not delete its aaPanel website, files or database.
The installer refused uninstall while the native cache was configured in our live test. The website route and plugin files remained intact. This verifies the active-cache safeguard, not a complete clean uninstall/reinstall lifecycle.
Do not delete runtime files or manually stop dependencies while a managed public route still needs them. If a native configuration has changed, preserve it and resolve the conflict; do not overwrite it with an older backup merely to force removal.
Installation troubleshooting
Addon opens but activation is unavailable: Confirm the exact supported site, engine and WordPress template. Other sites remain outside native activation scope.
Enable rolls back: Inspect the private routing journal, Nginx validation and PHP/site errors. Confirm the original website still works.
PHP cannot read addon configuration: Preserve open_basedir. The corrected bridge embeds its installed key in the PHP-readable MU plugin; it does not require relaxing the restriction.
Quick re-enable reports an occupied private port: Allow graceful listener retirement; identify a real port owner before retrying. Do not kill an unknown process.
Uninstall is refused: Disable the managed native cache first and confirm direct routing.
Public release still requires portable dependency installation, additional native engine adapters, mixed-engine tests and lifecycle validation. Until then, use this procedure only within the explicitly prepared closed lab.
Original AdminsForum lab work. Copyright AdminsForum | adminsforum.com.
Guide series: Installation | WordPress configuration | Measured results