Skip to content
Rendorix

Deployment

Deployment is infrastructure as code (typically Terraform) plus runtime secrets and runbooks. The Rendorix GitHub project should stay the source of truth for module names and CI—this page describes a healthy rollout pattern.

Sub-pages: Terraform, AWS setup.

Environments (dev / staging / prod)

Section titled “Environments (dev / staging / prod)”
  • Prefer separate AWS accounts for prod vs non-prod, or enforce strict IAM and tagging boundaries. Do not reuse production HMAC keys in development.
  • Use isolated Terraform state per environment (separate S3 buckets or prefixes; locking via DynamoDB—see Terraform).
  • Use distinct hostnames (e.g. img.staging.example.com vs img.example.com) with matching ACM certificates and CloudFront alternate domain names.

Pre-deployment checklist

Section titled “Pre-deployment checklist”
  • Terraform plan reviewed; no unexpected destroys or state corruption during migrations.
  • Secrets in Secrets Manager, SSM, or CI—not committed to git.
  • S3 bucket policies block public access on originals; only intended CloudFront / OAC / origin roles can read objects.
  • Lambda memory and timeout tested against worst-case reasonable source images.
  • CloudFront cache behaviors and query-string inclusion match your signing and preset design (Caching).
  • CloudWatch alarms or equivalent for 5xx, Lambda errors, and unusual 403 rates at the edge (AWS setup).

Post-deployment verification

Section titled “Post-deployment verification”
  1. Run the Quick start smoke test: signed URL returns 200 with expected Content-Type.
  2. Repeat the request and confirm CDN cache behavior via response headers or CloudFront metrics.
  3. Negative tests: missing signature → 403; expired exp → 403; unknown preset → 4xx per policy.
  4. Publish terraform output for app teams (distribution hostname, public base URL—never raw secrets).

Rollback and disaster recovery

Section titled “Rollback and disaster recovery”
  • Infrastructure: Re-apply a known-good Terraform revision; avoid console drift that state does not track.
  • Lambda code: Use version aliases, traffic shifting, or your pipeline’s rollback to the previous artifact if supported.
  • Key compromise: Follow Security rotation; invalidation does not revoke already-issued long-lived signed URLs.
  • Regional / data recovery: Define RTO/RPO for S3 (versioning, replication) per your own SLOs—outside the scope of this generic guide.
Section titled “Related reading”