ephShare: a file share with no database, and a copy anyone can run on cheap hosting

1The problem

Sooner or later you need to hand someone a file or a small web page: a mock-up, a PDF, a folder of images. Email chokes on size. Consumer file-sharing services add accounts, ads, expiry and tracking. Spinning up a full content management system is overkill. What is wanted is a folder on your own domain that you can drop things into and share by link.

ephShare is that folder, with a dashboard in front of it.

2What ephShare does

You sign in to a private dashboard and manage a single folder of files. You can upload, create, edit, rename, move, duplicate, delete, zip, unzip and search. Anything in that folder is public to anyone holding the link, which is the point. Optionally, one HTML page of your choosing can be shown as the home page.

3How it is built

ephShare is plain PHP with no framework and no database. The application splits into three folders, and only one of them has a web address.

All file operations are confined to public/uploads/, a “jail” that every path is resolved against, which blocks directory traversal. Because there is no database, backup is just copying the uploads folder, and moving the app is just moving a folder.

4Lightweight by design

ephShare asks almost nothing of the machine it runs on. There is no database server to keep running, no background worker, no queue, no cache layer and no framework to load. When nobody is using it, it uses nothing: the host runs a small PHP script only while a request is being answered, then lets go.

Measured on a clean copy of the standalone edition, signed-out page loads (home, sign-in and dashboard redirect), five requests each. Peak memory is PHP's own reported allocation; CPU is the process time consumed per request. Heavier actions such as zipping a large folder cost more in proportion to the files involved, which is the work itself rather than overhead.

This is why the original ran comfortably on a low-power board, and why the standalone edition fits the smallest shared hosting plan without needing special permissions. It also keeps the attack surface small: there is little running, so little to go wrong.

5Keeping uploads from becoming code

The classic way to lose a PHP file host is to let someone upload something that the server then runs. ephShare puts several independent barriers in the way, so one mistake does not open the door.

• One allow-list. A single list of permitted extensions is checked by upload, create, rename and zip extraction alike. An early version had separate lists per action, and rename had none; consolidating them closed a gap in rename.
• Name check. Any name containing a PHP-like segment is refused, even in the middle (a name that ends in .txt but contains an executable extension is still rejected).
• Server lock. The uploads folder carries its own server rule that stops the web server running anything inside it. This is deliberately independent of the app code.
• Sandboxed pages. HTML and SVG files open under a throwaway, isolated origin, so script inside an uploaded page cannot act as the signed-in owner. The trade-off is that shared pages cannot use cookies or browser storage.

Every state-changing request also needs a security token, defeating cross-site request forgery. The standalone edition went through a separate AI security review before release, and every genuine finding was fixed.

6Signing in

The edition built for self-hosting uses one password and a deliberately simple first-run flow. On a fresh install the sign-in page asks for a one-time setup code. That code is written to a file only someone with access to the hosting account's files can read, so a stranger who finds a brand-new install cannot claim it first. The owner pastes the code, chooses a password of at least 12 characters, and the code is destroyed.

• Passwords are stored as strong one-way hashes.
• Repeated wrong guesses are locked out.
• Sessions last at most 12 hours and expire after 2 hours idle; cookies are HTTP-only, Secure and SameSite.
• Forgot your password? Delete the hash file and the app returns to first-run setup, signing everyone out.

7Three editions, one idea

The original (November 2025)

Built over a few days as a self-hosted file manager for low-power hardware, with a PIN to sign in. It worked, but it was written quickly and later review found real weaknesses, including weaknesses that have since been closed. It is kept as a historical tag and marked never to be deployed.

The hardened edition (July–August 2026)

The code was reconciled with what was actually running, then audited. The weaknesses were closed, the PIN was removed in favour of a central single sign-on gate in front of the whole app, and features arrived: an optional front page, a fixed header that always names the space you are in, and a public signed-out page.

The standalone edition (October 2026)

Demand appeared for a copy that could run on ordinary shared hosting. Rather than hand over the old code, the standalone edition was built fresh from the hardened one with the parts specific to one environment removed: the sign-in gate, the container tooling and the internal integrations. In their place came the first-run password flow described above. It was released with a fresh history so nothing from the earlier versions travels with it.

8Checking a live site

The standalone package includes a read-only probe script anyone can run from a terminal against their own site. It never signs in and changes nothing. It confirms, among other things, that the dashboard demands sign-in, every action refuses signed-out requests, folders have no directory listing, config and secret files are not reachable, version details are not advertised, the session cookie is Secure, uploaded pages carry the sandbox header, and plain HTTP redirects to HTTPS. It exits non-zero if any check fails, so it can sit in a scheduled monitor.

A second, destructive test suite runs against a throwaway local copy only: it sets the password, uploads files, and deliberately trips the lockout.

9Review and verification

Because the code is produced with AI assistance, review carries more weight than usual. The standalone edition went through a separate, security-focused review pass before release, and every genuine finding was fixed. The working rule is that a feature is not done until a committed check exists and has been seen to fail when the thing it guards is broken. The pattern that worked: build quickly, audit hard, then ship a smaller, simpler package.

10Limits and what is next

• Single user. One owner, one folder. There are no accounts, teams or per-file permissions.
• Public by design. Anything in the folder is open to anyone with the link, so it is not for private documents. Despite the name, files do not expire on their own today.
• Sandboxed pages cannot use cookies or storage, which rules out some interactive sites.
• Updates are manual. Replace the code, keep the data and uploads folders.

Natural next steps are optional expiry dates for shared files, and a signed update package.