Skip to content
Rendorix

Overview

Rendorix is a developer-first, serverless image delivery system on AWS. You serve images over HTTPS: the path points at an object (your original), and the signed query string encodes the transform (dimensions, format, quality), when the link expires, and a MAC the edge can verify.

How you author that intent is the main DX choice:

  • Recommended: @rendorix/client — Define transforms once in a presets map (like Tailwind’s theme: design tokens in one place). In SSR, API routes, or SSG, call img("photos/hero.jpg", { preset: "hero" }). The library resolves the preset, validates bounds, canonicalizes, and signs—you do not hand-build query strings or HMAC. The browser only receives a normal signed URL string for src / srcset.
  • Manual — You can still construct URLs and HMAC without the library (other languages, custom tooling); you must match the same signing string and parameter rules as the CloudFront viewer validator. See Generating image URLs for the wire format and steps.

Marketing copy sometimes shows ?p=hero for intuition. The official Node client expands named presets into concrete w / h / f / q fields in the actual request; your edge may also support a literal p param if you implement a different wire format—keep signer and validator aligned.

This documentation covers architecture, security, caching, deployment, the client library, and how to integrate. See the Rendorix project on GitHub for source and infrastructure.

What is Rendorix?

Section titled “What is Rendorix?”
  • Image delivery, not a media suite — Rendorix is built for transforming and serving images (resize, format, quality, and similar) from private originals in object storage, with edge caching so repeat views are fast and cheap.
  • Presets over free-form parameters — You define named transforms once (e.g. hero, card, avatar). Application code references a preset instead of a long list of ad hoc query parameters.
  • Secure by design — Requests are validated at the edge and use HMAC-signed URLs (with expiration) so you do not rely on a public, unsigned transformation API.

Rendorix is intentionally minimal: URL-based usage, no dashboard required for the core path, and behavior that works the same from any stack (Astro, React, Next.js, and so on).

How it works (at a glance)

Section titled “How it works (at a glance)”
  1. Originals live in Amazon S3 (private; not directly browsable for transforms).
  2. Amazon CloudFront sits in front as the global CDN — most responses are cache hits.
  3. Edge validation (for example, a CloudFront Function or equivalent) enforces signatures and policy before expensive work runs.
  4. On a cache miss that is allowed, AWS Lambda (with an image engine such as Sharp) renders the variant, then the result is cached at the edge.
  5. Each distinct transformation is ideally computed once per cache policy, then served from the CDN on subsequent requests.

That flow keeps latency low for visitors and compute and origin traffic bounded by cache hit rate and request signing.

When to use it

Section titled “When to use it”

Rendorix is a good fit when you want:

  • Consistent image sizes and formats across products and teams
  • Simple URLs in app code (preset + asset path) instead of dozens of width/quality combinations
  • Serverless operations (no self-managed image workers)
  • AWS-native building blocks and infrastructure as code (e.g. Terraform) for the delivery stack

It is not aimed at a full digital asset management platform, a heavy “configure everything in a UI” product, or non-HTTP delivery models.

Section titled “Related reading”