Skip to content

Project overview ​

TypeType is a set of independently built services and libraries joined by the central deployment stack. This section is for contributors, integrators, and operators who need to understand which repository owns a behavior and how a request moves through the system.

If you only want to install an instance, start with the self-hosting introduction. If you use an existing instance, see the user guide.

System map ​

The browser talks to the web container. Its bundled nginx serves the React application and forwards API, WebSocket, and playback traffic to TypeType-Server. Server is the application/API boundary behind that public web gateway; Token, Downloader, PostgreSQL, Dragonfly, and Garage are internal services.

Public repositories ​

RepositoryOwns
TypeTypeCompose stack, nginx, installer, updates, rollback, release coordination, and the central issue tracker
TypeType-FrontendReact routes, interface, settings, account flows, and playback controls
TypeType-ServerHTTP API, extraction, accounts, private user data, playback sessions, and integrations
TypeType-TokenYouTube PO tokens, player decoding, SABR metadata, subtitles, and remote-login browser sessions
TypeType-DownloaderPersistent download jobs, media transfer, muxing, and artifacts
TypeType-PlayerBrowser Media Source Extensions pipeline used by the frontend
TypeType-RPCDesktop companion that shows your playback as a Discord Rich Presence status
TypeType-SignalsOptional recommender: the home page algorithms each user picks and tunes
Docs-TypeTypeUser, operator, and project documentation
TypeType-Video/.githubOrganisation profile and shared public assets

Read Repository guide for source-tree entry points, local checks, licenses, and where a change belongs.

Important flows ​

Sources of truth ​

Use this order when documentation and implementation appear to disagree:

  1. The source and tests in the repository that owns the behavior.
  2. The central stack's current Compose and installer files, plus the frontend's bundled nginx configuration.
  3. The central issues and discussions for known behavior, operator experience, and decisions.
  4. This site for the supported workflow.

Documentation changes are verified against all three upstream sources before being presented as stable behavior. An open issue is evidence of a problem, not by itself a specification; the owning source still decides what the current version does.

Source references ​