CDNShark vs Fastly: Programmable Edge vs Bundled Platform

Fastly and CDNShark are not really competing for the same buyer, and pretending otherwise would waste your time. Fastly is a programmable edge platform built for engineering teams who will write VCL and WebAssembly. CDNShark is a self-serve platform for people who want a CDN, DNS, storage, and tunnels on one bill. This post is about where the technical lines actually fall.

Price is the first-order difference

Figures as of August 2026.

Fastly's per-domain TLS charge deserves a second look, because it catches people out. Six domains on Fastly is $20/month before a single byte moves. Sixty domains is $1,100/month in certificates alone. CDNShark issues certificates for every domain on the plan at no additional charge.

None of which makes Fastly overpriced. It makes Fastly priced for what it is.

Programmability: the gap is total, not incremental

Fastly gives you VCL at the edge and Compute, its WebAssembly runtime, so you can run real application logic in the request path — rewrite, authenticate, assemble responses from multiple origins, A/B split, whatever you can compile.

CDNShark has no edge compute at all. What it has is a declarative rule set evaluated by Lua against a JSON config document:

Fastly                          CDNShark
------                          --------
request                         request
  |                               |
  v                               v
VCL: vcl_recv                   cdn_router.lua reads site:{host} from Redis
  |  arbitrary logic              |
  |  restarts, multiple           |  match_type: ext | prefix
  |  backends, shielding          |  action:     ttl | redirect
  v                               |  plus: geo_mode, ip_mode, waf_mode,
Compute (Wasm)                    |        rate_mode, cors_mode, hotlink_mode
  |  Rust / JS / Go               |
  |  full program                 v
  v                             fixed decision, no user code
response                        response

If your requirement is "run our code at the edge," CDNShark is not a candidate. Cache rules by file extension or path prefix, 301 redirects, CORS policy, geo and IP allow/block lists, four rate-limit modes, hotlink protection and origin selection is the whole surface.

Purging: durable versus instant

Fastly's instant purge is one of its genuine engineering achievements — global invalidation in roughly 150 milliseconds, which is what makes it viable to cache HTML and purge on publish.

CDNShark's purge is durable rather than instant, and the mechanism is worth understanding before you design around it:

Every edge owns its own queue, so a purge is never lost to a restart or a worker that happened to be down — Redis holds the job until that specific edge pops it. The tradeoff is that invalidation is a filesystem scan across up to 37 GB of cache directories, so completion time scales with cache size and is measured in seconds, not milliseconds. It is the right design for durability and the wrong design for purge-on-publish HTML at Fastly's cadence.

Cache tiering and stale behaviour

CDNShark splits the edge cache into four zones with different retention:

Collapsed forwarding is on (proxy_cache_lock, 10s timeout, 3s lock age), so a thundering herd on a cold key produces one origin fetch rather than thousands. Stale content is served on origin error, timeout, or any 5xx. What CDNShark does not have is Fastly's origin shield — a designated mid-tier PoP that absorbs misses from every other PoP. With 11 edges each fetching independently, your origin can see up to 11 misses for the same cold object.

Network and protocol reality

Those first three rows are all verified against the live edges of both networks, not taken from documentation.

What CDNShark brings that Fastly does not

• Bundled authoritative anycast DNS on its own prefix (208.78.78.78, Technitium behind BIRD2), with the data plane on two further prefixes announced via separate transit — 208.78.78.79 and 208.78.79.79.
• Private origin tunnels. An origin with no public IP, no port forward, and no inbound firewall rule, reached over connector-initiated WireGuard.
• S3-compatible object storage on Garage clusters, in HDD, NVMe, and VOD tiers, with browser-direct presigned multipart upload.
• HLS video with FFmpeg transcoding, AES-128 segment encryption keyed per library, and signed playback tokens.
• Self-serve everything. No minimum, no package, no contract, no call.

Limitations, stated plainly

• 11 edge PoPs against Fastly's global footprint and vastly larger per-PoP capacity.
• No HTTP/3, Brotli, origin shield, edge compute, or instant purge. HTTP/2 is live as of August 2026.
• No real-time log tail; analytics land in ClickHouse and logs archive hourly.
• The WAF is a custom Lua ruleset in basic and strict modes — smaller and less comprehensive than Fastly's Next-Gen WAF, and not a CRS implementation.
• TLS terminates at the edge rather than at the anycast node that accepted the connection, which costs a round trip Fastly does not pay.

Who should pick which

Fastly if you will write VCL or Compute code, need instant purge to cache HTML, need origin shielding, need real-time observability, or need a footprint and capacity that CDNShark does not have. If you are already spending $1,500/month on delivery, you are Fastly's customer, not ours.

CDNShark if $0.12/GB and $20-per-domain certificates have made a modest workload expensive, if you want DNS and storage and tunnels on the same account, or if you need to serve an origin that cannot be exposed to the internet at all.

Fastly is a better CDN. CDNShark is a cheaper platform with a wider footprint per dollar and a much narrower one per PoP. Those sentences are both true and you should choose on which one describes your problem.