onescales/Upload-to-Web3

Upload-to-Web3 provides a focused Apify Actor for downloading files from supplied URLs and uploading them to Pinata. The implementation supports public IPFS uploads and private Pinata storage, records the CID and resulting URL, and saves an individual success or error result for each file. The input schemas are well organized, and the Pinata API key is correctly marked as a secret. Sequential processing with a delay keeps the behavior predictable, while the README offers clear setup instructions and useful warnings about publishing sensitive or copyrighted material.
The main improvement should be securing the download stage. The Actor fetches arbitrary user-provided URLs without a timeout, file-size limit, protocol validation, or protection against private and link-local network addresses. In a hosted environment, this creates an SSRF risk and could expose internal resources before uploading them to Pinata. Redirects need the same validation. Large or slow responses can also exhaust memory because each file is fully loaded into a blob before upload. Adding an abort timeout, download limits, private-address blocking, safer redirect handling, and streaming where supported would make the Actor much more robust. Retry logic with bounded exponential backoff would also help with temporary network and Pinata failures.
The project would benefit from automated tests for public uploads, private signed links, failed downloads, rate limiting, and malformed input, plus a CI workflow to run them. Dependency builds are not reproducible because the repository has no lockfile and the Docker image runs npm install against a caret version. Several metadata details also need alignment: package.json declares ISC, while the repository uses a modified MIT license with mandatory attribution, and the copyright years differ. The duplicated root and .actor schemas have already begun to diverge. Keeping one authoritative set would prevent future configuration drift. Finally, the documented 30-day private-link default conflicts with the one-day default in main.js, and claims of permanent storage should explain that availability still depends on continued Pinata pinning and gateway access.