Qiniu Upload And Auto Delete

Problem

Storing OCR screenshots, temporary documents, or internal assets as Base64 can quickly fill database rows with large payloads and slow page rendering. Uploading to object storage without cleanup also leaves temporary files in the bucket long after they are needed. Qiniu Upload And Auto Delete targets this "short-lived file needs a URL and must disappear later" case.

How It Works

The skill accepts a local file path filePath, uploads the file to the configured Qiniu Object Storage bucket, and applies a server-side lifecycle rule. Pass deleteDays to override the default retention; otherwise the global defaultDeleteDays is used. isPrivate controls whether the returned URL is public or private. Private links are better for internal assets, while public links suit temporary previews.

The response includes key, hash, url, deleteAfterDays, deleteAt, and deleteHuman. The hash can be used for integrity checks, and url remains usable until the server-side deletion happens, after which access fails. Applications usually only need to store the key and URL in the database instead of the raw file content.

Boundaries

The skill uploads from a local file path only and does not accept Base64 payloads directly. Auto-deletion is a Qiniu server-side rule, and deleted files cannot be recovered. Private links depend on account key signatures, so changing keys may invalidate old signed URLs. Before use, configure accessKey, secretKey, bucket, domain, region, and defaultDeleteDays, and verify the bound domain, HTTPS setup, and Qiniu bucket permissions.