* fix(playback): route v3 direct play and remux through proxy nodes
Protocol v3 consulted the node planner only for the HLS deliveries, so
`original_http` and `server_remux_progressive` sessions returned an
API-local `/stream/{session_id}` URL and the API node served the bytes —
ServeDirectPlay for direct play, a locally spawned ffmpeg for the remux.
An operator running dedicated proxy nodes still saw all of that egress on
the API node.
The capability already existed: the proxy implements /stream/direct and
/stream/remux, and the Jellyfin-compat transport already plans a proxy for
exactly these two methods. Native v3 was the only surface skipping it, so
Jellyfin clients routed correctly on a deployment where Silo's own clients
did not. This wires the same shape into the v3 identity transport rather
than inventing a second selection path.
The proxy serves from the stream token alone, so the token now carries the
media path, the file's Dolby Vision profile (a P7 remux must strip the
dangling RPU) and the audio-only flag (which picks audio/mp4 over
video/mp4, the MIME the plan promised). RecipeCard models none of the
three; a missing claim would not fail loudly, it would serve a subtly
different stream than the plan promised.
Two related fixes:
- Proxy direct play served via http.ServeFile, which sets no strong ETag.
direct_stream_resume_v1 depends on the ETag ServeDirectPlay sets before
ServeContent, so routing direct play to a proxy without this would have
silently broken resumable direct streams: If-Range never validates and a
resumed range restarts at 200. The proxy now uses the same serve path.
- playback.local_transcode_fallback was only checked in the HLS branch, so
a progressive remux that converts audio still spawned ffmpeg locally on
an API-only node with the setting disabled. Identity deliveries now
honor the gate too — direct play still falls back locally, since moving
bytes is not transcode work and single-node deployments must keep
working.
Falling back to the API-local path when no proxy is eligible preserves
single-node behavior, and a planner reservation is released whenever the
session does not actually reach a proxy.
Closes #619
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(playback): validate proxy recipes and keep proxy sessions alive
Addresses three P1 findings on the proxy-transport change.
Proxies do run ffmpeg — /stream/remux converts audio and strips Dolby
Vision RPUs — but they exposed no capability endpoint, so unlike the HLS
offload path nothing checked that the selected proxy could execute the
transformations a plan froze. A pool whose proxies carry a different
ffmpeg build (rolling upgrade, custom image) would fail at stream time: a
missing aac encoder 500s, a missing dovi_rpu filter is refused outright by
the remux itself. Proxies now serve /hw-capabilities in the same shape and
at the same path as a transcode node, and identity planning validates the
frozen recipe against the selected proxy, falling back to a node that can
do the work. A proxy that does not answer is treated as incapable rather
than assumed good: an older proxy predating the endpoint is exactly the
mismatched build the check exists to catch. Direct play copies bytes and
needs no recipe, so it skips the probe entirely.
meteredResponseWriter implemented neither Unwrap nor SetWriteDeadline, so
RollingDeadlineWriter could not install its stall deadline on any proxy
stream. With the standalone proxy running WriteTimeout 0 there was no
server-level guard behind it, so a client that stopped reading without
closing its connection would block a write forever, holding the session,
the file, the goroutine and the connection.
A proxy-served session never produces a transport request on the API node,
so activeTransportCount — what protects a local stream from the idle
reaper — stays zero and a heartbeat gap longer than the active grace would
reap a healthy stream, after which progress, stop and replan all fail with
session-not-found while bytes still flow. Sessions are now marked as
remotely transported, which widens their idle windows rather than granting
immunity: this manager has no absolute session lifetime, so unconditional
immunity would leak a session forever when a client disappears without
stopping. The mark is always set on commit, so a re-plan that moves a
session back onto the API clears a stale one.
Also adopts the exported transformation constants in the tests and covers
the effective-recipe bitrate branch, per review.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(playback): pick capable sibling proxies and refresh transport locality
Narrow proxy selection by capability *before* selection rather than
rejecting a single round-robin pick afterwards. Abandoning the pool on one
mismatch meant a capable proxy with free capacity sat unused while
playback either ran ffmpeg on the API node or, with
playback.local_transcode_fallback disabled, was refused outright — the
exact api/proxy split this branch targets, during exactly the rolling
ffmpeg upgrade the capability check exists for. PlanSessionWith now
applies its eligibility predicate to the proxy on proxy-only plans (the
proxy is the executor there), mirroring how HLS filters transcode nodes,
and the planner grows ProxyNodeURLs to match TranscodeNodeURLs. Direct
play still skips the probe: it copies bytes and needs no recipe.
Every committed route now records transport locality, not just the
identity-proxy one. A session replanned from a proxy onto the integrated
transcoder previously kept a stale remote-transport mark, and the widened
idle grace it grants would hold that session's stream and transcode slots
for five minutes after the local stream disconnected without an explicit
stop. The remote HLS route sets it too — it also hands the client an
absolute proxy URL that never reaches this server.
The proxy's CORS config exposed no response headers, so cross-origin
JavaScript could send the If-Range/Range request headers it already allows
but never read the ETag, Accept-Ranges or Content-Range needed to build
them. direct_stream_resume_v1 silently degraded to a full restart whenever
the proxy was on a different origin than the web app, which is the normal
deployment.
Also regenerates internal/playback/testdata/protocol_v3 and the schema
fixtures, which were stale for output_change_v1 since #613/#617 and failed
CI on every branch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(playback): restore the alternate-version fallback for burn-in refusals
#617 renamed the terminal a burn-in-forced adaptation reports: when the
subtitle burn requirement is the sole trigger, an HDR source that cannot
be re-encoded now returns subtitle_conversion_unsupported instead of
hdr_transcode_unsupported, so the refusal names the thing the viewer can
actually act on.
terminalAllowsAlternateFileV3 was not updated to match, and it gates the
alternate-version retry on the old reason strings. That silently retired
the fallback for exactly the case its own comment describes — a bitmap
subtitle needing burn-in that an HDR source cannot support while an SDR
alternate can. Playback was refused outright instead of switching to the
version that can serve it.
Adds the new reason to the gate and covers it directly, so a future
rename of a refusal reason fails on the gate rather than only on the
end-to-end replan test.
Also drops debug instrumentation that was committed by mistake in
TestHandleReplanPlaybackV3BitmapSubtitleFallsBackFromHDRToSDRVersion; the
assertion is back to its original form and now passes on the merits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Silo
Silo is a self-hosted media streaming server for your movies, shows, music, and books. Point it at your media folders and stream to your devices — at home or away — with direct play, remuxing, and hardware-accelerated transcoding handled automatically.
Join the community on Discord. If Silo is useful to you, consider sponsoring the project — see Supporting Silo.
Highlights
- Plays your media, your way — direct play when the device supports it, remux or hardware-accelerated transcode (including NVENC) when it doesn't.
- Web app included — a full-featured web client and admin interface ship with the server.
- Works with apps you already use — optional Jellyfin/Emby-compatible API supports clients such as VidHub, Findroid, and Infuse.
- Household profiles — multiple profiles per account, with per-profile watch state and parental controls.
- Plugin-driven metadata — match and enrich your libraries with providers like TMDB and TVDB, installed as plugins.
- Fast setup — one
docker compose up -dbrings up the whole stack; everything else is configured in the admin UI.
Deploy with Docker (recommended)
The easiest way to run Silo is with Docker Compose 2.24 or newer. The default stack assumes you do not already have PostgreSQL and Redis available, so it bundles PostgreSQL, Redis, FFmpeg, and the application for a one-command start.
-
Create a
.envfilecp .env.example .env printf '\nPOSTGRES_PASSWORD=%s\nSECRET_KEY=%s\n' \ "$(openssl rand -hex 24)" "$(openssl rand -base64 48)" >> .envThis replaces the development database password from
.env.exampleand creates the key Silo uses to encrypt stored credentials. Back up.envseparately from PostgreSQL; losingSECRET_KEYmakes those credentials unrecoverable. -
Set your media path
Edit
.envand set:MEDIA_ROOT=/path/to/your/mediaMEDIA_ROOTis the one value most users need to change. You can also overrideSILO_DATA_ROOTif you do not want bind mounts under/opt/silo, and change ports if the defaults conflict with something else on the host. -
Start the default integrated stack
docker compose up -dThis starts PostgreSQL, Redis, and the integrated Silo server. The app is available at
http://localhost:8090. Jellyfin-compatible app support is disabled until an administrator enables it in onboarding or admin settings.If you already have PostgreSQL and Redis available, omit those bundled service examples from compose and point Silo at your existing
DATABASE_URLandREDIS_URLinstead.Optional Intel/AMD VA-API or Intel Quick Sync
The default stack is CPU-only so it starts on hosts without
/dev/dri. On a Linux host with/dev/dri, enable the device overlay:docker compose -f docker-compose.yml -f docker-compose.vaapi.yml up -dTo make that the default for this installation, set:
COMPOSE_FILE=docker-compose.yml:docker-compose.vaapi.ymlOptional NVIDIA/NVENC
GPU support is kept out of the default compose file so hosts without NVIDIA drivers work unchanged.
Install the NVIDIA Container Toolkit and use a Docker Compose version with GPU reservation support before enabling this override.
Use the optional override file when you want NVENC:
docker compose -f docker-compose.yml -f docker-compose.nvidia.yml up -dIf you want this controlled from
.env, setCOMPOSE_FILE:COMPOSE_FILE=docker-compose.yml:docker-compose.nvidia.yml NVIDIA_GPU_COUNT=1Windows uses
;instead of:between compose files.Then
docker compose up -dwill include the NVIDIA override automatically. -
Configure through the admin UI
Add libraries, users, metadata providers, and playback settings from the web interface.
Bind Mount Layout
The deploy-oriented compose files use host folder mappings rather than Docker-managed volumes.
By default, data is stored under /opt/silo:
/opt/silo/postgres/opt/silo/redis/opt/silo/plugins/opt/silo/compat/opt/silo/transcode/opt/silo/catalog-seeds
The optional search profile also stores its index under /opt/silo/meilisearch.
Media is mounted into the container at /mnt/media from the host path you set in MEDIA_ROOT.
Optional Search Profile
PostgreSQL full-text search works without any optional services. Meilisearch is available when you want its search provider:
| Profile | Command | Description |
|---|---|---|
| default | docker compose up -d |
Integrated server plus bundled PostgreSQL and Redis |
search |
docker compose --profile search up -d |
Add the optional Meilisearch service |
Before starting the search profile, set MEILI_MASTER_KEY in .env to the output of
openssl rand -hex 32. After Silo starts, choose Meilisearch under Admin > Settings > Search,
set the URL to http://meilisearch:7700, enter the same key as the API key, test the connection,
and save. Restart Silo, then rebuild the catalog search index from the same page. Silo continues
to use PostgreSQL full-text search until you select Meilisearch.
Distributed Examples
The main Compose file includes commented proxy and transcode service examples. Most single-host installs should leave them commented because the integrated service already includes proxying and transcoding.
Multi-host operators can use those examples as a starting point for a dedicated worker Compose file connected to the deployment's shared PostgreSQL and Redis services.
Proxy nodes serve source downloads from the same absolute media paths used by direct playback.
Prepared-download work can also run on transcode nodes. Each selected transcode node retains its
result on node-local storage and exposes it only through Silo's authenticated internal artifact API;
the paired proxy relays those bytes, so no shared artifact mount is required. Dedicated transcode
nodes default to retaining prepared downloads in a protected directory inside the transcode volume
captured at process startup. download.artifact_dir overrides that location for both dedicated
transcode nodes and the integrated/API-local fallback, so mount the configured path on every process
that prepares downloads. Changing either artifact-path setting requires a restart. Downloads with a
configured server-wide or per-user bandwidth limit remain API-local so those aggregate limits stay exact.
Clients discover distributed delivery through proxy_delivery on the download capability response.
When it is true, they may opt into GET or HEAD /api/v1/downloads/{id}/file-proxy and
/api/v1/direct-download-proxy; those routes may return a temporary redirect to a proxy node. The
established /file and /direct-download routes keep serving bytes directly with their existing
status-code contract; for a node-local prepared artifact, the API itself performs the authenticated
relay on that fallback route.
Deployment Notes
The default compose stack intentionally bundles PostgreSQL and Redis for ease of setup and assumes a fresh install without those services already available. If you already operate PostgreSQL and Redis, omit those examples from compose and point Silo at your existing infrastructure instead. For serious installs, PostgreSQL is better on a separate VM or a managed service so upgrades, tuning, and backups are isolated from the app host. Redis can stay local for many installs, but externalizing it is also reasonable if you already operate shared infrastructure.
Silo is externally stateful by default rather than fully stateless. Durable application state lives in PostgreSQL. Redis only stores coordination and cache-style data. Silo still writes transient transcode output locally under /tmp/silo-transcode. If you switch userdb.backend=sqlite, Silo also becomes locally stateful at /var/lib/silo/userdb.
Migrating an existing Continuum Docker install should be done with the preflight helper and cutover guide in docs/continuum-to-silo-docker-migration.md.
Configuration
Silo requires DATABASE_URL and SECRET_KEY when running from source or against external
infrastructure. In the default Docker Compose path, the stack wires the database and Redis URLs
for you. All other settings — libraries, metadata providers, transcoding, users — are managed
through the admin UI after first launch.
Server Modes
| Mode | Description |
|---|---|
integrated |
Full server: API + frontend + scanner + transcode (default) |
api |
API server only, no local transcoding |
proxy |
Stream proxy node that connects to the shared deployment database and Redis |
transcode |
HLS and prepared-download worker node that connects to the shared deployment database and Redis |
PostgreSQL Auto-Tuning
The default Docker Compose stack does not require a checked-in postgresql.conf.
It enables Silo's pgtune-style OLTP tuning
by default:
POSTGRES_TUNE: auto
When enabled, Silo connects with DATABASE_URL and applies recommendations with
ALTER SYSTEM, which writes to PostgreSQL's postgresql.auto.conf inside the
database data directory. Reloadable settings are applied immediately with
pg_reload_conf(). Settings that PostgreSQL marks as restart-only are written
too, and Silo logs the setting names so you can restart PostgreSQL once:
docker compose restart postgres
The default Compose database user has the required PostgreSQL permissions. If
you use an external PostgreSQL server, make sure the configured DATABASE_URL
user can run ALTER SYSTEM, or set POSTGRES_TUNE=off and manage
PostgreSQL yourself.
For POSTGRES_TUNE_MEMORY=auto, Silo uses the first trustworthy memory source:
a finite Docker cgroup limit, the read-only /host/proc/meminfo mount supplied
by the bundled Compose file, then /proc/meminfo with container safety guards.
Auto-detected memory is treated as a PostgreSQL budget, defaulting to 75% of
detected RAM so Silo, Redis, plugins, transcodes, and the OS retain headroom.
POSTGRES_TUNE_DB_SIZE=auto queries pg_database_size(current_database()) and
classifies the workload by comparing the database size to that memory budget.
Optional tuning overrides:
| Variable | Default | Description |
|---|---|---|
POSTGRES_TUNE_PROFILE |
oltp |
Tuning profile. Only oltp is currently supported. |
POSTGRES_TUNE_MEMORY |
auto |
Server/container RAM, such as 8GB or 32GB; explicit values are used as-is. |
POSTGRES_TUNE_MEMORY_BUDGET_PERCENT |
75 |
Percent of auto-detected RAM used for PostgreSQL recommendations. |
POSTGRES_TUNE_CPUS |
auto |
CPU count used for worker recommendations. |
POSTGRES_TUNE_STORAGE |
ssd |
One of hdd, ssd, san, or nvme. |
POSTGRES_TUNE_DB_SIZE |
auto |
Use less_ram when the database comfortably fits in RAM, mid_ram, or greater_ram for very large databases. |
POSTGRES_TUNE_CONNECTIONS |
100 |
PostgreSQL max_connections; automatically raised if Silo's app pool is configured higher. |
POSTGRES_SHM_SIZE |
8gb |
Docker /dev/shm size for the bundled PostgreSQL container. |
Advanced operators can still supply their own PostgreSQL configuration or
override these env vars. Set POSTGRES_TUNE=off when you do not want Silo to
change PostgreSQL server settings. Settings already written with ALTER SYSTEM
remain in postgresql.auto.conf; reset those PostgreSQL parameters if you later
move fully to a custom postgresql.conf.
Build from Source
If you prefer running Silo without Docker:
-
Install prerequisites: Go 1.26.4+, Node.js 22+, pnpm 10.32.1, PostgreSQL 18 with pgvector, Redis, and FFmpeg.
-
Configure the source process
cp .env.example .env printf '\nSECRET_KEY=%s\nDATABASE_URL=%s\nREDIS_URL=%s\n' \ "$(openssl rand -base64 48)" \ 'postgres://silo:silo@localhost:5432/silo?sslmode=disable' \ 'redis://localhost:6379' >> .envChange the URLs when you use existing services instead of the bundled development defaults.
-
Start PostgreSQL and Redis (skip if you already have them running)
docker compose up -d postgres redis -
Build and run
make build ./siloThe server starts at
http://localhost:8080by default. All other settings are configured through the admin UI.
Reporting Issues
Client implementers can use the Canonical Settings API guide for contract discovery, contextual headers, remote scopes, effective reads, and the admin projection.
If you are reporting a bug, install problem, or performance issue, start with the admin workflow and reproduction steps, not Claude/Codex analysis.
Please include:
- What you were trying to do
- Exact steps you took
- What you expected to happen
- What actually happened
- What exact action is slow or broken (
save,scan,browse,import,playback, etc.) - Whether it happens every time or only sometimes
- The library, media type, filter, setting, or value involved
- Version, branch, commit, and deployment details if you know them
- Screenshots, recordings, or log snippets if relevant
If you used Claude/Codex for debugging, put that under Technical notes at the end. Suspected files, SQL output, stack traces, and root-cause theories can be helpful, but only after the workflow and repro steps are clear.
Use this template:
Goal:
Steps:
Expected:
Actual:
What is slow/broken:
Scope:
Version/branch:
Deployment:
Technical notes:
Contributing & Development
Silo is open source and contributions are welcome. See DEVELOPMENT.md for building from source in a dev workflow, running tests, database migrations, and project layout, and CONTRIBUTING.md for contribution expectations, merge request guidance, and the policy for AI-assisted submissions.
Supporting Silo
Silo is an open-source hobby project, developed in spare time and funded out of pocket. If you'd like to support development, you can sponsor via GitHub Sponsors.
Donations go directly toward the costs of building and running the project:
- AI development tooling subscriptions (Claude, Codex) used to build and maintain Silo
- Push notification relay infrastructure
- Future development costs
Sponsoring is entirely optional — Silo is and will remain free and open source. Bug reports, contributions, and feedback are just as valuable.
License & Trademarks
Silo's source code is licensed under the GNU Affero General Public License
v3.0 or later (AGPL-3.0-or-later) — see LICENSE.
The Silo name, logo, and wordmark are trademarks of Silo Media L.L.C. and are not covered by the AGPL. You're free to fork and redistribute the code, but forks and redistributions must not use the Silo brand as their identity and must remove or replace the brand assets. Publishing a Silo-branded app to an app store requires written permission. See TRADEMARK.md for what's permitted — including referential use like "compatible with Silo."