TransferNow

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 large-file transfer that replaces TransferNow: upload, share a link, and it expires — on my own storage.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Local disk or an S3-compatible bucket, with the upload going straight there
- Caddy in front

THE HONEST COST
- The cost of this business is bandwidth, and it is not small. A twenty-gigabyte file sent to five people is a hundred gigabytes out
- Some providers charge for egress and some do not. Check yours before building, put the number in the README, and set limits accordingly
- That is the real trade: you save a subscription and take on a bill that varies with use

THE DATA MODEL
- transfers: id, token, owner_id_or_null, title, message, total_bytes, file_count, status, expires_at, max_downloads, download_count, password_hash, created_ip_hash, created_at, deleted_at
- files: id, transfer_id, name, path, sha256, bytes, mime_detected, upload_id, is_complete
- chunks: id, file_id, index, sha256, bytes, received_at — for resumable uploads
- recipients: id, transfer_id, email, token, notified_at, first_downloaded_at, download_count
- downloads: id, transfer_id, recipient_id, at, ip_hash, bytes_sent, completed — append-only
- Deletion at expiry is real, on disk as well as in the row, and the row records that it happened

UPLOADING, WHICH IS THE HARD PART
- Chunked and resumable. A two-gigabyte upload over a domestic connection will be interrupted, and an upload that restarts from zero is a product nobody uses twice
- Each chunk hashed and verified; the assembled file hashed and compared before the transfer is marked complete. Never trust the client's hash
- Parallel chunks, with a sensible concurrency, because a single stream rarely saturates a connection
- Progress that is honest, including the time remaining, computed from the recent rate rather than the average
- The browser must be able to close and come back: the upload state is on the server, keyed by an upload identifier held in the browser
- A hard size limit per transfer and per file, and a disk check before the upload starts rather than a failure at ninety per cent

SHARING
- A link with a long unguessable token. That is the whole authentication for the recipient, and it must be long enough that guessing is hopeless
- Optional password, optional expiry, optional download limit, all enforced server-side
- Email the recipients if addresses were given, each with their own token so you know who downloaded
- The download page is plain and fast: what the files are, how big, when they expire, and a button. No account, no application, no explanation needed — that recipient experience is the entire reason this category exists

DOWNLOADING
- Range requests supported, so a large download resumes
- Several files zipped on the fly as a stream, never assembled on disk first
- A partial download does not count against a download limit; only a completed one does
- Bandwidth limited per transfer if you need to protect the machine, and stated if so

EXPIRY AND DELETION
- Everything expires. A default measured in days, configurable, with the countdown visible on the download page
- A sweeper that deletes from storage as well as the database, and a verification that it actually did
- Manual deletion by the sender at any time, immediately
- This promise is the product's privacy story and it is only as good as the sweeper. Test it

ABUSE, WHICH WILL FIND YOU
- A public upload endpoint on the internet becomes a file host for other people's content within weeks
- So: require an account, or an invitation, or at minimum a per-address-hash rate limit and a total storage cap per uploader
- Scan uploads with ClamAV if it is available, quarantining until the scan finishes
- A reporting link on every download page, and a way to take a transfer down in one command
- Never serve an uploaded file with a type the browser will execute. Force download with a content-disposition header and a type from your own detection, never from the client's claim
- Log enough to answer an abuse complaint, and no more

PRIVACY
- Optional client-side encryption: the browser encrypts before upload with a key in the URL fragment, which never reaches the server. The recipient's browser decrypts. Then the server genuinely cannot read the files, which is a much stronger promise than a policy
- Say clearly which mode a transfer used
- No third-party requests anywhere

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, MAX_TRANSFER_BYTES, RETENTION_DAYS, HASH_SALT, SESSION_SECRET, SMTP_URL, S3_*
- Migrations on boot, each once
- Disk watchdog that refuses uploads above a threshold rather than filling the volume
- Bandwidth measured per day, with an alert, because that is the bill
- Health endpoint checking storage and free space

WHAT MATTERS MOST
Resumable upload and real deletion. Get an interrupted two-gigabyte upload to continue where it stopped, and confirm an expired transfer is gone from disk. The first is why people use it; the second is why they trust it.

Give me the repository, the chunked upload client, migrations, .env.example, the sweeper, and a README with deploy steps behind Caddy and the bandwidth cost stated.