Presets

A preset is a short, stable name (for example hero, card, avatar) that maps to a concrete set of image parameters: dimensions, output format, quality, and anything else your pipeline supports.

In app code (with @rendorix/client) you reference the name; the library resolves it to w / h / f / q and builds the signed URL. On the wire, the official Node client typically emits those concrete fields in the query—not a p=hero token—so the edge signs a stable, explicit transform. (A custom design could use p= everywhere; signer and verifier must match.) See Usage: presets.

What a preset is

• Contract between design (what “hero” means visually) and engineering (how that maps to width/height/WebP, and so on).
• Enforcement point: the edge and worker can reject requests for unknown presets or forbidden combinations, which keeps the attack surface smaller than a fully open “pass any number” API.
• Versioning in practice is often hero → hero_v2 or config snapshots deployed with your IaC; avoid silently changing what hero means without a cache or URL plan.

A minimal mental example:

Preset	Typical intent
hero	Large landscape, good quality, WebP/AVIF
card	Medium, lighter quality, fixed max width
avatar	Small square, crop, low byte weight

Defining and updating presets

Where presets live is up to your deployment—common patterns:

• Config file in the image repository, loaded by the Lambda (simple, good for “preset = deploy” workflows).
• S3 object or SSM Parameter Store (update without redeploying code—add caution and versioning).
• DynamoDB or another store if you need dynamic product-driven presets (higher operational complexity).

When you change a preset definition, old URLs can still be cached at the CDN or browser. Plan for: shorter cache TTL, key changes, or invalidation—see Caching and TTL.

Defaults and fallback behavior

Document explicitly:

• Unknown preset → 400 (strict) or default preset (convenient but can hide bugs).
• Conflicts when both preset and inline parameters appear—Overrides should state precedence (e.g. preset wins, or whitelisted overrides only).

Rendorix is opinionated by design; “fail closed” is usually better for security and predictability than a silent default.

Preset vs. one-off parameters

• Presets keep URLs short and reviewable in code review (?p=hero).
• Overrides (when allowed) handle rare exceptions without minting a new named preset for every case—tighten min/max bounds in policy at the edge.

If every request becomes a bespoke parameter salad, you lose the consistency Rendorix is aiming for; treat overrides as constrained escape hatches.

Testing presets

• Golden outputs: same original + preset → same checksum (or perceptual check) in CI after pipeline changes.
• Visual spot checks for hero and card on real content before production deploys.
• Load is not the only risk—memory and time for huge originals; test upper bounds and rejection paths.

Related reading

• Signed URLs — URLs must still be signed even with presets
• Architecture — where preset config is consumed in the pipeline