When I rebuilt my video downloader as a plain PHP site on shared hosting, the first design decision was the simplest one: my server never keeps the video. A visitor pastes a link, my code finds the file, and the file travels straight to them. Nothing is saved on my disk, not even for a minute.

It sounds obvious, but it is a deliberate choice, and it shapes everything else in the codebase. Here is why I made it, and what it costs.

The disk would fill up anyway

Shared hosting gives me a small slice of disk and a hard inode limit. One viral video is a few hundred megabytes; a busy afternoon of downloads would be gigabytes. If I stored every file, I would need a cleanup job, a quota check, and a plan for when the disk fills at 2 a.m. — and a full disk on shared hosting does not just break downloads, it breaks the whole site.

So there is no uploads/ folder, no temp directory filling with MP4s, and no cron job deleting old files. The absence of a storage layer is the feature.

How the download actually works

There are two endpoints, and the split matters. resolve.php takes the pasted link, calls the provider API, and returns a JSON list of formats — each one a URL, a quality label and a file size. It never touches the video bytes.

The second endpoint is the proxy. When the visitor picks a quality, the browser asks my proxy for that file. The proxy opens the provider's URL with cURL, sets a CURLOPT_READFUNCTION callback, and writes each chunk straight to the visitor as it arrives:

curl_setopt($ch, CURLOPT_WRITEFUNCTION, function ($ch, $data) { echo $data; flush(); return strlen($data); });

PHP's memory limit never comes into play because the whole file is never in memory — only one chunk at a time. A 500 MB video costs my server a few kilobytes of RAM. The trick is calling flush() after every chunk so the visitor's download starts immediately instead of buffering until the end.

For YouTube this is where it gets interesting. The provider's tunnel refuses requests from datacentre IPs, which is exactly what my server is. So for YouTube, the format is flagged as "direct" and the visitor's own browser fetches the file — no proxying at all. Same outcome for the visitor, zero bytes through my server.

What I lose by not storing anything

The honest trade-off is speed. A stored file could be served instantly from my own disk, and repeat downloads of the same popular video would cost me nothing. Instead, every download is a fresh fetch from the provider, and if the provider is slow or says "Service is busy", the visitor waits. I retry the API call up to three times, but I cannot make a slow provider fast.

I also cannot offer a download history or a "your recent downloads" page. There is nothing to list. That is a privacy win — I genuinely have nothing to leak — but it is also a missing feature some visitors would like.

The legal and trust side

I am not a lawyer, but the logic is plain: a downloader that stores files becomes a host of those files. A downloader that only passes them through is a pipe. I do not want to be in the business of deciding which files I am allowed to keep, or answering for files I never asked to hold. Passing the bytes through and forgetting them keeps the site simple, and simple is defensible.

It also makes the privacy story easy to tell honestly. The site has no accounts, no cookies and no database. My privacy page can say "we keep nothing" and mean it, because there is literally nowhere on the server for a video to live.

The rule I kept

Every time I have been tempted to cache a file "just for an hour" to speed things up, I have said no. The moment I store one file, I need expiry logic, disk monitoring, and a policy for what happens when storage runs out. The pipe stays a pipe.

If you are building a tool on shared hosting, ask yourself what your server actually needs to remember. On ramrom.io, the answer turned out to be nothing at all — and the site is faster, cheaper and easier to reason about because of it.