Uploadcare

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the file upload path I actually need instead of Uploadcare.

Start from the rule that decides the architecture: **files must never pass through your application server.** Sign a direct upload to object storage and let the browser talk to it. Everything else follows.

STACK
- Node 20+ with Fastify — only for signing and bookkeeping
- SQLite through better-sqlite3, WAL mode
- Object storage with presigned multipart uploads
- Uppy in the browser for the widget half
- sharp and ffmpeg on a worker for derivatives
- Caddy in front

THE DATA MODEL
- uploads: id, owner_id, key, filename, declared_type, detected_type, bytes, sha256, status, created_at, completed_at
- derivatives: id, upload_id, kind, key, bytes, created_at
- scans: id, upload_id, verdict, detail, at

THE UPLOAD ITSELF
- Your server issues a presigned multipart URL with a size cap, a type constraint and a short expiry, and records a pending row
- The browser uploads directly, in parts, resuming after a dropped connection. A 2GB file over a phone connection is the case that decides whether this works
- Storage notifies completion, or the client confirms and the server verifies the object exists and its size — **never trust the client's word that an upload finished**

VALIDATION, WHICH IS SECURITY AND NOT A FORMALITY
- **Detect the type from the file's own bytes, never from the extension or the declared content type.** A .jpg that is actually HTML, served from your domain, is stored cross-site scripting
- Serve user files from a separate domain, always with `Content-Disposition: attachment` unless the type is one you deliberately render inline, and with a strict content security policy
- Hard caps on size, dimensions and megapixels; a decompression bomb is a real attack and sharp will happily try
- Scan with ClamAV on a worker before the file is reachable. Quarantine until it passes

DERIVATIVES
- Thumbnails, a poster frame, a PDF first page. Generated on a queue with a concurrency cap, never during the request
- Store the hash and deduplicate: the same file uploaded twice is one object with two rows

DELIVERY
- Signed expiring URLs for anything private, and a cheap network in front for anything public
- Range requests supported, so video seeking works

OPERATIONS
- A sweeper deleting pending uploads that never completed, or storage fills with abandoned halves
- Per-owner quotas, and bytes stored and served recorded daily
- Deletion that actually deletes: the object, its derivatives and the rows

WHAT MATTERS MOST
Direct-to-storage uploads and type detection from the bytes. The first is why it scales; the second is why it does not become an attack on your own users.