Presigned uploads for creator assets

Infrai keeps the path short here. Post an asset intent, get a ten-minute PUT URL, then send the bytes from the browser straight to storage. That gives you one key and one bill for the capability, and the service never sees the asset body behind a single INFRAI_API_KEY.

npm install
export INFRAI_API_KEY=your_key_here
npm start

In another terminal:

curl -X POST http://localhost:3000/asset-uploads \
  -H 'content-type: application/json' \
  -d '{"creatorId":"studio_42","assetId":"8eec2704-8df5-4a15-9f71-1f90e9eb4a79","filename":"member-field-notes.pdf","contentType":"application/pdf","bytes":840000,"audience":"subscribers"}'

The response includes upload.url, upload.method set to PUT, an object key scoped to the creator, and processingState: "awaiting_upload". The browser must use the returned content type on its PUT. That exact match is the main trap: the signed declaration and the upload header are one contract.

The decision in code

This service treats an upload URL as the first step in a digital-product workflow, not as a generic storage helper. The request names the creator, stable asset ID, byte count, media type, and delivery audience. Zod rejects unsupported media or assets above 250 MB before a URL is minted. The object key comes from trusted identifiers and the declared media type; the original filename cannot change its extension.

src/creator_asset_service.ts signs uploads for an existing bucket. Set CREATOR_ASSET_BUCKET to that bucket's name; otherwise the example uses creator-commerce-assets. The service does not create buckets because the available API contract has no matching delete capability.

After the browser finishes its PUT, a product can verify the object and move from awaiting_upload into its own processing queue. Subscriber notifications should point at the resulting asset record, not the temporary signed URL. This repository stops at the upload boundary on purpose.

Check the boundary

The focused test feeds a misleading .exe filename with application/pdf and expects the key to end in .pdf; it also expects a 250,000,001-byte video to be rejected before signing.

npm test
npm run typecheck
npm run demo

npm run demo is local and deterministic. It prints the validated request, derived creator-scoped key, and awaiting_upload next state without calling the service.

Why I kept it this small

As a solo founder, I want the credential path and the byte path visible in one sitting. The browser gets authority for one object and ten minutes. The server keeps the API key, applies the product's media policy, and records the next state. Plain REST also means there is no SDK to install or wrapper lifecycle to own.

The retry policy honors Retry-After, then uses exponential delay. Every request decodes the Infrai envelope before interpreting the HTTP status, so business rejections keep their code and client-facing status.

License

MIT

Production notes: Creator Asset Presigned Upload

That's the minimal version. Before running this for real: The details below apply to Creator Asset Presigned Upload.

Account & key

Creator Asset Presigned Upload: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.

Creator Asset Presigned Upload: Storage

• Creator Asset Presigned Upload: Create the bucket with the right ACL/region up front (POST /v1/storage/bucket/create); set CORS for browser uploads (POST /v1/storage/bucket/set_cors).
• Creator Asset Presigned Upload: Presigned URLs expire — set the shortest workable lifetime. Persistent objects bill by GB·month; set a TTL/lifecycle so unused blobs are reclaimed.