Quick start

This quick start is the path for operators and integrators: deploy (or use) the Rendorix stack on AWS, then request an image through the CloudFront URL with a valid signed URL. Exact repository layout and terraform module names may vary—follow the infrastructure repository that ships with your Rendorix version (see the main GitHub project).

If you are only working on the marketing site or this docs site in rendorix-web, you do not need the steps below; run npm install and npm run dev from that repo’s README.

Prerequisites

• AWS account with permissions to create the resources your Terraform defines (S3, CloudFront, Lambda, IAM, and related services).
• Terraform (1.x recommended) and AWS CLI configured for the target account (e.g. aws configure or short-lived role credentials).
• Node.js (for example 20 LTS) if you use a small script to sign URLs (signing is often done in CI or a backend, not in the browser).
• Git to clone the Rendorix infrastructure and application repositories.

Configure AWS and Terraform (minimal)

1. Clone the repository that contains the Rendorix Terraform root module (naming varies by project layout).
2. Copy the example variable file (often terraform.tfvars.example → terraform.tfvars) and set at least:
   • Region and environment (e.g. dev / prod)
   • S3 bucket (or name prefix) for originals
   • CloudFront / domain settings as required
   • Signing secret (or a reference to where secrets are stored—AWS Secrets Manager is a common choice)
3. Review which outputs you need after apply (typical: CloudFront domain or alias, Lambda-related values if you script against them, and signing parameters for HMAC).
4. Run terraform init in the working directory (with remote state if your stack uses a backend—configure that first if applicable).

Secrets: The HMAC key for signing must not be committed to the repo. Use your team’s standard approach (e.g. Secrets Manager, SSM Parameter Store, or CI injected env vars for non-production).

Deploy the stack

terraform plan -out=tfplan
terraform apply tfplan

After apply succeeds, note:

• The image delivery base URL (for example the CloudFront distribution hostname or your custom domain)
• How signing is configured in your project (which query or header fields participate in the HMAC, and the expiry parameter name)

If your project documents outputs (e.g. terraform output), use those as the source of truth for the base URL and integration settings.

Generate a signed URL and verify the response

1. Pick an object key in the originals bucket that your stack expects (or upload a test image to that key).
2. Mint a URL in one of two ways:
   • Node: use @rendorix/client — createRendorix({ baseUrl, secret, presets }).img(key, { preset: "…" }) (see Client library). You do not assemble HMAC by hand.
   • Any runtime / manual: build the same sorted query the verifier expects (w / h / f / q as applicable, exp, then s) and sign the canonical string per Generating image URLs and your CloudFront code.
3. Request the URL:

curl -sI "https://<your-cloudfront-host>/<path>?<signed-query-string>"

You want HTTP/2 200 (or 304 if you repeat with caching headers) and content-type matching the delivered image. A 403 usually means a bad or expired signature or a deny policy at the edge. For day-to-day app work, use Client library so presets and signing stay in one place.

Troubleshooting

Symptom	What to check
403 from CloudFront	Signature (algorithm, key, parameter order), clock skew vs. exp, and that the asset and preset are allowed.
404 or NoSuchKey-like behavior	S3 key / path the origin expects; path normalization in your transform URL.
Stale image after an update	Cache-Control / TTL at CloudFront and browser; Caching and TTL.
Terraform fails on IAM or quotas	AWS setup—service quotas, nodejs_compat if using Workers-like runtimes, and least-privilege IAM.
Slow first request	Cold start for Lambda; subsequent requests should hit the CDN if keys are consistent.

For deeper integration (framework examples), see Examples; for cost and complexity tradeoffs, Tradeoffs.