The Barbican CDN

What it is

The Barbican CDN is the first gate in front of every site Zipper hosts: before a request reaches the app, the gate checks whether it already holds a copy that is safe to reuse. Build assets are stored with the freshness Zipper already gave them — the gate never invents a lifetime. Private or no-store responses are never stored, signed-in sessions and live connections walk straight past the gate, and every response carries an X-Cache-Status header (HIT, MISS, or BYPASS) so you can see what happened. It sits at the edge of the Zipper network on this node — not a far-flung network of points of presence. When the gate is unsure, it fetches the origin instead of guessing.

Cloudflare analogue: CDN edge cache. SLA 99.99% · p99 30ms. Zipper operates the gate. Site owners read X-Cache-Status per response; nothing signed in is ever served from the cache.

• ▸Cacheable GETs answered at the gate
• ▸Private and no-store never stored
• ▸Websockets and sessions bypass
• ▸X-Cache-Status: HIT / MISS / BYPASS

How it works

The Barbican CDN is the cache gate in front of everything Zipper hosts on this node: before a request reaches the app, the gate answers with a stored copy when the response already declared itself reusable.

Freshness always comes from the app — build assets carry their immutable lifetime, and private or no-store responses are never stored at all.

Live traffic bypasses the gate — websockets and signed-in requests go straight through — and every response carries X-Cache-Status: HIT, MISS, or BYPASS.

Use cases

Concrete ways teams use this service on day one.

Set it up in the dashboard

Dashboard → Services → The Barbican CDN.

Read the four always-on controls: gate, header respect, live bypass, status header.

Check X-Cache-Status on any response to see HIT or MISS.

API

Control-plane: GET|PATCH /api/v1/services/barbican · /_next/static/:path* and /hosted/:id/:path* cache with X-Cache-Status · /api/* is never cached. Send Authorization: Bearer tz_live_YOUR_TOKEN.

Creates count against the plan quota. A 402 plan_limit means you are at the cap — upgrade or delete an unused resource.

curl -sSI https://tinyzipper.com/ | grep -i x-cache-status

const res = await fetch("https://tinyzipper.com/api/v1/services/barbican", {
  method: "GET",
  headers: {
    Authorization: `Bearer ${process.env.ZIPPER_TOKEN}`,
    "Content-Type": "application/json"
  }
});
const json = await res.json();
if (!res.ok) throw new Error(json.error ?? res.statusText);
console.log(json);

Tips

The gate stores only what the app marks reusable — when unsure, it fetches origin.

This is a cache at the edge of the Zipper network, not far-away points of presence.

• ▸SOC 2
• ▸Cache isolation
• ▸X-Cache-Status

Runbook

The Barbican sits in front of the app on this node and stores only responses that declare themselves reusable: private, no-store, and Set-Cookie responses are never stored, and websockets or signed-in requests bypass the gate entirely. Freshness always comes from the response the app already sends — the gate never invents a lifetime. Every answer carries X-Cache-Status: HIT, MISS, or BYPASS. When in doubt the gate fetches the origin instead of guessing.