StreamHub


If you've ever wanted to peek under the hood of a real-world React and TypeScript project without putting your main computer at risk, sandboxing it is one of the better ways to learn. I recently did exactly that with StreamHub, an open-source IPTV dashboard built with React, TypeScript, Tailwind CSS, and Vite. Here's a full breakdown of what the project actually does, how I set it up using Windows Sandbox, and what the experience taught me about running unfamiliar code safely.

What Is StreamHub?

StreamHub is an open-source web dashboard that aggregates publicly available IPTV channel lists and displays them through a browser-based video player. It doesn't host any video content itself. Instead, it pulls together M3U playlists — plain text files containing stream URLs and metadata — from community-maintained sources and merges them into a single browsable catalog.

The project is built on a modern front-end stack:

  • React 19 for the UI
  • TypeScript for type safety
  • Tailwind CSS for styling
  • Vite as the build tool
  • HLS.js to handle HTTP Live Streaming playback in the browser

It's a genuinely useful reference project if you're trying to understand how a real app handles playlist parsing, deduplication, CORS proxying, and stateful routing — independent of whatever you end up doing with the streams themselves.


Why I Used Windows Sandbox Instead of My Main Machine

Quick note before this section: using Windows Sandbox is optional, not a requirement. You can clone and run StreamHub directly on your normal machine with just Git and Node.js installed, following the exact same commands below. I chose to use Sandbox simply as a personal precaution, not because the project demands it.

Before running npm install on any unfamiliar GitHub repository, it's worth asking what you're actually trusting: every dependency, every script, every API call the project makes. Rather than running it directly on my main system, I used Windows Sandbox, a built-in Windows feature that spins up a disposable, isolated desktop environment.

The appeal is simple. Everything inside the sandbox — installed software, downloaded files, browser history — disappears the moment you close it. Nothing persists, and nothing touches your actual files, accounts, or installed programs. For testing an unfamiliar repository, that's a sensible default rather than a paranoid one — but it's purely a "nice to have" for peace of mind, not a setup prerequisite.

Windows Sandbox is available on Windows 10 and 11 Pro, Enterprise, or Education editions. It's not available on Windows Home — if you're on Home edition, just skip ahead and install Git and Node.js directly on your system instead.

Step 0 (Optional): Enable Windows Sandbox

Windows Sandbox is a disposable, throwaway virtual environment — anything done inside it disappears completely once you close it. This is why we're using it: if anything in this project turns out to be untrustworthy, none of it touches your real computer.

If you'd rather skip the sandbox entirely, you can jump straight to Step 1 below and install Git and Node.js on your regular system. The sandbox step is just an extra layer I added for my own setup.

Requirements: Windows 10/11 Pro, Enterprise, or Education. Not available on Windows Home.

  1. Press Start, type Turn Windows features on or off, open it.
  2. Scroll down, check the box for Windows Sandbox.
  3. Click OK, then restart your computer when prompted.

Step 1: Launch Windows Sandbox

  1. Press Start, type Windows Sandbox, open it.
  2. Wait for the clean virtual desktop to load.

Remember: everything from here on happens inside this sandbox window, not on your main computer. If you close the sandbox, you lose everything and have to start over from Step 1.

Step 2: Install Git (inside the sandbox)

  1. Open Edge inside the sandbox.
  2. Go to https://git-scm.com/download/win
  3. The download should start automatically (or click the Windows download link).
  4. Run the installer.
  5. Click Next through all the prompts, keeping the default options.
  6. Let it finish.

Step 3: Install Node.js (inside the sandbox)

  1. In Edge, go to https://nodejs.org/
  2. Download the LTS version.
  3. Run the installer.
  4. Click Next through the prompts, keeping defaults, then Install.
  5. Let it finish.

Step 4: Open a terminal

  1. Press Start (inside the sandbox), type cmd, open Command Prompt.

Step 5: Confirm Git and Node.js installed correctly

Type each command below one at a time, pressing Enter after each:

node -v

Expect to see a version number like v20.x.x.

npm -v

Expect a version number like 10.x.x.

git --version

Expect something like git version 2.x.x.

If any of these say the command isn't recognized, the install didn't complete — repeat Step 2 or Step 3 for whichever one failed.

Step 6: Choose a folder and download the project

Navigate to the Desktop:

cd Desktop

Clone the repository:

git clone https://github.com/TechKnoWEB/StreamHub.git

Wait for it to finish (you'll see "Receiving objects..." scroll by, then it returns to a blank prompt).

No Git alternative: if you'd rather skip Git entirely, go to the repo page in Edge, click the green <> Code button, choose Download ZIP, then extract it from the Downloads folder instead. Everything from Step 7 onward is identical either way.

Step 7: Move into the project folder

cd StreamHub

Step 8: Install the project's dependencies

npm install

This downloads all the libraries the project needs (React, Tailwind, HLS.js, etc.). Takes a minute or two. You'll see a progress bar and a final summary line like "added 250 packages."

Step 9: Start the app

npm run dev

Wait for output that includes a line like:

Local:   http://localhost:5173/

Step 10: Open it in the browser

  1. Open Edge inside the sandbox.
  2. Go to http://localhost:5173
  3. The StreamHub dashboard should load.

How the App Actually Works

Digging into the project structure revealed a fairly clean separation of concerns:

  • Playlist aggregation: On load, the app fetches M3U playlists from two public community repositories, then deduplicates entries by stream URL, merging them into one catalog of several thousand channels.
  • Playback: Streams are handled through HLS.js, which is necessary because most browsers (aside from Safari) don't natively support HLS (.m3u8) playback in a standard <video> element.
  • CORS proxying: Many public stream URLs block direct cross-origin requests from a browser. The project includes a small backend proxy (in an api/ directory) designed to run as a serverless function, most likely intended for deployment on Vercel given the included vercel.json configuration.
  • State and routing: The app uses React Context for theme switching and for passing "currently live" match data between sections, with hash-based routing (#home, #iptv, #sports) to preserve tab state across refreshes.

This is a solid, approachable example of how a single-page app can aggregate third-party data sources, handle playback compatibility issues, and work around browser security restrictions — useful patterns regardless of the specific use case.

A Note on Legal Risk

This is the part worth being upfront about, since it's easy to gloss over in a "cool open-source project" writeup.

StreamHub itself doesn't host or license any media. The channel lists it aggregates come from community-maintained playlists, and the live sports integration pulls from a third-party API and embeds an external player. Whether any specific stream is legally distributed depends entirely on the original source, and that can vary by channel, by match, and by the viewer's country.

Major sporting events in particular tend to have exclusive, country-specific broadcast rights sold for significant sums, and rights holders are generally active in pursuing unauthorized redistribution. Laws around watching (as opposed to hosting or distributing) unlicensed streams vary considerably by jurisdiction. If you're looking to actually watch a major sporting event, checking who holds official broadcast rights in your country is the safer and more reliable route.

What I Took Away From This

A few practical lessons from the experience:

  1. Sandboxing unfamiliar code is a low-cost (but optional) habit. Windows Sandbox made it trivial to try a project without any lingering footprint on my main system — though it's just one of several ways to test code cautiously, not a requirement.
  2. Open-source aggregator projects are great for learning architecture, even when you have no intention of relying on them for anything beyond testing — deduplication logic, proxy patterns, and state management are all transferable skills.
  3. READMEs aren't always accurate. The mismatched clone URL in this project was a small but telling reminder to read setup instructions critically rather than copying them blindly.

If you're comfortable with a terminal and want a contained way to explore a real React/TypeScript codebase, this kind of sandboxed local setup is a solid weekend project — just go in with realistic expectations about both the code quality and the legal grey areas that come with any IPTV aggregator.


Have you tried running unfamiliar open-source projects in a sandboxed environment? I'd love to hear how you approach testing code you don't fully trust yet.

Post a Comment

Please No spam link, No Hate Speech in the comment box.

Previous Post Next Post