Nahnu Cache Connector for Bunny.net

It integrates with the 18 cache plugins listed above. Without one of them you can still use the edge rules, manual purge, admin bar button, CDN stats and the post save and update purge triggers. Purges just are not mirrored from a cache plugin.

Yes. Pick the second pull zone under Settings, Second pull zone (optional), or define WPBC_PULL_ZONE_ID_2 in wp-config.php. Both zones then get the same edge rules, and every purge clears both. If one pull zone already lists both hostnames, or one hostname redirects to the other before it reaches Bunny, you do not need a second zone. The settings screen tells you which case applies once your zones are loaded.

No. Rules redeploy automatically in the background after every update, reinstall or activation, and a five-minute check catches anything missed. You can still deploy manually from the Edge Rules tab at any time, and a manual deploy always takes priority.

Yes. Each bypass rule checks for its plugin at deploy time. If WooCommerce is not active, the WooCommerce rules are skipped. When a supported plugin is activated or deactivated, rules redeploy in the background.

Yes. Bypass rules include translated page URLs, and the pull zone varies its cache by Accept-Language.

When someone with a selected role logs in or opens an admin page, the plugin sets a cookie holding a secret that is unique to your site. Edge rules turn Shield off only for requests carrying that exact value, and only for admin, logged-in REST, builder and media processing URLs. Visitors are always inspected. You can choose the roles in Settings (Administrator and Editor by default) and rotate the secret at any time.

It sets all six headers the scanner grades on. Test both your www and non-www addresses after the rules deploy. If your site needs a stricter Content-Security-Policy, or HSTS with includeSubDomains and preload, set it with the wpbc_security_headers filter.

Yes, on both the dashboard and child sites. Child sites trust the dashboard's IP in Shield automatically, the dashboard can reach child sites directly at their origin, and pull zones never resend timed-out MainWP requests. For best results use a real server cron on the dashboard and set MainWP's child request timeout to at least 300 seconds. The Integrations tab shows the status for each site.

Yes. Each dashboard's IP is trusted in Shield after its first verified request, its login links are never cached, and long updates are not cut short or sent twice. If a dashboard is blocked before its first request gets through, add its IP once under Settings, in the Shield WAF trusted IP whitelist. UpdraftCentral sends commands from your browser by default, so the IP it learns is yours and expires after 7 days.

To avoid a CPU spike on servers that host many sites. Updates pushed from a dashboard, by WordPress auto-updates or by WP-CLI give each site its own fixed slot of up to 5 minutes, and at most two sites on one server deploy at once. Updates you click in a site's own admin deploy straight away. Developers can change the window with the wpbc_stagger_window filter and the per-server limit with wpbc_server_deploy_slots.

So the site is purged once, after all the updates have finished, instead of after every single plugin or theme. A dashboard update usually arrives as several separate requests, and each one used to empty the CDN, so the server rebuilt every page several times. Updates pushed from a dashboard also wait for the site's own slot, so the sites on one server do not all purge in the same minute. Updates to admin-only plugins (this plugin, remote management connectors, backup plugins) do not purge at all. Developers can change the wait with the wpbc_update_purge_delay filter and the skipped plugins with wpbc_no_purge_plugin_folders.

Both are covered by edge rules since versions 1.0.6 and 1.0.7. Update the plugin and the rules redeploy automatically. If an Author or another role uploads media, add that role to the WAF bypass roles in Settings.

Some cache plugins send Cache-Control: max-age=0 to Bunny, which tells Bunny not to cache. Force Cache mode overrides this on your pull zone so Bunny caches HTML for the TTL you set, whatever the origin sends.

Yes. Enable Perma-Cache cleanup in Settings and enter your Bunny Storage zone details. After every full purge the plugin deletes stale Perma-Cache files so visitors always get fresh content.

In the Bunny.net dashboard, go to Account > API and use the Account API Key, not a pull zone access key. The account key is needed to manage edge rules and list pull zones.

Bunny allows 5 URL patterns per rule trigger. Rules that cover many paths or file types are split into batches of 5, and each batch is a separate rule. The suffix shows which batch you are looking at.

Batched rules each take several slots, and some rules are added only when a matching plugin is active. On a site with www and non-www hostnames and several integrations, the count in Bunny is higher. The plugin tracks every rule and cleans up old batches when it redeploys.

Most LMS plugins publish courses and lessons as normal public pages that are safe to cache. Only per-user pages (student dashboards, checkout, registration, account) need a bypass, and the plugin makes this distinction for each LMS.

Yes. Security plugins work at the request or firewall layer and are fully compatible. See the Integrations tab for the complete list.

Not as a CDN. NitroPack runs its own CDN, and using NitroPack CDN and Bunny CDN together creates a double-CDN conflict.

Yes. See the Developer hooks section above and the API tab inside the plugin for filters, actions, REST endpoints and examples.

Yes. Visit wpbunnyconnector.com/support to request a plugin check.

The API key is stored in the WordPress options table, or in wp-config.php if you define it there. It is never printed in the page, never sent to the browser and never included in an AJAX response. It is only sent in request headers to the Bunny.net API. Every admin action requires a valid nonce and the manage_options capability.