January 14, 2026 4 min read JavaScript fork

seedbox lite

Abstract

A light-weight torrent media center at one place.

The Problem

Users who run a private torrent client often have to juggle a separate UI, a download client, and a media player. Switching between them adds latency, and exposing the torrent stream to browsers safely is non‑trivial. SeedBox Lite tries to collapse those pieces into a single web‑based streaming front‑end.

What This Does

The repo ships a React front‑end (client/) and an Express API (server/). The UI lives in client/src/App.jsx and renders AuthenticatedApp, which pulls data from the back‑end via the service layer (client/src/services/*.js). The API entry point is server/index.js; it registers routes, serves the video range requests, and handles authentication. Docker files (client/Dockerfile*, server/Dockerfile, docker‑compose.yml) let you spin up the whole stack with a single docker‑compose up.

Key files:

client/src/components/VideoPlayer.jsx – video element, time‑update handling.
client/src/services/progressService.js – stores per‑torrent progress (11 functions, used by 5 callers).
server/handlers/streamHandler.js – reads torrent files and serves HTTP range responses.
server/middleware/requestLimiter.js – throttles inbound requests (high branching density).

How It Is Wired

Execution begins in server/index.js (line 1). It creates an Express app, applies requestLimiter middleware, sets CORS ('*' with credentials – a high‑severity issue), and mounts route handlers. The most‑used handler universalTorrentResolver (line 515) calls loadTorrentFromId (3 calls) to locate a torrent, then streams via streamHandler. Only one outbound network call is made from the server (the torrent client library). File I/O occurs in streamHandler (reads torrent pieces) and progressService (reads/writes JSON progress files).

On the client side, the entry point client/src/App.jsx renders AuthenticatedApp. AuthenticatedApp immediately invokes fetchData (via useSmartPolling) which calls api.getTorrents. The API layer (client/src/services/api.js) forwards the request to the Express server. The UI components that consume the data are:

VideoPlayer.jsx – called by VideoPlayer (34 functions total, highest blast radius).
HomePage‑clean.jsx – loads recent torrents (loadRecentTorrents → getRecentTorrents) and adds new torrents (addTorrent).
TorrentPage.jsx – formats file size/speed (via formatFileSize, formatSpeed).

The internal call graph shows getAllProgress and fetchWithTimeout each invoked from 8 places, making them hot spots for change impact. No circular dependencies were detected, but client/src/components/TorrentList.jsx has an instability of 1 (imports three modules and is imported by none), indicating dead‑code risk.

How To Use It

# Clone the original repo
git clone https://github.com/moses-y/seedbox-lite.git
cd seedbox-lite

# Build and run with Docker (recommended)
docker-compose -f docker-compose.yml up -d

# If you prefer a local node environment
cd server && npm ci && npm start   # starts Express on default port
cd ../client && npm ci && npm run dev   # Vite dev server on port 5174

Configuration – copy the example files and fill in secrets:

cp .env.example .env               # server env
cp client/.env.example client/.env # client env

The server expects PORT, JWT_SECRET, and torrent client options (see ENVIRONMENT-CONFIG.md). The client reads REACT_APP_API_URL from its .env.

Real‑World Use

A home‑lab media server could run SeedBox Lite behind a reverse proxy. A user authenticates via the UI, selects a torrent from the “Recent” page, and the client streams directly from the server’s range endpoint (/stream/:infoHash). Progress is persisted in client/src/services/progressService.js, enabling resume across sessions.

Code Health & Issues

High – Secret file tracked: server/.env.production is committed despite .gitignore.
High – Vulnerable dependency: express@4.18.2 has CVE‑2024‑29041; upgrade required.
High – No test suite: 0 test files for 50 source files.
High – Missing lockfile: top‑level package.json lacks a lockfile; lockfiles exist only in sub‑folders.
High – No CI pipeline: no .github/workflows or similar.
High – Dockerfile not gated: client/Dockerfile builds without automated verification.
High – Committed .env files: .env.docker, .env.production, client/.env.production, server/.env.docker.
High – Wildcard CORS with credentials: Access-Control-Allow-Origin: * paired with credentials:true.
High – Runtime eval/exec in server/index.js.
Medium – High branching density in server/middleware/requestLimiter.js and server/handlers/streamHandler.js.
Medium – Deep nesting (max depth 10) in several component files.

Additional observations: the repository includes a licence (LICENSE) but lacks a CI configuration and has duplicated ecosystem config files (client/ecosystem-*.js), a DRY violation.

The Bottom Line

SeedBox Lite provides a functional end‑to‑end torrent streaming UI backed by an Express API and is container‑ready. However, the codebase suffers from serious security hygiene lapses (committed secrets, unsafe CORS, eval), outdated dependencies, and a complete lack of automated testing or CI. It is suitable for internal or experimental use where the team can remediate the highlighted issues before production deployment.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

116 files

JavaScript29
JSX20
CSS16
Markdown8
JSON6
Shell4

ReactExpressDocker

Module dependencies

The 10 most depended-upon modules of 49, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_lient_src_config_environment["environment"] n1_src_services_progressService["progressService"] n2_rvices_torrentHistoryService["torrentHistoryService"] n3_client_src_services_api["api"] n4_src_components_ErrorBoundary["ErrorBoundary"] n5_t_src_components_VideoPlayer["VideoPlayer"] n6_ient_src_context_AuthContext["AuthContext"] n7__hooks_usePollingWithBackoff["usePollingWithBackoff"] n8_client_src_App["App"] n9__src_components_SettingsPage["SettingsPage"] n8_client_src_App --> n6_ient_src_context_AuthContext n8_client_src_App --> n9__src_components_SettingsPage n9__src_components_SettingsPage --> n0_lient_src_config_environment n9__src_components_SettingsPage --> n6_ient_src_context_AuthContext n9__src_components_SettingsPage --> n1_src_services_progressService

Dependencies

9 of 19 declared dependencies are a major version behind. Resolved 19 of 19 against the registry.

Package	Declared	Latest	Behind
`@vitejs/plugin-react`	^4.7.0	6.0.5	2 major
`eslint-plugin-react-hooks`	^5.2.0	7.1.1	2 major
`webtorrent`	^1.9.7	3.0.21	2 major
`lucide-react`	^0.539.0	1.31.0	1 major
`@eslint/js`	^9.32.0	10.0.1	1 major
`eslint`	^9.32.0	10.8.1	1 major
`globals`	^16.3.0	17.11.0	1 major
`vite`	^7.1.0	8.2.1	1 major

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowSecret-shaped paths present; the code-health audit confirms or clears them .env.production, client/.env.production, server/.env.production

Open in Code Brain → See its neighbourhood →

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high9

medium3

low1

Untrack the file your own .gitignore says to ignorehigh

server/.env.production

tracked although .gitignore excludes it

The author already decided this file must never be committed, so its presence is an accident nobody noticed, which means the credentials in it are the ones actually in use.

Fix: git rm --cached the path and rotate; the ignore rule is already correct.

Upgrade the pinned dependency carrying a published advisoryhigh2 occurrences

express@4.18.2 CVE-2024-29041 (medium) +1 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Add a test suite; this repository has nonehigh50 occurrences

50 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Commit a lockfile beside the manifesthigh

package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

49 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh3 occurrences

client/Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Remove the committed .env and rotate what it holdshigh5 occurrences

.env.docker

.env.docker, .env.production, client/.env.production, server/.env.docker

A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.

Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.

Replace the wildcard CORS origin with an explicit allow listhigh

server/index.js

Access-Control-Allow-Origin', '*' together with credentials enabled

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Remove eval over a runtime valuehigh

server/index.js

exec() over a computed value

eval executes whatever the string contains, so wherever that string came from is now able to run code in the process, and the distance between the input and the eval is usually the only thing making it look safe.

Fix: Parse the value into the type you expect, with json.loads or ast.literal_eval.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

client/Dockerfile

node:18-alpine, nginx:alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

1 further finding(s) are listed in the full report.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.

View on GitHub All Projects