DEV Community: Radhey Kalra

hi

Radhey Kalra — Thu, 15 Oct 2026 15:51:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

BoxBox v0.3.0: file and folder sharing for a self-hosted file manager

Radhey Kalra — Tue, 06 Oct 2026 09:50:23 +0000

A few months ago I wrote about building BoxBox, a self-hosted file manager for homelabs and NAS boxes. v0.3.0 is out, with file and folder sharing.

Music: "the kill 2" by Lex Amarni & 2muchmotion.

What's new

File and folder sharing. Every file or folder gets a token link. Folder links come in four levels: View only, Upload only, Upload + delete, and Full access. Links can expire and can be revoked.
A public share page. Recipients get a path bar, a file list, previews, a read-only code editor (editable with full access), arrow-key navigation, and ZIP downloads. No account needed.
Folder uploads. Drop a whole folder in. Uploads go in chunks and keep nested paths.
Drives and Places. Top-level mounts are drives. A mount inside another mount (like Downloads inside home) shows up under Places. You can override either with kind: in the config.
Your wallpaper on share pages. Each user's wallpaper is stored on the server and shown to their recipients.

The hard part: sharing from a box that holds everything

A homelab file manager usually runs with access to your disks, backups, and configs. Public links need to keep recipients inside the shared path. These are the rules BoxBox follows.

The token is the only credential. Each link is 32 random bytes from crypto/rand, encoded as 43 URL-safe characters. Recipient endpoints are public, so they get their own per-IP rate limit, separate from login.

Every failure looks the same. Unknown, expired, and revoked tokens all return the same 404. Someone guessing tokens learns nothing about which links ever existed.

Re-check the path on every request. A share stores a path, not a promise. On every recipient request BoxBox resolves the path against the current mount config. If you remove or rename a mount, its links stop working. If a mount becomes read-only, its links can still read but can't upload.

Upload-only means upload-only. Recipients with upload access must not overwrite existing files. Uploads land in a temp file and are published with renameat2(RENAME_NOREPLACE) on Linux, so the kernel refuses to replace an existing file atomically.
On other platforms it falls back to a hard link plus remove, which gives the same no-replace guarantee.

Revocation wins races. If you revoke a link while someone is mid-upload, the upload is not published.

Treat previews as hostile. Recipient downloads and previews use the same sandboxed Content-Security-Policy as the main app. HTML, SVG, and XML are always downloaded, never rendered inline, so a shared file can't run script on your BoxBox origin.

ZIPs stay inside the share. Folder archives check every entry's traversal and resolved path against the share root before streaming, so a symlink can't pull in files from outside it.

Keep internals private. Recipient responses never include mount names or server paths. The share store is 0700, and the token-bearing shares.json is 0600.

Upgrading

One breaking change: the container now listens on 8080 instead of 80. The container side of your port mapping, the healthcheck, and any reverse proxy must match port in config.yaml. The release notes cover this, plus rollback.

BOXBOX_IMAGE=ghcr.io/jr4dh3y/boxbox:v0.3.0 docker compose pull
BOXBOX_IMAGE=ghcr.io/jr4dh3y/boxbox:v0.3.0 docker compose up -d

Try it

Site and docs: https://boxbox.radhey.dev
Repo (MIT): https://github.com/jR4dh3y/BoxBox
Release: https://github.com/jR4dh3y/BoxBox/releases/tag/v0.3.0

If you run a homelab, I'd like to know what you'd share first, and what would stop you from exposing a share page to the internet.

I built BoxBox, a self-hosted file manager for home-labs

Radhey Kalra — Tue, 02 Jun 2026 10:48:09 +0000

I wanted a simple way to manage files on my Linux server from the browser.

Not a full cloud suite.
Not a bloated desktop app.
Just a clean web UI over the folders and disks I already have mounted.

So I built BoxBox.

BoxBox is a self-hosted file manager for homelabs, NAS-style setups, and bare-metal Linux servers.

Repo: https://github.com/jR4dh3y/BoxBox
Site: https://boxbox.radhey.dev

What it does

BoxBox lets you browse multiple mounted paths from one UI:

/mnt/storage
/srv/media
/home/user

It supports:

Multi-mount navigation
Chunked uploads for large files
Real-time progress through WebSockets
Copy, move, and delete operations
Image, audio, video, PDF, code, and text previews
Monaco editor for editing config and code files in the browser
Docker and Compose deployment

The main idea is simple:

Manage Linux server files like local folders.

Why not just use Nextcloud?

Nextcloud, Seafile, Syncthing, and similar tools are great, but they are much bigger than what I wanted.

I did not need calendars, contacts, sync clients, plugins, or a whole cloud ecosystem.

I wanted something narrower:

Open browser. Pick mount. Browse files. Upload and download. Preview media. Edit config files. Move stuff around.

That is the core loop.

Stack

The backend is written in Go.
The frontend is built with SvelteKit and TypeScript.
The editor uses Monaco.
Live progress and events use WebSockets.

Deployment is Docker-first, so the setup is meant to stay simple for homelab use.

What I want feedback on

BoxBox is still early, and I would love feedback from people who actually run homelabs or NAS servers.

PRs, issues, feature requests, commits, bug reports, and security feedback are open.

Repo: https://github.com/jR4dh3y/BoxBox