Content

Content

Turn URLs, files, and text into media, knowledge, and documents.

One self-hosted engine. HomeTube client for YouTube — Content Studio for everything else — HomeTube browser extension — MCP server — CLI — Typed SDK — REST API underneath them all

Quick start · HomeTube · Coming from HomeTube? · All the clients · Connect an agent · Read the docs

Content is a self-hosted engine that turns supported sources into media, transcripts, summaries, translations, images, metadata, Markdown, PDF, and more. The backend analyzes each source, determines what it can actually produce, plans and runs the job, records its history, and delivers the results.

Everything else is a client of one public contract: HomeTube for the focused YouTube experience, Content Studio for general workflows, a Chromium extension for the tab you are already on, the `content-mcp` server for agents, a CLI for terminals and cron, a typed Python SDK for applications, the REST API for every other language, and Content Console to watch the engine work. Pick one or several — none of them is a layer the others have to pass through, and none of them holds business logic of its own.

HomeTube is the quickest way to see what that means: paste a YouTube URL, pick what you want out of it, and watch the files land in your library.

HomeTube in Content — paste a YouTube URL, choose what you want, follow the job into your library. More about HomeTube ↓

[!NOTE]

A proven workflow, now growing into a platform. The standalone

HomeTube container has passed

300,000 package downloads on GitHub Container Registry. It keeps running

and stays maintained — nothing breaks, and there is no deadline. Content is

where that work continues, and where its users are invited to move at their

own pace.

The two are separate projects: standalone HomeTube has not been retrofitted to

run on Content. The **HomeTube app in this repository is a new UI on the

Content engine**, carrying the same workflow forward.

Coming from standalone HomeTube? ↓

Quick start

Docker Compose is the only runtime prerequisite. Install from the published images — nothing to clone or build:

mkdir content && cd content

curl -fsSLO https://raw.githubusercontent.com/LatentNoise/content/main/deploy/docker-compose.yml curl -fsSL -o .env https://raw.githubusercontent.com/LatentNoise/content/main/.env.example docker compose up -d

The default .env starts the complete local stack:

Open Content Studio for the general workflow, or HomeTube if your source is YouTube. You can also skip both web apps entirely and drive the same engine from the MCP server, CLI, SDK, extension, or REST API.

Everything stays in the installation folder: ./data holds the database, jobs, and artifacts; finished files are delivered to ./playground/output. Set CONTENT_DELIVERY_DIR_HOST in .env to point at your own NAS or media library instead — its sub-folders then become the destination choices offered in the clients.

Update later with:

curl -fsSLO https://raw.githubusercontent.com/LatentNoise/content/main/deploy/docker-compose.yml

docker compose pull && docker compose up -d

The first line is not optional, and it is the one that is easy to skip. docker compose pull refreshes the images; the stack definition is the local copy you downloaded on day one, and new settings arrive in *it* — a container receives only what its environment: block names. A compose file left at its original version therefore keeps silently dropping every setting added since, however correctly you write it in .env. Your .env is yours and is never touched; compare it against the current .env.example when you want the new knobs.

Build from source instead — for development or to include the optional speech-to-text runner

git clone https://github.com/LatentNoise/content.git

cd content cp .env.example .env docker compose up -d --build

The repository's docker-compose.yml adds local build: definitions beside the same images. deploy/docker-compose.yml is the build-free deployment file used above; a test keeps the two aligned.

One source, many artifacts

The same engine serves media and document workflows:

                             ┌─ My Conference.mp4

├─ My Conference - audio.opus YouTube URL ──→ Content ─────┼─ My Conference - subtitles - en.srt ├─ My Conference - subtitles - fr.srt ├─ My Conference - transcript.txt ├─ My Conference - summary.md └─ My Conference - summary.pdf

Web page / text / .md file ──→ Content ──┬─ Article.txt ├─ Article - summary.md ├─ Article - translation.md └─ Article.pdf

Each branch starts with a declarative request. You describe the results; Content resolves what is possible, plans the work, runs the available tools, and records where every artifact came from. No yt-dlp flags, ffmpeg pipelines, transcription glue, or LLM orchestration in the client.

The clients

One engine, one contract, several independent front doors. Every client below speaks the same GenerationRequest, sees the same resolved capabilities, and produces the same artifacts — they differ in ergonomics, not in what they can ask for. HomeTube is entirely optional; so is every other row.

HomeTube — YouTube, focused

http://localhost:8501 · README

Paste a URL, choose the media and related artifacts, and follow the job into your library — the workflow demonstrated at the top of this page.

With HomeTube in Content, you can:

• download a video or playlist as video or audio, with quality, codec, container, audio-language, and subtitle choices;
• remove or mark sponsored segments with SponsorBlock, cut clips, use server-side cookie credentials, and embed subtitles, chapters, thumbnails, and metadata;
• give every artifact a readable name and deliver it into a filesystem library watched by Plex, Jellyfin, or Emby;
• ask the same source for a transcript, summary, thumbnail, or metadata — not just the downloaded media — when the required runners are available.

HomeTube is deliberately focused: it does not accept file, upload, or inline-text sources, and it does not expose the broader document workflow or PDF output. For those, use Content Studio, the API, CLI, or SDK. HomeTube is a Content client, not a layer every Content user must pass through.

It has no settings of its own. It reads the engine's configuration, so what changes HomeTube lives in the .env beside your docker-compose.yml: the delivery library whose sub-folders become the destination choices (CONTENT_DELIVERY_DIR_HOST), the languages pre-selected for audio and subtitles (CONTENT_LANGUAGE_PRIMARY, CONTENT_LANGUAGES_SECONDARIES, CONTENT_VO_FIRST, CONTENT_LANGUAGE_PRIMARY_INCLUDED_IN_SUBTITLES), and the server-side cookie file that unlocks age-restricted or members-only videos (CONTENT_CREDENTIALS — HomeTube only ever shows its id; the file never leaves the server). Nothing is ever pre-selected that the source does not offer, and no default is final.

[HomeTube's README](apps/web-hometube/READ