Why I Don't Cache Video Files on My Downloader

When I built ramrom.io, a free video downloader that runs on plain PHP hosting, one of the first questions I had to answer was simple: once a visitor downloads a video, should my server keep a copy of it?

It is tempting. If ten people download the same popular TikTok video, keeping one copy on my server means I only fetch it once. Less work for the provider, faster for everyone. A cache feels like the obvious engineering choice.

I decided not to do it. Here is why, and the three options I weighed up.

Option 1: hotlink

Hotlinking means giving the visitor the provider's file URL directly and letting their browser fetch it. My server does almost nothing, which is lovely on shared hosting with a modest memory limit.

The problem is that the link is not really mine to give away. Some provider URLs are signed and expire after a few minutes, so a visitor who opens the page and comes back later finds a dead link. Others check the referrer or the IP address, and a link that works for my server returns nothing for the visitor's browser. I still use direct links in one place — YouTube, where the provider's tunnel simply will not answer my server's datacenter IP — but I treat that as a fallback, not the plan.

Option 2: proxy

Proxying means my server fetches the file and streams it straight through to the visitor, without saving it anywhere. That is what ramrom.io does today. The visitor gets a working download, the file never touches my disk, and when the transfer finishes there is nothing left to clean up.

It costs bandwidth on my side, and the transfer is only as fast as the slowest hop between the provider and my server. On a small shared hosting plan that is a real limit: a big file can take longer, and PHP's execution time ceiling means very large files fail honestly instead of hanging forever. I accept that tradeoff because it keeps the site simple.

Option 3: store (cache)

Storing means saving each downloaded file on my server so the next person gets it from me. This is the fastest option for repeat downloads and the kindest to the provider's API. It is also the option with the most hidden costs.

First, disk space. Videos are not small, and a popular video can be hundreds of megabytes. A shared hosting plan fills up fast, and there is no graceful way for a site to run out of disk — things just start failing.

Second, cleanup. A cache needs expiry rules, a janitor process, and a way to know when a file is stale. On shared hosting there is no cron job I fully control and no background worker, so the janitor is a script I would have to trigger myself and hope it runs.

Third, and the one that settled it for me: responsibility. A stored file is a file on my server, in my name, with my hosting account behind it. I built a tool that fetches public videos for the person who pasted the link. Keeping a copy turns me from a pipe into a host, and I do not want that job. The video belongs to the person who made it and the platform it came from; my site is only the bridge between the two.

What I actually do

So the rule on ramrom.io is simple: nothing is stored. The resolve step calls the provider API and returns a URL. The proxy streams the file through and forgets it. The next visitor with the same link goes through the same two steps again.

It costs a little more bandwidth and a little more API quota. In exchange I get a site with no disk to fill, no cleanup job to babysit, and no stored copies of other people's videos sitting on my server.

Sometimes the boring choice is the right one. A cache would make the site faster on paper. Not having one keeps it honest, small, and easy to run on the cheapest hosting I could buy — which, for a side project, matters more than speed.