Upload from the lab computer. Download it later. No account needed.

What’s LabStash?

LabStash is a temporary file-sharing service designed for computer labs. Upload files before you leave, get a short code, and download them from any device later. Files auto-expire and have a configurable download limit — no Google login, no email attachment size limits, no forgotten sign-outs.

Why I Built LabStash, and What Nearly Broke Me While Doing It

Picture this: you're in your college computer lab, you've just finished an assignment, and now you need to get that file home. What do you do? You log into your personal Google account on a shared lab PC, email the file to yourself, and hope you remember to log out before you leave. Now add a wrinkle: the file's bigger than Gmail's 25MB limit. And another: you don't have your phone with you, because most labs don't allow it. This exact hassle — repeated by hundreds of students every single day — is what LabStash exists to fix. It's a website where you upload your file, get a short code back (something like AE7-BCU-FVH), and use that code later to download it — from anywhere, on any device, with no account and no login at all. The idea sounds simple. Building it taught me more about real-world software engineering than any single college project has.

The problems nobody warns you about

Problem 1: "Temporary" is harder to build than it sounds.

If a file is supposed to disappear after 6 hours, when exactly does that clock start? I originally built a system that checked every 15 minutes for anything overdue — but that meant a file could sit around for up to 15 extra minutes after it should've vanished, and worse, every file was on the same shared countdown regardless of when it was uploaded. The fix was giving each file its own personal timer that starts the second it's uploaded, so file A and file B — uploaded minutes apart — each disappear exactly on their own schedule, not a shared one.

Problem 2: Two people can accidentally "steal" the same download slot.

Imagine a file that's only allowed to be downloaded once, and two people click the link at the exact same moment. Without care, both could succeed — like two people both grabbing the last seat on a plane because the airline checked availability a split second too late for both of them. I had to make the "check if a download is allowed" and "record that it happened" steps happen as one inseparable action, so there's no gap in time for two requests to slip through together. I actually simulated ten people hitting the same file simultaneously to prove this worked — and it did, every time.

Problem 3: Files kept a weird, meaningless name on download.

Early on, downloaded files were saved as things like 28e2a16a-de89.enc instead of the student's actual filename, like assignment.pdf. The browser simply wasn't being told what the real name was. I traced this down to a small but real gotcha: browsers block websites from reading certain pieces of information back from a server response unless the server explicitly says it's okay to share. One line of configuration fixed it — but finding that one line took real digging.

Problem 4: A "temporary" tool that accidentally became permanent.

While planning how to actually put LabStash online for free, I discovered that the free hosting tier I'd planned to use wipes its local storage clean every time the server goes idle and restarts — which happens automatically after 15 minutes of no traffic. That meant all my records of which codes belonged to which files could vanish randomly, at the worst possible time. The fix was moving that record-keeping to a proper hosted database that survives restarts, rather than keeping it on the server's own disposable disk.

Building it to survive a rush of students, not just one person testing it

A lab full of students finishing at the same time isn't a hypothetical — it's the actual use case. A few decisions went specifically into surviving that kind of moment:

• The actual files live in cloud storage, separate from the app itself — so the server handling requests never gets bogged down holding onto file data; it just points to where the real thing lives.
• Every "is this allowed?" check happens as one atomic step in the database, the same fix described above for the double-download problem — this matters a lot more once you imagine dozens of students hitting download buttons in the same few seconds after class ends.
• Rate-limiting — the system's way of saying "slow down" to someone hammering the server — is shared across every copy of the app running, using a fast, separate piece of infrastructure built exactly for this (Redis). Without this, running multiple copies of the app to handle more traffic would quietly break the "slow down" rule entirely, since each copy would count separately instead of together. I proved this by literally running two independent copies of the server and confirming they correctly shared one limit instead of each allowing their own.
• Cleanup work happens in the background, not in the middle of someone's request — so deleting old files never makes an active upload or download wait around for housekeeping to finish. None of these are exotic techniques. They're the same handful of ideas — "don't let two things happen at once when only one should," "don't make the user wait for unrelated work," "share information the right way across multiple machines" — that show up in almost every system built to handle more than a handful of people at once.

Where it stands now

LabStash is open source and still growing. You can check out the code here: github.com/StackFox/LabStash. If you're a student who's ever emailed yourself a file out of sheer necessity, this one's for you. <empty-block/>