Caching & Revalidation

Forte serves your website over a global content delivery network (CDN). This page covers what gets cached, how to control it, and the rules around revalidating server-rendered content.

Static assets

The fingerprinted build output a framework emits — hashed JavaScript, CSS, and media files — is cached aggressively. These files are immutable: when their content changes, their filename changes, so a new deploy is picked up right away without serving anything stale. You don't need to configure this.

Server-rendered responses

For a server-rendered (SSR) website, caching is driven by the Cache-Control header your app sets on each response:

  • No Cache-Control (or no-store) — the response is generated fresh on every request. This is the right default for dynamic, per-user pages.
  • Cache-Control with a positive shared lifetime (for example s-maxage) — the response is cached at the CDN for that period and reused for every visitor, then refreshed.

Set these headers in your framework the same way you would behind any CDN.

Time-based revalidation

Time-based revalidation works. In Next.js, a route segment with:

ts
export const revalidate = 60

is served from cache for the configured number of seconds, then refreshed on the next request after it expires. This is honored at the CDN through the response's cache headers, so it behaves the same for every visitor. Use it for content that changes on a schedule — a blog index, a product listing, a homepage.

On-demand revalidation

On-demand revalidation is not applied reliably

On-demand revalidation — revalidateTag, revalidatePath, or the Pages Router res.revalidate — is not reliable on Forte.

Forte runs your app on multiple servers. An on-demand revalidation call only refreshes the cache on the server that handles it; the other servers and the CDN are unaffected, so a page you expect to update may keep serving its previous version.

Use one of these instead:

  • Time-based revalidation (export const revalidate) for content that changes.
  • Redeploy to publish updated content immediately — a deploy refreshes everything.

If your build calls an on-demand revalidation API, Forte adds a note to your build log pointing back to this page.

Server-rendered request limits

Server-rendered websites handle ordinary request/response web traffic. A few limits are worth knowing when you build one:

  • No WebSockets or other long-lived connections. Use ordinary HTTP requests.
  • Requests must finish within about a minute. Move long-running work — large reports, media processing — to a background job instead of doing it inside a request.
  • Keep request bodies small. Large uploads (multi-megabyte files) should go straight to your storage provider, with your app handling only a reference to the file.

Reading the visitor's domain

Forte sits in front of your app, so the standard Host header your code sees is an internal value. To get the domain the visitor actually used — for canonical URLs, redirects, metadata, or sitemaps — read the x-forwarded-host header. Most frameworks already do this for you.

If you use an authentication library, turn on its trust-host option so it builds callback URLs from the forwarded host. In Auth.js / NextAuth, set:

ts
trustHost: true

Next Steps

Search

Search documentation and console pages