Invidious: interface, media paths and operational responsibility
Operating Invidious: instance trust, separate secrets and layered health checks
Audit data paths and operational boundaries without equating a privacy-oriented interface with anonymity or a complete security assessment.
What you will learn
- Write down who can observe which data
- Keep signing, companion authentication and network exposure distinct
- Monitor failures at the boundary that actually failed
Before you start
- Basic HTTP and container concepts
- Ability to distinguish application state from media traffic
Explain the dependency and trust boundaries, prepare a verifiable trial and interpret source/model evidence without overclaiming.
Key takeaways
- The page hostname does not establish all media or logging paths.
- HMAC and companion keys serve different relationships.
- Readiness, application health and actual playback need separate checks.
Write down who can observe which data
The FAQ distinguishes application behavior from what an instance owner can log, and describes account history/subscriptions stored in the server database. A reverse proxy and hosting provider introduce additional operational boundaries. State a retention policy that matches the deployed system, and treat exported history or diagnostic URLs as potentially sensitive rather than harmless support attachments.
Media privacy needs separate verification. The FAQ’s direct-versus-proxy explanation and the companion public_url option show why the visible page hostname alone is insufficient evidence. On your own authorized deployment, inspect browser requests and the edge topology before making a claim. This article did not capture user traffic, test public operators or certify anonymity.
Keep signing, companion authentication and network exposure distinct
The HMAC key is documented for signing-related application functions; the companion key protects the separate companion relationship and must satisfy the configured length requirement. The installation guide says not to reuse the HMAC key as the companion key. Keep real values out of repositories, screenshots, resolved Compose output and article examples, and consider both components when rotating the companion secret.
The documented companion service drops capabilities, uses a read-only root filesystem and retains a specific writable cache mount. Those are useful defense-in-depth settings, not proof of a complete sandbox or vulnerability-free service. Keep PostgreSQL private, review any browser-facing companion route and preserve TLS at the edge. Do not respond to a failed test by disabling certificate checks.
Monitor failures at the boundary that actually failed
A database readiness check, a stats endpoint and a successful known-video playback test answer different questions. The inspected companion route streams upstream response status, headers and body, while rescue blocks in that file do not themselves supply a detailed diagnostic response. Review surrounding logging and error handling before assuming a failure will be automatically visible or actionable.
Before upgrades, record image digests, backup state and a tested restoration procedure. Provider restrictions and upstream changes can break service independently of an application process staying alive. This is an operational checklist, not a penetration test or legal compliance opinion. No credentials were generated, public service probed for weaknesses or user database accessed during this review.
Implementation steps
- 1
Map operators, logs, account data and media endpoints.
- 2
Keep keys distinct and restrict internal service exposure.
- 3
Test readiness, stats and permitted playback separately.
- 4
Rehearse backup restoration and record precise upgrade boundaries.
Copy-ready example
{
"controlsToVerify": ["private database", "distinct secrets", "TLS edge", "log retention", "restore test"],
"anonymityCertified": false,
"penetrationTestExecuted": false,
"userDataAccessed": false
}Frequently asked questions
Does a read-only companion filesystem prove it is fully sandboxed?
No. It is one defense-in-depth control alongside capabilities, mounts, network exposure and application behavior.
Should health monitoring stop at the stats endpoint?
No. Add separate, authorized playback and persistent-state checks with clear failure attribution.
Sources
- invidious/config/config.example.ymlSource checked 2026-09-08
- invidious/src/invidious/routes/companion.crSource checked 2026-09-08
- documentation/docs/installation.mdSource checked 2026-09-08
- documentation/docs/faq.mdSource checked 2026-09-08