CacheHaul

Caching and delivery acceleration for your site

Cacheable requests are answered by edge nodes near the visitor, and an origin shield keeps the rest of the load off your servers.

Request access Sign in

How a request is served

A hit never leaves the edge; a miss is collapsed by the shield before it reaches your server.

Visitor browser Edge nearest node Origin shield one fetch Origin your server request miss fetch hit, served at the edge

Edge nodes

A request is routed to the node closest to the visitor and terminated there, so round trips stay short. Hits never travel to the origin.

Origin shield

A shielding tier between the edge and the origin collapses concurrent misses into a single upstream fetch, and keeps serving the last good response while the origin is unreachable.

Rules and purge

Match on path, query and request headers to decide what is cached and for how long. A purge by path or prefix clears the edge without waiting for entries to expire.

Everything over the API

Zones, rules and purges use the same endpoints as the console. Tokens are scoped per zone, so a deploy pipeline carries only the rights it needs.

Purge from a deploy step

Release the build, then clear the paths it replaced. The call returns as soon as the purge is accepted; propagation across the edge continues in the background.

Request

curl -X POST https://app.cachehaul.com/api/v1/zones/z8f31ca/purge \
  -H "Authorization: Bearer $CACHEHAUL_TOKEN" \
  -d '{"paths": ["/static/app.css", "/img/*"]}'

Response

{
  "purge": "pg41d9b0",
  "state": "propagating"
}

CacheHaul is in a private beta. Access is granted per workspace while the onboarding queue is kept short.

Request access