Global Edge Deployment

A shopper in Tokyo shouldn't pay for a server in Frankfurt. Deploy as a fleet of edge nodes anywhere in the world. Your single Magento backend stays where it is.

Accelerate Guru is designed to run as a distributed fleet. Each node is a full, independent edge: it terminates TLS, serves the cache, applies WAF rules, encodes images, and handles all client-facing traffic. The single Magento server — which can be in any country — is the origin of truth, but most requests never reach it.

#The problem with single-region Magento

A Magento server in Frankfurt serves pages to visitors in Tokyo in roughly 250–300 ms of network latency alone, before any PHP or MySQL work. Even with an excellent cache hit rate at the origin, the visitor still waits 300 ms just for the TCP handshake.

With a CDN, you can push static assets closer to visitors, but HTML pages typically cannot be edge-cached by traditional CDNs because they don't understand Magento's personalisation signals (customer groups, store views, X-Magento-Vary).

Accelerate Guru solves this correctly:

Each regional node understands Magento's cache segmentation.
It can cache and serve full HTML pages — not just assets.
It handles TLS termination, WAF, image encoding, and all optimisations locally.
Only genuine cache misses (the first visit to a URL variant) travel to the Magento origin.

#Architecture

                        ┌─────────────────────────────────┐
                        │     Magento + DragonflyDB       │
                        │     Frankfurt (origin)          │
                        └──────────────┬──────────────────┘
                                       │  cache misses only
                      ┌────────────────┼────────────────┐
                      │                │                │
              ┌───────┴──────┐ ┌───────┴──────┐ ┌──────┴────────┐
              │  Edge Node   │ │  Edge Node   │ │  Edge Node    │
              │  São Paulo   │ │  Singapore   │ │  New York     │
              │  AG + Dragon │ │  AG + Dragon │ │  AG + Dragon  │
              └──────────────┘ └──────────────┘ └──────────────┘
                     │                │                │
              BR visitors      APAC visitors     US visitors
              TTFB: ~5 ms      TTFB: ~4 ms      TTFB: ~3 ms

Each edge node:

Has its own DragonflyDB instance.
Caches pages independently (cache is NOT shared between nodes by default).
Handles all traffic from its geographic region.
Only contacts the Magento origin for cache misses.

#What percentage of requests skip the origin?

After the initial cache warmup period (typically a few hours of live traffic), expect:

Phase	Origin contact rate	Notes
First hour	80–90%	Cache is being populated
After warmup	5–15%	Ongoing: only misses, crawlers, cache expirations
With warmup sitemap	2–8%	Cache pre-populated at startup
With MySQL proxy	< 5%	Invalidation is surgical; pages rarely expire

For a store with 50,000 daily visitors distributed globally, the origin server might receive fewer than 5,000 requests per day — the rest are served from regional DragonflyDB instances.

#Step-by-step: adding a second edge node

#Prerequisites

A VPS or server in your target region (any Linux distribution, 2 GB RAM minimum, 20 GB disk for image cache).
DragonflyDB installed on the new server (see DragonflyDB Setup).
Your magento_ultra.ini from the primary node.
DNS updated to route regional traffic to the new node (see DNS routing strategies below).

#Step 1: Install on the new server

curl -fsSL https://accelerate.guru/install | sudo sh

#Step 2: Copy your configuration

# From your primary server, copy the config
scp -r /etc/accelerate-guru/ user@new-server:/etc/accelerate-guru/

#Step 3: Update `upstream_addr`

The new edge node is in Singapore; your Magento is in Frankfurt. Update upstream_addr to the Magento server's public or private IP:

[server]
upstream_addr = 185.0.0.1     ; Frankfurt Magento server's IP
upstream_port = 8080

Tip

If your Magento server is in a VPC, use the private IP of the Magento server. Otherwise, use the public IP and ensure the Magento server accepts connections from the edge node.

#Step 4: Use the same license key

The same license key works on all nodes serving the same hostname(s). No additional activation is needed.

#Step 5: Start the service

sudo systemctl enable --now accelerate-guru

The new node is now live. Test it directly by setting a Host header:

curl -H "Host: yourstore.com" https://<new-server-ip>/ -k -I

#DNS routing strategies

#Option A: GeoDNS (recommended for production)

Configure your DNS provider to return different IP addresses based on the visitor's geographic location:

yourstore.com A 185.0.0.1   ; Frankfurt (Europe)
yourstore.com A 203.0.113.1 ; Singapore (Asia-Pacific)
yourstore.com A 198.51.100.1; New York (Americas)

GeoDNS is available from Cloudflare, AWS Route 53, Google Cloud DNS, and most modern DNS providers. Visitors are automatically routed to their nearest node.

#Option B: Anycast (for maximum resilience)

Use a BGP anycast IP address announced from all edge locations simultaneously. Visitors are automatically routed to the nearest node at the BGP routing level. This requires your own ASN and IP space, or a provider like Cloudflare or Vultr that offers anycast.

#Option C: Regional subdomains

For simpler deployments, use country-specific subdomains:

eu.yourstore.com → Frankfurt edge
ap.yourstore.com → Singapore edge
us.yourstore.com → New York edge

Combined with domain masking, each subdomain can display the correct language, currency, and content for its region.

#Cache warming on new nodes

A new edge node starts with an empty cache — the first visitor to each URL triggers a cache miss. To pre-warm the cache after deployment:

[mysql_proxy]
warmup_sitemap     = https://yourstore.com/sitemap.xml
warmup_concurrency = 8

At startup, the new node fetches all URLs in the sitemap and stores them in its local DragonflyDB. Visitors arrive to a warm cache.

Note

The warmup process fetches pages through the new edge node's connection to the Magento origin. Ensure upstream_addr points to the correct origin before starting the warmup.

#Optional: shared cache across nodes

By default, each edge node caches independently. This means a cache miss on the Singapore node always goes to Frankfurt, even if New York already has the page cached. For most stores, this is acceptable — the miss rate is already low, and Frankfurt can handle the few misses easily.

If you want to share the cache across nodes (so a cache miss on one node can be served by another), you can:

Run DragonflyDB in a central location (e.g. near the Magento origin) and point all nodes at it.
Use DragonflyDB replication (experimental) to keep multiple instances in sync.

The simplest approach for most deployments is independent caching with a shared origin.

#Practical example: e-commerce with global reach

A Brazilian fashion retailer has:

Magento in São Paulo (existing infrastructure, large database, can't move it).
Growing sales in Mexico, Colombia, US, and Europe.

Without Accelerate Guru fleet: all traffic goes to São Paulo. A visitor in New York experiences 150 ms of round-trip latency before a single byte is sent.

With a Accelerate Guru fleet:

Location	Server cost	TTFB	Cache hit rate after warmup
São Paulo	~$40/mo VPS	3 ms	90%
New York	~$20/mo VPS	2 ms	88%
Amsterdam	~$20/mo VPS	2 ms	87%

Total infrastructure cost: ~$80/mo. A New York visitor's TTFB drops from 150 ms to 2 ms on cache hits. The São Paulo Magento server now handles only ~10% of total traffic — its load drops dramatically and it serves its remaining requests faster because there is headroom.

#Security in a multi-region fleet

Each edge node runs its own WAF independently. Blocked IPs on one node are not automatically shared with other nodes (each node has its own in-memory runtime blocklist from blocklist.ini).

To share blocklist updates across all nodes:

Maintain a single blocklist.ini file in a shared repository.
Deploy changes to all nodes via your infrastructure automation (Ansible, Terraform, etc.).
The file is hot-reloaded on all nodes within 500 ms of being written.