Caching

Gigadrive Network caches on response headers alone. There is no cache duration setting in the console and no heuristic that guesses a TTL for you: whatever cache-control a response carries is what the CDN honours.

What is cacheable

The platform sets a default cache-control on the responses it produces itself. It sets none on what your Function returns.

The split in the first two rows is the reason a per-deployment URL is safe to cache forever while a production alias is not. The alias re-points on every promotion, so its assets are revalidated with the origin every five minutes, and the same file addressed through the deployment's own hostname is cached for a year.

A Function response is forwarded with whatever headers your handler set, so decide the caching yourself rather than relying on a platform default:

export function GET() {
  return new Response(JSON.stringify({ status: 'ok' }), {
    headers: {
      'content-type': 'application/json',
      'cache-control': 'public, s-maxage=60, stale-while-revalidate=300',
    },
  });
}

You can also attach headers to a route in gigadrive.yaml, which applies them to whatever the handler returned:

version: 4

functions:
  api/index.js:
    runtime: node-22

routes:
  - source: ^/api/health$
    destination: /api/index.js
    headers:
      cache-control: public, s-maxage=30

Route headers are skipped on responses with a status of 400 or above, so a failing request never inherits a caching rule written for a healthy one.

Cache keys

A cached entry is keyed by hostname and query string. Two applications sharing the CDN never see each other's responses, and ?page=2 is stored separately from ?page=3. Query parameters are sorted before the key is built, so ?b=2&a=1 and ?a=1&b=2 hit the same entry.

Cookies are not part of the key. A response that varies per user has to say private or no-store itself.

Requests that negotiate WebP or AVIF get their own entries, and so do the React Server Component variants of a Next.js page, which is what keeps a client-side navigation from being served an HTML document.

Invalidation

Promoting a deployment purges the CDN for every alias that moves, before and after the alias re-points. Nothing is left to expire, and there is no manual step after a deploy.

Inside a Next.js application, revalidateTag reaches the platform and purges the matching CDN entries as well as the stored cache entry:

'use server';

import { revalidateTag } from 'next/cache';

export async function publishPost() {
  // ... write the post ...
  revalidateTag('posts', 'max');
}

The second argument is the cache profile to revalidate against and is required. Use updateTag instead when the writer has to read its own change back immediately.

Exact URLs are purged alongside the tag for the paths the tag resolves to, up to 120 URLs per call.

Optimized images have their own purge endpoint, covered in Image optimization.

The runtime cache

Next.js applications get a durable cache behind incremental static regeneration, use cache, and partial prerendering. It is scoped to one deployment and one build, it survives a Function being suspended, and it is shared by every invocation of that deployment rather than living in one process's memory.

You do not configure it and there is nothing to install. What you see of it is in your usage: reads and writes are metered as runtime_cache_reads and runtime_cache_writes, and a tag revalidation counts as a write. Usage breaks those down per application.