Nivoli Edge docs

How it works

Nivoli Edge has two halves that share one plugin and, on managed plans, one license key:

• Images: the plugin hooks WordPress's native image pipeline (wp_get_attachment_image_attributes, wp_calculate_image_srcset, and optionally the_content plus a full page scan) and rewrites image URLs through Cloudflare Image Resizing. Variants are created on the fly from your originals: right-sized, format-negotiated (WebP/AVIF), never stored twice.
• Pages: every cacheable page response carries Surrogate-Key / Cache-Tag headers (post-N, category-N, author-N, home…). When content changes, the plugin dispatches a purge listing only the affected tags, so exactly the right pages evict and the rest of the cache stays warm.

Quickstart: managed (recommended)

No Cloudflare account, plan, or DNS work.

1. Install and activate the plugin.
2. Open Nivoli Edge → Managed Edge → License and paste your key (it arrives by email the moment checkout completes; every plan starts with a 14-day free trial). Activation provisions a CDN tenant and fills the rewrite settings in automatically.
3. For page caching, paste your dashboard URL from the welcome email under Settings → Page cache.
4. The Dashboard's pipeline check should read ✓ working. Done.

Quickstart: self-hosted (free)

Images need a Cloudflare zone with Image Resizing enabled on the host that serves them (bundled with Cloudflare Pro plans, or pay-per-1000):

1. Proxy the image host through Cloudflare (orange cloud) and enable Speed → Optimization → Image Resizing.
2. Verify with any image: https://yoursite.com/cdn-cgi/image/width=200/wp-content/uploads/….jpg must serve a resized image. A 404 or error 9421 means Image Resizing isn't on.
3. In Nivoli Edge → Settings, confirm the auto-detected image host + path prefix and toggle Enabled.
4. Open Image rules → Size mapping and click once to create rules for your theme's registered sizes. The catch-all covers everything else.

Pages need a tag-aware edge you already run: pick Fastly, Cloudflare Enterprise, or a custom webhook under Settings → Page cache and supply the token. The plugin verifies the token actually has purge permission at setup time.

Image rules & presets

Every rewrite goes through a preset, a named recipe of width, height, fit, format, quality, and srcset behavior. Presets attach to images via bindings:

Size mapping creates presets + bindings from your theme's registered sizes in one click. Inline content, CSS backgrounds, and lazy-load data attributes are covered by the content scan toggles under Settings → Behavior.

Page caching & purging

# Every page response carries the tags it was built from
Surrogate-Key: post-42 category-7 author-3 home

# One post save → one surgical purge
POST /purge  { "keys": ["post-42", "category-7", "home"] }

Purges dispatch non-blocking on save, delete, and comment events, so editing never waits on a CDN round-trip. The purge activity log lives under Diagnostics → Page cache; prewarm-after-purge re-fetches affected URLs ~45s later so the next visitor hits a warm cache. Theme and plugin developers can add tags via the nivoli_edge_pc_keys_for_request / nivoli_edge_pc_keys_for_post filters.

Audits & repair tools

• Coverage audit: scans content and measures the optimized share, with one-click "create rule" links for anything uncovered.
• Runtime misses log: images that matched the path prefix but no rule at serve time, grouped into patterns.
• Fake-image scan & repair: finds files with an image extension whose bytes are actually HTML (old CMS error pages), and swaps the content for a placeholder while keeping the path and a .orig backup.
• Tinify compression: shrink originals in place with your own TinyPNG/Tinify API key; every change keeps a restorable backup.
• Client report: a printable, brandable delivery report; fills with live edge numbers on managed plans.

Automation & alerts

• Weekly scheduled audit emails you when coverage regresses.
• Purge-failure alerts: a daily sweep of the purge log emails when dispatches keep failing.
• Weekly header self-test: fetches your own site with trace mode and verifies tag headers still emit after theme/plugin changes.
• Pre-warm on save: parallel HEAD requests warm new image variants the moment you publish.

Debugging

WP-CLI

# status of both halves
wp nivoli-edge status

# activate a license / enable optimization
wp nivoli-edge activate <key>
wp nivoli-edge enable

# run the coverage audit / probe the pipeline / purge tags
wp nivoli-edge audit
wp nivoli-edge probe
wp nivoli-edge purge post-42 home

Built for agency provisioning: every setup step scriptable, exit codes are meaningful.

The managed service

A license key connects the plugin to the Nivoli edge, which runs both halves for you and adds what a plugin alone can't. Everything below lives in WP admin under Managed Edge; metrics are cached for an hour and served instantly, with a Refresh data link in the rail when you want live numbers.

Origin Shield

Always on, nothing to configure. When your server errors or stops responding, the edge serves the last good cached copy of every page for up to 7 days. You get an email when the shield engages and another when your origin recovers (switchable under Email & reports). The Origin shield pane keeps an incident history with honest durations; scattered single-request errors are counted separately as blips, not stitched into fake outages. "Not covered" requests are pages nobody had visited recently: a higher cache hit rate widens the shield.

The edge security suite

All enforced at Cloudflare's edge, before a request reaches PHP; they complement Wordfence/Sucuri rather than replace them. The Edge shields pane opens with an attack-surface strip: XML-RPC blocked vs reached, logins stopped, AI crawlers and wp-admin hits blocked, over the last 14 days.

• XML-RPC block (all plans): answers /xmlrpc.php with a cached 410.
• Login country lock (all plans): wp-login.php limited to the countries you list; everyone else gets a 403 at the edge. Continent quick-add buttons included; keep a country you can always reach.
• Security headers pack (all plans): one switch adds HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a conservative Permissions-Policy; your own header values always win. No CSP by design.
• Login rate limiting (all managed plans): 10 attempts per 10 minutes per IP; brute-force runs get a cached 429. Self-healing, you cannot lock yourself out.
• wp-admin IP lock (Growth+): /wp-admin restricted to your IPs/CIDR ranges (one per line), with a self-lockout guard and an email self-rescue flow on the 403 page. admin-ajax.php stays open.
• AI-crawler block (Growth+): GPTBot, ClaudeBot, CCBot, Bytespider, Google-Extended, PerplexityBot and friends get a 403; verified search engines are never affected.
• Geo control (all plans): allow or block countries per path via URL rules.
• Stray-PHP lock (all managed plans): every direct .php request except the real WordPress entry points gets a cached 404. Monitor mode lists what it would have stopped before it stops anything.
• WordPress surface lock (all managed plans): user enumeration (/wp-json/wp/v2/users, ?rest_route=/wp/v2/users, ?author=N) and leftover files (readme.html, license.txt, the installer, debug.log) get a cached 404 for anonymous visitors. Logged-in sessions pass. Off, monitor or block.
• Change lock (all managed plans): once on, every token-gated change that weakens protection (a shield off, block to monitor, the purge allowlist, the wp-admin IP list, a URL rule removed or loosened, the lock itself) is refused with a 423 and stored as a pending change; the license email (the address your license key went to) gets a link that applies exactly that change, once, within 30 minutes. Nothing happens until the link is clicked, and the same change asked twice within a minute sends one mail. Turning shields on never needs it. The address is held at the edge, so a compromised WordPress cannot redirect it; console sessions are not gated because signing in already proved that address.
• Origin lock (all managed plans, plugin 1.56.0): a per-site secret held at the edge and in the plugin. The edge stamps it on every request it forwards; the plugin, first thing on every request, answers code-change paths (installs, updates, uploads, the editors, plugin activation, the REST plugins route) that lack it with a 403 and an X-Nivoli-Origin-Lock: refused header. Requests that came through the edge carry it, so nothing changes for normal use; a request straight to the origin does not. The weekly self-test probes the server's own loopback and the Locks page says whether the check is enforced. Turning it off at the edge is a confirmed change; the secret is never in a URL.
• Install lock (all managed plans): wp-admin requests that change code (plugin and theme install, upload, update, delete; the file editors; the REST plugins endpoint) are refused with a 423 page unless the same 15-minute window is open. The page carries an "Email me the confirmation link" button, so the lock stays on and you confirm when you actually want to install something. Store installs use the same endpoints as uploads. Automatic updates (wp-cron on the server) and WP-CLI never pass through the edge and are unaffected. The Locks page in the plugin lists what was refused (by action and plugin or theme slug), can open the same 15-minute window by email and close it early, and keeps a lock activity log: unlock requests, clicked links, confirmations, lock changes, each with time and requesting address.
• Comment and search flood limits (all managed plans, two switches): 5 posts to wp-comments-post.php per 5 minutes per IP, 30 ?s= searches per 5 minutes per IP; over the line is a 429 with Retry-After, never cached.

Underneath all of them: every managed site is a custom hostname on a Cloudflare zone with the managed WAF rulesets enabled, including the WordPress rule set that virtual-patches known plugin vulnerabilities, and Cloudflare's network absorbs volumetric attacks before they reach the edge worker or your server. The shields above are what Cloudflare does not know to do for WordPress on its own.

Hardening: what runs where, and what survives a takeover

The question that matters for a security control is not what it stops but where it lives. A control inside WordPress stops working the moment WordPress is owned. Everything in the first group below runs at the edge and is configured at the edge, behind an email confirmation to the license address, so a compromised site can neither reach it nor switch it off.

The origin side door. Every edge control applies to traffic that reaches the edge. Anyone who knows the origin's IP address, its hosting-panel hostname, an unregistered www or apex twin, or a staging vhost on the same docroot can talk to WordPress directly and none of the shields or locks apply. Three things close it, in order of strength: the origin lock (plugin 1.56.0): the edge stamps a per-site secret on every forwarded request and the plugin refuses code-change requests without it, and its weekly self-test reports whether the server really enforces it; an origin firewall that accepts port 443 only from Cloudflare's address ranges; and Authenticated Origin Pulls, where the origin requires Cloudflare's client certificate. Do the first today; do the second if you control the server's firewall.

What no edge control can do: undo a compromise that already has code execution on the server. The locks stop it from extending through WordPress tooling and from silencing the shields, and every attempt reaches the license address as the confirmation email, which is how you find out. Restore from a clean backup remains the answer to an owned box.

Audience analytics

On Stats & overview: human pageviews vs bots (14 days), visitors per day, top referrers, visitor countries, devices and regions, plus served-from-cache timing vs your origin's render time. Measured entirely at the edge from traffic you already serve: no tracking script, no cookies, no consent banner needed, and no visitor-level data is ever stored. A monthly audience digest rides along with the stats email.

URL rules and the 404 cleanup inbox

URL rules block dead routes with a cached 410 or redirect moved pages with a 301/302, straight from the edge, with per-rule hit counts and a what-was-blocked log. The Redirects pane carries a suggestions inbox: the edge watches which URLs 404 against your origin and proposes block/redirect rules (with guessed targets) that you apply in one click. URL rules live under Security in the rail, because blocking is how the pane is used. The Redirects pane keeps the one-to-one mappings: it shows which redirects actually fire, folds unused ones away, and when a migration leaves a family of one-offs that differ by a number, proposes the single pattern that covers them all and merges them in one click.

Edge controls

The rail groups the panes that decide what the edge keeps, separately from the panes you read daily:

• Cache duration: per-path lifetimes (TTL), so /news/ can expire in minutes while /about holds for a week. Stale-while-revalidate serves the old copy instantly while the edge fetches the new one.
• Query params: junk query strings (utm_*, fbclid, and unknowns) collapse into the cached page instead of splitting the cache, while functional params keep working.
• Cache protection: purge triggers locked to your own IPs, plus the exact snippet to stop an origin micro-cache (nginx fastcgi, Varnish) fighting the edge.
• Speculative loading: a Speculation-Rules response header points Chrome at a small rules file served from the edge, so your HTML is never modified. On hover, the browser prerenders the target. Because a prerender executes the target page's JavaScript, action links are excluded: the paths the cache bypasses, anything carrying add-to-cart, remove_item, wc-ajax, action or _wpnonce, and WooCommerce's own button classes. A link carrying a nonce is an action, not a page. Those exclusions are query params and CSS classes rather than page names, so they hold whatever language the store runs in. Visitors who are logged in or carrying a cart are never sent the rules, since their requests bypass the cache and every speculation would be a full origin render. Any link can also be opted out with a no-prerender class, and links marked rel="nofollow" are skipped. One limit worth knowing: the rules file is the same for every site, so a bypass pattern you add yourself is honoured by the cache but not by these rules; use the class, or have the plugin mark the page uncacheable. Off by default. The pane reports how many browsers fetched the rules (they cache it for an hour, so it is a floor on reach rather than a page-view count) and what share of speculated requests reached the origin instead of cache. It reports no activation rate: an opened prerender makes no new request, so the edge cannot see it, and we would rather say so than invent a number.
• Dynamic content: cart, checkout and account pages, plus any visitor carrying a WooCommerce cart or session cookie, bypass the cache. This is a floor rather than a setting, so a store is protected even with no plugin installed. Those are the default slugs; a renamed or translated one (/winkelwagen, /kassa) is covered instead by the plugin marking those pages no-store, which is the only layer that knows what they are actually called.

The same pane reports what your origin's own Cache-Control is doing. no-store is always obeyed, with no setting, because it is plain HTTP correctness and it is what makes the translated-slug case work. no-cache and private are softer (no-cache means "revalidate", not "never store", and themes emit both carelessly), so the edge counts them from day one and stops caching them only when you switch to Enforce. Switching also purges what is already stored, since a page cached before the switch would otherwise keep being served. An enforced directive reports as BYPASS rather than MISS, so an uncacheable page cannot show up as a fake 0% hit rate. Counts for a merely measured directive are a floor: the response is still cached, so only the requests that reach your origin carry a marker.

Reporting is available on every managed plan, because it is diagnostic. Switching to Enforce is gated like the other advanced controls (Growth+); returning to measure never is.

Static assets and asset URL versioning

Stylesheets, scripts and fonts are answered by the edge node nearest each visitor, with the browser lifetime your server already sets left exactly as it is. The Static assets pane reports that population on its own, images excluded (images run through the image pipeline and are reported on the Dashboard): the edge hit rate, the share of requests on versioned addresses, distinct files, bandwidth the origin did not serve, a per-type table (stylesheets, scripts, fonts, other), your most-requested files that still travel on plain addresses, and the files your server marks no-cache, private or Set-Cookie so the edge must fetch them every time.

Asset URL versioning (every managed plan, off until you switch it on) gives every stylesheet, script and font an address that changes when you purge. A purge clears the edge's copy; a browser that already holds a file keeps it until its own timer runs out, and no purge can reach it. With versioning on, the next page load references new addresses, so browsers pick up changed files immediately. The rewrite happens at the edge on the way out: your files and the HTML on your server are untouched, and a file keeps its plain address only when its URL appears solely inside a stylesheet or script (the rewriter reads pages, not those files), when the page referencing it was cached before the last purge (resolves itself as pages re-render), or when that page was too large to rewrite. Purge cache now on the same pane moves every asset to a new address at once.

Client reports and the agency console

The printable client report (Tools) is white-label: your name and logo, no vendor branding. On Business+ the monthly delivery report can also email itself to up to 3 recipients under your brand (Email & reports → Branded client reports), and each site can additionally send its own numbers to its own client.

Fleet management lives in its own console at console.nivoli.com, outside WordPress, so you do not sign into a client's site to see how the fleet is doing. Sign-in is by magic link to your account email, with no password to share around a team. The Overview carries four things:

• Needs attention: failures ranked above cosmetics. Red for failed image requests in 48h, 10 or more origin errors in 24h, or pages the edge served stale to cover downtime. Amber for a page hit rate under 40% on a site with real cacheable volume, plus one security-gaps summary across the fleet. Idle sites are excluded instead of nagging. Each item links straight to the pane that explains it.
• Fleet totals: sites (active vs idle), pages served over 7 days with the share answered at the edge, bandwidth offloaded, and attacks blocked over 14 days (XML-RPC, logins, AI crawlers and admin-lock hits together).
• Security posture: a matrix of every site against every shield and lock: headers, XML-RPC, login rate limit, comment and search flood limits, country lock, AI block, admin IP lock, stray PHP, surface lock, change lock, install lock, origin lock. A tick means applied, a dot means a fixable gap, and a dash means an optional per-site choice that is never counted as a gap (the three locks and the country and admin IP locks change how the owner works, so they are never gaps). Stray PHP counts as a gap while the shield is off or only monitoring, because monitoring blocks nothing. "Fix gaps" opens that site's Security tab.
• Fleet actions: purge every site's HTML at once, or apply the security baseline (hardened headers, XML-RPC 410, login rate limit, the two flood limits and the surface lock in block mode) across the fleet in one click. The login country lock is deliberately excluded from the baseline, since the right countries differ per site.

The Sites table lists page hit rate, bandwidth and 48-hour failures per site, with Manage into that site's dashboard, a per-site purge, and a direct WP admin link.

What unlocks where

Matching what the server actually enforces:

• Every managed plan: managed CDN + page cache, Origin Shield, the eight attack shields (security headers, XML-RPC block, login country lock, login, comment and search flood limits, stray-PHP lock, WordPress surface lock), the change lock, install lock and origin lock, geo control, URL rules + 404 inbox, edge analytics, reports and alerts.
• Growth+: AI-crawler block, wp-admin IP lock, enforcing origin cache directives, white-label image hostname, edge watermarking.
• Business+: multiple sites on one key, the agency console (needs-attention list, security posture matrix, fleet purge, security baseline), automatic branded client reports.
• Agency: pooled transform allowance across all client sites, priority support.

FAQ

Will this break my theme?

No. Only URLs change, at the filter boundary. The HTML structure is untouched, and no-cf opts any element out.

How is this different from Smush / ShortPixel / Optimole?

Those compress and re-host your images on their CDN. Nivoli Edge transforms on the fly from your origin: no duplication, no migration, no storage bill.

I run a membership site or an LMS. Is this for me?

Partly, and here is the honest split. Everything public is cached and shielded normally: your sales page, catalog, pricing and blog, which is usually where most of the traffic and all of the signups are. Security before PHP, image delivery, edge analytics and surgical purge apply to every visitor, signed in or not. But a logged-in member's page views are not cached, so they get no edge time to first byte and no outage coverage. We have not built per-user cache buckets or edge-side includes. If the pages that need to be faster are the ones behind the login, better hosting or an origin-side cache will move that number and we will not. The fuller version is here.

Does this replace WP Rocket, FlyingPress or NitroPack?

No, and it does not try to. Those own the render path: minification, critical CSS, unused-CSS removal, script deferral, lazy loading, font handling. Nivoli Edge ships none of that. We answer the request from the node nearest your reader, keep the site up when your server stops, block junk before PHP starts, and measure all of it at the edge. Keep your optimizer and run both; they touch different layers. If you are comparing PageSpeed scores alone, an optimizer is the tool that moves them. If your problem is time to first byte, outages, scanners or not knowing what your edge actually serves, that is this.

Does the page caching conflict with Wordfence / Sucuri?

No, these are different layers. Security plugins inspect requests inside PHP; the edge shields stop junk before it reaches your server. They complement each other.

Do I need to change my web-server config?

Only if your origin runs its own micro-cache (nginx fastcgi cache, Varnish) and you use the manual purge trigger; the Cache protection pane shows the exact snippet. A standard PHP-FPM origin needs nothing.

What happens if I cancel a managed plan?

The plugin reverts to serving originals from your own server. Your site stays up; the free feature set keeps working.

Privacy & external services

The free tier's core rewriting contacts no external service. Opt-in integrations: the Nivoli managed edge (license verification + usage stats; no visitor data), Cloudflare / Fastly APIs (only with your own tokens, for purges), and Tinify (only images you explicitly compress, with your own key). Full details in the plugin readme, Terms, and Privacy Policy.