A private presigned upload is the right default for an edtech avatar: the browser sends bytes directly to S3-compatible storage, while the application keeps the authority to issue keys and record ownership. For backup and restore workflows, keep that same discipline around snapshot selection: store the object key and the tenant identity in the database, then verify the object before marking the avatar ready.

This is a delivery decision, not a shortcut. The application avoids proxying image bytes, but it must validate content, constrain expiry, make retries harmless, and treat storage state as something to confirm rather than assume.

How can a Node.js service upload a user avatar to S3-compatible storage?

The signal to watch is a record that says avatar_ready while the object is absent, owned by another tenant, or larger than policy allows. A second signal is duplicate work after a worker timeout.…