Architecture

Edge Caching runs as a cluster of edge nodes managed by Docker Swarm. Every request passes through the same chain of components before it reaches your origin, and each site has its own isolated cache.

Request path

1. DNS and load balancing

Your site’s records point to the platform’s load balancer. The load balancer forwards TCP connections on ports 80 and 443 to the edge nodes using the PROXY protocol, so the original client IP address is preserved through the whole chain. It is the address used by the firewall, shown in live logs and sent to your origin in X-Forwarded-For.

2. Traefik: TLS and routing

Traefik runs on every edge node and terminates TLS. Certificates come from Let’s Encrypt (issued once DNS points to the platform, then renewed automatically) or from a certificate you upload.

Traefik also:

• redirects HTTP to HTTPS when TLS is enabled for the site;
• applies your preferred domain version, redirecting www to the bare domain or the reverse;
• redirects alias domains to the primary domain;
• adds Strict-Transport-Security with a one-year max-age, includeSubDomains and preload on HTTPS responses.

HSTS applies to subdomains

Because HSTS is sent with includeSubDomains, browsers that have visited your site over HTTPS will refuse plain HTTP connections to any subdomain of it for a year. Make sure every subdomain you use serves HTTPS before enabling TLS.

3. CrowdSec: firewall

Every HTTPS request is checked by the CrowdSec bouncer before it is routed:

• IP decisions. The client IP is checked against active bans: IPs banned by the platform’s own detection and IPs from CrowdSec’s community blocklist. The bouncer keeps a local copy of the decision list, refreshed every 15 seconds, so the check adds no network round trip.
• Request inspection. The request is also evaluated by CrowdSec’s AppSec engine, which applies virtual patching rules for known vulnerabilities and generic attack signatures. Matching requests are rejected with a 403.
• Behavioral detection. Traefik’s access logs are analyzed continuously. Clients matching attack scenarios, such as WordPress login brute forcing, XML-RPC abuse or vulnerability scanning, are banned platform-wide.

The AppSec check fails open: if the inspection engine is unavailable, requests are allowed through rather than blocked, so a firewall problem never takes sites offline. Your origin’s own IP address is automatically exempted from bans, so plugins that call back into their own site (such as Jetpack) cannot get the origin blocked. How CrowdSec protects you covers detection, decisions and enforcement in depth.

4. Varnish: per-site cache

Each site has a dedicated Varnish Cache instance running as its own Swarm service, with its own memory allocation sized by your plan. One site’s traffic can never evict another site’s cached pages.

The site’s VCL, generated from your settings, runs on every request:

1. Geo blocking rejects requests from blocked countries.
2. Bypass rules send requests straight to the origin: logged-in or WooCommerce cookies, /wp-admin, /wp-json/, cart and checkout pages, and anything else you configure.
3. Site firewall rules reject the rest of the unwanted traffic: XML-RPC, blocked or empty user agents, sensitive files, PHP execution in uploads and author enumeration.
4. Normalization removes cookies and tracking parameters such as utm_*, gclid and fbclid, so they don’t fragment the cache.
5. Cache lookup: a hit is returned from memory. A miss is fetched from the origin and stored if cacheable. Non-GET requests are always passed.

What gets cached lists every rule in the exact order it is applied.

Every response carries an X-Cache header (HIT or MISS) so you can see how a request was served.

5. Origin connection

On a miss or a pass, Varnish connects to your origin’s IPv4 address on port 443 over TLS. It sends your domain both as the TLS SNI name and as the Host header, so the origin serves the right site even on shared hosting. Certificate verification is disabled on this hop, which lets origins use self-signed certificates.

Timeout	Value
Connect	5 seconds
First byte	60 seconds
Between bytes	10 seconds

6. Response handling

Successful responses (200) and redirects (301, 302) are cached for one hour, unless the origin marks them no-cache, no-store or private. Set-Cookie headers are removed from cacheable responses so a session cookie is never shared between visitors. 404 responses are not cached.

When Always Online is enabled, expired responses are also kept for a grace period (24 hours by default) and served if the origin fails. Server errors from the origin produce a maintenance page, or the stale copy when one is available. See When your server is down for the complete behavior.

Control plane

Configuration changes

The admin panel turns your settings into two things:

• VCL for the site’s Varnish instance. It is distributed as a Swarm Config and loaded into the running instance with vcl.load and vcl.use. Changes take effect immediately, with no restart and no loss of cached content.
• Routing labels on the site’s Swarm service, which Traefik reads to build its routes and certificate requests. Changes to domains, aliases or TLS roll out with a start-first update, so the site stays reachable.

Invalidation

Purges use Varnish bans. When the WordPress plugin reports a change, it calls the purge API with the site’s API key, and the admin panel issues a ban on that site’s Varnish instance: either for the specific URLs affected, or for everything. Banned objects are dropped immediately, including copies kept for Always Online. How the cache is refreshed covers what this means for visitors and for your origin.

Monitoring

Varnish counters (hits, misses, bandwidth, objects in cache) are collected from each instance every minute. Traefik exports request metrics to Prometheus, and its access logs feed both the firewall’s behavioral detection and the per-site traffic statistics. When Always Online is enabled, a health probe requests the site’s homepage every 10 seconds; it drives the origin status shown in the admin and the origin down alerts.

High availability

Traefik runs on every edge node, so the load balancer can send HTTPS traffic to any of them. Each site’s Varnish service can run on any node and is reached over the cluster’s overlay network. Certificates are issued centrally and synchronized to every node, so any node can terminate TLS for any site.