Skip to content
Rendorix

Core concepts

Rendorix is easier to reason about if you keep four ideas straight: presets (what to do to an image), signed URLs (who is allowed to ask), caching (where answers are stored), and TTL (how long each layer may trust a URL or a response). With @rendorix/client, presets live in config and img() turns them into the wire query; without it, you still implement the same resolve → sign contract. Usage covers app patterns; Security covers signing and threats.

Mental model

Section titled “Mental model”

  1. Your app (or your build) produces a request URL that names an asset and encodes the transform (from a preset name and/or overrides in code, then resolved to concrete fields on the wire) plus exp and s.

  2. The edge (CloudFront) first decides whether that request is cacheable and already in cache. A hit returns bytes without running image compute.

  3. On a miss, edge logic checks the signature and policy (preset allowed? params sane?). Failing that yields 4xx without touching S3 or Lambda for a full transform.

  4. The image worker loads the original from S3, applies the resolved transform (from presets + your rules), returns the image, and the CDN can cache that response under a stable key.

  5. TTL sits in two places: how long a signed URL remains valid, and how long HTTP caches (browser, CDN) may keep the served image. Those are not the same number and are often tuned differently.

That loop is the same one described in Architecture—this section names the concepts so the rest of the docs can stay concrete.

Glossary

Section titled “Glossary”
TermMeaning in Rendorix
OriginalThe source object in S3 (e.g. full-resolution JPEG) before any on-the-fly transform.
Variant / transformThe output image after resize, reformat, quality change, and so on.
PresetA named bundle of transform parameters (e.g. hero → width, quality, format) so URLs stay semantic instead of opaque.
Signed URLA request URL that includes a cryptographic signature (and usually expiry) so only your stack can mint valid links.
EdgeCloudFront and any lightweight checks that run before Lambda-scale work.
Cache keyWhat the CDN (and often the browser) uses to tell whether two requests are the same resource for caching.
TTLTime to live—how long something is valid: link lifetime vs HTTP Cache-Control / CDN behavior.

How concepts relate

Section titled “How concepts relate”
flowchart LR
  preset[Presets] --> url[RequestURL]
  sign[SignedURLs] --> url
  url --> cache[Caching]
  cache --> ttl[TTL]
  sign --> ttl
  • Presets simplify what you ask for; signed URLs constrain who can ask and when.
  • Caching reuses variants; bad cache keys mean misses and extra Lambda cost.
  • TTL must line up: a valid link can still be served from an old cache entry if HTTP caching is long—see TTL.

Further reading

Section titled “Further reading”