renditionkit$ npm install renditionkit
DOCS / ARCHITECTURE

One asset ID.
One processing attempt.

The API owns uploads and asset records. The queue carries an ID; the worker reads the latest durable record and runs the engine selected by its mediaType.

APPLICATION↓REPOSITORY + ORIGINAL↓BULLMQ JOB / ASSET ID↓WORKER → IMAGE ENGINE↓OBJECT STORAGE + READY METADATA

The attempt lifecycle

  1. Load the asset from the configured AssetRepository.
  2. Claim and mark the processing attempt.
  3. Select the matching MediaEngine.
  4. Read, validate, inspect, and checksum the original.
  5. Emit each rendition to ObjectStorage.
  6. Persist dimensions, byte counts, keys, and transform metadata in one ready result.

Predictable output keys

Default keys include namespace, media type, asset ID, rendition version, and output name. A retry writes the same keys rather than creating new names.

Object key
renditions/<namespace>/<media-type>/<asset-id>/v<version>/<name>.<extension>

Who owns what?

Your app owns upload policy, asset identity, database schema, access control, and delivery URLs. RenditionKit owns the processing lifecycle. The provided PostgreSQL repository is available when you want a ready-to-use persistence model.

Failure behavior

Bad inputs are rejected without retrying. Unexpected errors are rethrown so the queue adapter can retry. Completed outputs are not deleted after a transient failure because a ready database write may have committed even when its response was lost.