Piped: a YouTube frontend that splits the browser app from the scraper

This repository is the frontend, not the whole system

Piped is described as an open-source alternative frontend for YouTube which is efficient by design. That description is accurate but easy to under-read, because Piped is two pieces of software and this repository is only one of them. A frontend that renders video listings and a player has to ask something for the data, and in Piped's case that something is a separate backend service built around NewPipeExtractor.

The dependency list confirms the shape. The frontend imports `shaka-player` for media playback and `fast-xml-parser` for feed documents, which is what you would expect from a client. It does not import a scraping library, because the scraping happens elsewhere. The technical features in the README put it plainly: it does not use official YouTube APIs, and it uses NewPipeExtractor to extract information.

Some README details still carry the old repository naming, which is worth knowing if you go looking for source. The GitHub stars badge points at TeamPiped/Piped-Frontend and the last-commit badge points at the same path, even though this repository is TeamPiped/Piped. Those are stale badge targets rather than a sign the code lives elsewhere, but they will send you to a redirect if you click them.

The public API is documented separately. The README links the specification to the TeamPiped/OpenAPI repository and the documentation to docs.piped.video, and says the documentation site source is in TeamPiped/Documentation. Three repositories before you reach the backend.

A Vue 3 and Vite application with an unusually opinionated toolchain

The build is current enough to be worth reading closely. Vue is at 3.5.32, vue-router at 5.0.4, vue-i18n at 11.3.2, and the bundler is Vite 8.0.8. Tailwind runs through its Vite plugin at version 4, and there is a legacy plugin in the build, which tells you the app still targets browsers that need transpiled output. The browserslist field confirms the intent, pinning only the last Chrome and last Firefox version.

Styling runs through `unplugin-icons` with the Font Awesome icon sets as dev dependencies, and `eslint-plugin-better-tailwindcss` is in the lint toolchain. Component primitives come from `reka-ui` rather than a hand-rolled set, and `@vueuse/core` handles the composable utilities. None of this is remarkable on its own; together it is a fairly standard modern Vue stack applied consistently.

The scripts are short enough to read in one glance:

"scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "format": "prettier -w --ignore-path .gitignore **/**.{js,vue,json}",
    "lint": "eslint --fix --color ."
}

The package manager is pnpm, with `pnpm-lock.yaml` and `pnpm-workspace.yaml` both committed. The README's development section matches the scripts, giving `pnpm install` to set up and `pnpm dev` to start a hot-reloading dev server.

Two entries in the tree are worth a look for context. `renovate.json` says dependency updates are automated, and `.coderabbit.yaml` says code review assistance is configured. Neither changes how the app works, but both are signals about how the project absorbs upstream change in a dependency set that moves quickly.

The Docker image is a static build served by unprivileged nginx

The Dockerfile is the most informative file in the repository for understanding what this project actually ships. It is a two-stage build: a Node LTS Alpine stage that installs with pnpm and runs `pnpm build`, then an `nginxinc/nginx-unprivileged:alpine` stage that receives only the built `dist/` directory.

That final image choice matters. There is no Node runtime in the shipped container, no application server and no filesystem to write to at request time. The output of a Vite build is copied in as static files and served by nginx running as an unprivileged user, with the HTML copied under owner 101 and the custom config mounted from `docker/nginx.conf`.

FROM nginxinc/nginx-unprivileged:alpine

COPY --chown=101:101 --from=build /app/dist/ /usr/share/nginx/html/

COPY --chown=101:101 docker/nginx.conf /etc/nginx/conf.d/default.conf

This is the same structural decision the v3 branch of some other static site projects make for a different reason, and it has the same payoff: the runtime surface is a web server you already understand, and image size stays small. It also means the frontend cannot do server-side work. Every dynamic operation, including login, must go through the backend API.

The build stage enables corepack and pins pnpm to latest rather than a specific version, which is convenient and slightly unpinned at once. Both `Dockerfile` and `Dockerfile.ci` are committed, so CI builds its own variant. `vercel.json` explains the Vercel mirror in the README's mirror list, alongside a `public/` directory for static assets.

Feature claims that belong to the frontend and claims that do not

The README's user feature checklist is long, and it is worth sorting it because the entries are not all the frontend's responsibility. Frontend concerns include infinite scrolling, light and dark themes, 4K support, audio-only playback, progressive web app support, locally saved preferences, embedded video support, no age restriction, and translations across many locales hosted on Weblate.

The privacy claim that gets the most attention, no connections to Google's servers, is the one that needs the most care. What the frontend can guarantee is that it talks to its own API rather than to Google. What reaches the media CDN on playback is decided by the backend and by upstream URL behaviour, not by this repository. Both statements are in play, and the useful reading is that the browser is not the component phoning home.

The backend-dependent items are SponsorBlock integration, Return YouTube Dislike through a separate RYD-Proxy service, LBRY integration for streaming, and the ability to bypass geo restrictions through a federated network. Login is also backend work. Multi-region load balancing and handling thousands of concurrent users are backend and infrastructure properties, described in the README as technical features.

That leaves the frontend's real contribution visible: a fast, translated, themeable player shell that speaks a documented JSON API. Which is exactly the right shape for a frontend, and also exactly why the backend is the part that determines whether an instance works.

Public instances, mirrors and the ecosystem built on the API

Piped's user base is not directed at a single server. The README points to a list of public instances in the TeamPiped documentation repository, and its own hosted instance is at piped.video with a registration endpoint behind a badge. The list of mirrors at the bottom of the README is a good illustration of how cheap it is to host this frontend: Cloudflare Pages, Vercel, Render, Fleek, DigitalOcean, Netlify and Azure, each on a short subdomain.

None of those mirrors change who serves the data, which is the practical limit of mirroring a frontend. You can point the app at a different backend and get a different experience; you cannot make a frontend-only deployment more private than the backend it calls.

The ecosystem section is the most telling part. LibreTube, Yattee, YTDLnis, Pipeline and PlasmaTube are mobile or desktop clients, and the README says YTDLnis uses Piped to update formats, which means the backend serves non-browser consumers too. Harmony Music is a Flutter app with Piped linking for playlists. On the web side there is Hyperpipe for YouTube Music, ytify, Piped-Material as a fork focused on performance and design, and Musicale.

The extension story is equally concrete: Piped-Redirects, Libredirect and Predirect all rewrite YouTube links to Piped. A documented JSON API plus a redirect extension is what turns a frontend into infrastructure, and it is the reason this repository has 319 open issues without the project having collapsed under the maintenance load.

Editorial conclusion

Piped's frontend is a well-executed Vue application whose real design decision lives one repository away, in the backend that does the extracting. Everything from multi-region load balancing to public instance count belongs to that service, so judging Piped by this repository alone will mislead you. What this repository settles is the client half: which browser APIs are used, how the app is built and served, and how much of the ecosystem plugs into it through the documented API. Start with the self-hosting documentation to understand which backend you are deploying against, then read the package scripts to see the whole build, from Vite compile through to the nginx image.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. TeamPiped/Piped on GitHub