tapexyz/tape: self-hosting an open video-sharing platform built on Lens

What tapexyz/tape actually is, and who it is for

Tape describes itself in the README as "an open video-sharing platform", and the package.json description repeats that phrase. The repository is a pnpm monorepo written in TypeScript, licensed under AGPL-3.0, and it is not archived. The last push was on 2026-05-23.

The audience is narrow. This is not a drop-in YouTube clone you configure with environment variables and deploy. It is a codebase with a web frontend, an embed player, an API, a cron worker, an Open Graph generator and a set of signup contracts, plus packages for Lens indexing and shared UI. Someone who wants to run a video site without writing code has little to gain here. Someone building a Lens-integrated media frontend, or studying how one is assembled, has a full example in front of them.

The distinction matters because the README spends more space on the app and package tables than on operation. The tables are the real documentation: they tell you the shape of the system, and everything else has to be inferred from the directory tree.

The monorepo layout is the architecture document

The README lists six apps and nine packages. On the app side, web is the frontend, embed is the video player meant to be embedded elsewhere, cron covers background tasks, api is the backend, og generates Open Graph meta tags, and contracts holds permissionless signup contracts. On the package side, abis holds contract interfaces, config holds shared lint configuration, constants holds application-wide constants, generic, server and browser hold helper collections, lens holds everything related to the Lens indexer, and ui holds web UI components.

That split tells you where to look when something breaks. Metadata previews come from the og app, not the web app. Anything touching Lens goes through the lens package. Contract ABIs are isolated in abis, which means the contracts app and whatever consumes it share a single source for interfaces.

The presence of a cron app and an api app as separate deployable units is the most consequential detail. Background work does not run inside the web process, so a single-node deployment that only starts the frontend will not perform whatever the cron jobs do. The README does not say what those jobs are, and it does not document how the apps are meant to be deployed together. That is a gap, not an oversight you can paper over: you will be reading apps/cron source to find out.

Installing Tape and getting the dev server up

The README gives two commands. It notes that the monorepo uses pnpm as its package manager, and the root package.json enforces this with a preinstall script that runs npx only-allow pnpm, so npm and yarn will fail before anything installs.

From the repository root:

pnpm install

Then start the application:

pnpm dev

The README says to visit http://localhost:4783. That port is the only concrete runtime detail the documentation provides. The dev script itself is pnpm -r --parallel run dev, which runs the dev script in every workspace package in parallel, so the terminal output will interleave logs from several apps rather than showing one clean server log.

The root package.json also defines narrower entry points. pnpm web runs pnpm --filter @tape.xyz/webv3 dev, which starts only the web app, and pnpm mobile runs pnpm --filter @tape.xyz/mobile expo:start. Note that the mobile script targets a package the README's app table does not list, so the table is not exhaustive. If you want a quieter first run than the full parallel dev, pnpm web is the more targeted command.

There is no documented production build or deploy sequence beyond the generic build, start and codegen scripts in package.json. Treat the README's instructions as a development setup, because that is what they are.

What the documentation does not tell you

The README does not document environment variables, database requirements, storage backends, or how the api and cron apps are configured. It does not describe upload flow, transcoding, or moderation. It does not explain what the contracts app deploys or to which network. For a platform whose entire purpose is hosting and serving media, the absence of any storage or delivery detail is the largest hole.

The release history reinforces the point. The most recent tag is v2.0.3-beta, published on 2024-07-25, and the two before it, v2.0.2-beta and v2.0.1-beta, are from 2024-03-22 and 2024-01-31. Every tag carries a beta suffix. There is no stable release to pin to, and no changelog explaining what changed between them.

So the honest position is this: you can install dependencies and start a dev server from the README, and that is the extent of what the README promises. Everything past that is source reading. If your team cannot afford that, Tape is the wrong tool regardless of how well the code is organised.

Tape against a conventional video CMS

The obvious comparison is with a self-hosted video platform such as PeerTube, which ships an installer, an administration interface and documented storage and transcoding settings. The difference is not quality, it is intent. PeerTube is a product you operate. Tape is an application codebase you modify, with a Lens package and signup contracts sitting inside it.

That shows up in the dependency graph. A conventional CMS hides its data layer behind an admin panel; Tape exposes abis, constants and lens as packages any app in the workspace can import. If you want to change how identity or signup works, you are editing contracts and the packages around them, not toggling a setting.

The trade is straightforward. Tape gives you a TypeScript monorepo where the frontend, the embed player and the metadata generator are separate, replaceable pieces, which is useful if you intend to embed playback somewhere else or serve link previews from a dedicated service. It gives you far less if you wanted to point a config file at a bucket and walk away.

Licence and the cost of staying current

Tape is licensed under AGPL-3.0, stated in the README and present as a LICENSE file at the repository root. The practical consequence, and this is not legal advice, is that running a modified Tape as a network service brings the copyleft obligations into play for users interacting with it over a network. If you plan to fork and host, read the licence with your own counsel rather than assuming a permissive outcome.

Upgrade cost is harder to estimate from what is available. There is no changelog, no migration guide, and no stable tag, so moving between releases means diffing commits. The repository does include tooling that lowers the day-to-day cost: biome.json at the root, a biome:check script that runs biome check . followed by a typecheck across all packages, and a Husky prepare hook. Those give you a fast way to see whether your changes still typecheck across the workspace, which is more than many monorepos offer.

What you cannot get is a support commitment. The README points to Discord for discussions and help, and to a Contributing Guidelines file before opening an issue or pull request. That is community support, not a maintenance contract.

Editorial conclusion

Tape is worth evaluating if you want a working reference implementation of a Lens-backed video frontend and are comfortable reading a pnpm monorepo rather than a deployment guide. Skip it if you need a documented self-hosting path, a stable tagged release, or a general-purpose video CMS: the latest tag is v2.0.3-beta from 2024-07-25 and the README documents no production install. Verify first that pnpm install and pnpm dev bring up http://localhost:4783, and check the apps/api and apps/cron configuration before assuming anything about how uploads or background jobs are wired.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tapexyz/tape on GitHub