Skip to content
Rendorix

TTL

TTL (time to live) shows up in three different places in Rendorix-style systems, and conflating them causes either security issues (links that work too long) or UX issues (new images that refuse to update in the browser). This page is about concepts; Expiration focuses on signing behavior.

TTL in signed URLs

Section titled “TTL in signed URLs”

The signature is bound to an expiry (exp or your field name): after that time, the edge must reject the request, even if a long-caching browser might still want to reuse an old response. Typical choices:

  • Short (minutes to hours) for sensitive or frequently rotated content.
  • Longer (hours to days) for stable marketing assets when URLs are minted at build time and caching is the primary reuse mechanism.

Rule of thumb: signed TTL should be ≥ the longest HTTP cache you expect for that URL if you need browsers to be able to re-fetch a valid signed URL when cache expires—or you accept that users only get stale bytes until the HTML is rebuilt with a new signed link.

Section titled “HTTP Cache-Control and related headers”

Successful image responses should carry explicit caching policy (often via CloudFront or origin headers):

  • public — Response may be cached by CDNs and browsers (typical for public images).
  • max-age / s-maxage — How long a client (or shared CDN) can treat the response as fresh without revalidating.

immutable is appropriate when the URL is versioned (new bytes = new URL); it is a poor fit when the same signed URL is supposed to “mean” updated content over time (it usually should not—use a new URL or shorter TTL).

Aligning browser, CDN, and application TTL

Section titled “Aligning browser, CDN, and application TTL”
  1. Pick how often the image bytes for a given logical asset can change without a renamed URL (if ever).
  2. Set S3/CloudFront and app headers so the CDN TTL matches that reality.
  3. Set signed URL expiry so a stolen link does not outlive the business risk you accept—often tighter than browser max-age if you re-issue URLs on each page view.

When the signed link expires before the browser’s HTTP max-age, an old tab can still show a cached 200 from an earlier (then-valid) request—that is often acceptable. For rollouts that must be visible as soon as users refresh, issue new signed URLs in the page HTML, shorten max-age, or use versioned asset paths so the URL itself changes.

Rotation and key expiry

Section titled “Rotation and key expiry”
  • HMAC keys (see HMAC signing) are not the same as URL expiry. Rotate keys on a schedule; support overlapping verification (old + new) during rollover so in-flight pages do not all break at once.
  • TLS certificates and custom domain DNS for CloudFront have their own expiry—track them in the same calendar as IaC reviews.
Section titled “Related reading”