Caching and response headers

Use HTTP response headers to tell browsers and compatible caches which responses they may store. Choose the policy according to the content, rather than applying a long cache lifetime to every route.

Openstead serves versioned static releases. This is not a promise of a global CDN, and the saved Cache profile selector alone does not configure a response cache. Use explicit headers and verify the responses your visitors receive.

Set static-site headersCopy Anchor Link

Open the static site's Settings → Custom HTTP headers, add a path pattern, header name, and value, then deploy to publish the change.

For a site whose /assets/ directory contains only content-hashed build assets:

Use the real asset paths generated by your framework. The long asset lifetime is appropriate only when every content change produces a new URL. A file called app.js that changes without changing its URL should not receive a year-long immutable policy.

no-cache allows storage but requires revalidation before reuse. no-store instructs clients not to store the response. They have different meanings.

Set dynamic response headers in the applicationCopy Anchor Link

For web services, configure response headers in your framework or application server. Responses containing account information, personalised HTML, or private API data should not use a broad public cache policy.

For example, an Express handler for a private account response can set:

response.set('Cache-Control', 'private, no-store');
response.json(accountSummary);

This example assumes the request has already been authenticated and authorised. Caching headers do not provide access control.

Publish updates safelyCopy Anchor Link

Use content-hashed asset filenames so a deployment can reference new assets immediately while older browser caches remain valid. Keep HTML lifetimes shorter than immutable assets so visitors discover the new references.

Changing an Openstead variable or response-header setting does not rewrite already cached files on every visitor's device. Deploy the updated site, confirm its served headers, and use new asset URLs when replacing immutable content.

A code rollback changes the active release. It does not erase copies already stored by browsers or an external cache.

Verify the actual responseCopy Anchor Link

Inspect a representative page and asset with your browser's network panel or:

curl --head https://app.example.com/
curl --head https://app.example.com/assets/app-CONTENT_HASH.js

Replace these example URLs with paths that exist in your release. Check Cache-Control, content type, status, and any Vary header used by the application.

Test authenticated and unauthenticated requests separately. An asset URL returning HTML often indicates a missing file or an overly broad SPA rewrite, not a cache problem. See Static sites.

External cache providersCopy Anchor Link

If you add an external caching service, follow its own invalidation and authentication requirements. Do not enable Cloudflare proxying merely to try caching while using Openstead's current direct-DNS domain-verification flow; see Cloudflare DNS.

Openstead's maintenance and platform-error responses use no-store. Ensure your own error and personalised responses have a deliberate policy as well.