Transloadit

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 the file pipeline I actually need instead of Transloadit — and start by noticing that the client half is free and excellent.

**Uppy is made by the same people and is open source.** Resumable uploads, a decent interface, and the tus protocol underneath. Take that, and the question becomes only what happens after the file lands.

STACK
- Uppy in the browser with tus for resumable uploads. Do not write an upload client
- tusd or a small Node receiver for the server half
- Node 20+ with Fastify for the pipeline
- SQLite through better-sqlite3 for jobs
- The converters are existing binaries, each in its own container: ffmpeg, ImageMagick or sharp, LibreOffice, Ghostscript
- Caddy in front

THE DATA MODEL
- uploads: id, token, original_name, stored_path, sha256, bytes, mime_detected, mime_claimed, received_at, expires_at
- jobs: id, upload_id, template_id, status, started_at, finished_at, error
- steps: id, job_id, name, tool, options_json, input_id, output_path, status, ms, log_excerpt
- templates: id, name, steps_json, version — the pipeline as data, versioned, so a job records which version ran
- Files expire by default, with a sweeper that deletes from disk as well as the row

THE UPLOAD
- Resumable, in chunks, so a two-gigabyte file on a phone survives a lift. That is the single feature people most notice
- Size limit enforced as bytes arrive, not after
- **Type from the file's own content, never the extension or the client's claim.** A mismatch is recorded and usually refused
- The assembled file hashed server-side and compared. Never trust the client's hash

SANDBOXING, WHICH IS NOT OPTIONAL
- Every converter runs in a container with no network, a read-only root filesystem, a tmpfs for work, a memory cap, a CPU quota, a wall-clock timeout and dropped capabilities
- Non-root inside, input mounted read-only, only the output directory writable
- ImageMagick, Ghostscript and LibreOffice have each been remote code execution within recent memory. **You are running strangers' files through parsers**, and the isolation is the requirement rather than a precaution
- Archives checked for expansion ratio and entry count before anything is unpacked. A zip bomb is a denial of service with a two-line fix

THE PIPELINE
- A template is an ordered list of steps, each naming a tool and its options, with the output of one feeding the next
- Steps that do not depend on each other run in parallel, bounded by a concurrency cap
- Every step's log kept, sanitised of paths, so a failure names the stage rather than the job
- Idempotency by a hash of the input and the template version: the same file through the same pipeline returns the stored result instead of running again
- Retries with backoff for transient failures, never for a parse failure

WHAT TO ACTUALLY BUILD
- Images: resize to declared sizes, convert to AVIF and WebP with a fallback, strip EXIF including location, and a focal point for cropping
- Video: a ladder of renditions packaged as HLS, a poster frame, and a hard duration cap. This is the expensive part — measure the processor cost before promising it
- Documents: office formats to PDF, and PDF operations through qpdf
- Say no to the long tail. Build the four you use rather than the forty a service offers

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SIGNING_SECRET, MAX_UPLOAD_BYTES, CONTAINER_RUNTIME
- Migrations on boot, each once; a queue with a concurrency cap, because this work is CPU-bound
- Disk watchdog that refuses new jobs rather than filling the volume
- Health endpoint that runs one small conversion through the real path

WHAT MATTERS MOST
Uppy for the upload, and the sandbox for everything after. Get an interrupted upload to resume, then try to break the pipeline with a malformed PDF and a zip bomb before writing a single format handler.