-
-
Notifications
You must be signed in to change notification settings - Fork 78
Advanced Customization
This page covers the advanced knobs that are useful for technical self-hosting users, without turning the wiki into an internal engineering manual.
Use this page when you want to:
- run PigeonPod behind a reverse proxy
- disable built-in auth safely
- use an outbound proxy for YouTube API and yt-dlp
- switch storage strategies intentionally
- tune yt-dlp behavior
- build your own container image from source
This page is for customization and deployment control, not for deep architecture design.
Before using this page, you should already have:
- a working Docker-based PigeonPod deployment
- admin access to User Settings
- enough comfort with Docker, networking, and logs to validate your changes
If not, start with Installation and Quick Start.
Running PigeonPod behind a reverse proxy is useful when:
- you want HTTPS
- you want a stable public or private domain
- you want to place access control in front of the app
Important rules:
- set the correct Base URL in PigeonPod
- make sure
/api,/media, and RSS routes remain reachable - verify media playback still works after proxying
Good use cases:
- private domain on a home server
- internal access behind a VPN
- HTTPS termination at the proxy layer
Common mistake:
- the proxy works for the web UI, but media or RSS links break because the Base URL or forwarded routing is wrong
If you change proxy behavior, always re-test:
- login
- one feed page
- one RSS link
- one media playback link
PigeonPod enables built-in authentication by default. This is the correct choice for most users.
Only disable built-in auth if another trusted layer already protects the instance, such as:
- an auth proxy
- a reverse proxy with strong access control
- VPN-only access
- a private network that is already controlled
Example environment variable:
PIGEON_AUTH_ENABLED=false
Do this only when you are certain the instance is not directly exposed.
Unsafe pattern:
- auth disabled
- public Internet exposure
- no other access control in front
That is not an advanced setup. It is a security error.
PigeonPod supports an outbound proxy for:
- YouTube Data API requests
- yt-dlp download requests
Use this when:
- your network cannot reach upstream services reliably
- you need a different egress region
- your host environment requires a proxy
Supported proxy types:
- HTTP/HTTPS
- SOCKS5
Important Docker note:
- if PigeonPod runs in Docker and your proxy runs on the host, do not use
127.0.0.1 - use
host.docker.internalor your host LAN IP
Practical workflow:
- enable the proxy in settings
- save the configuration
- run the built-in proxy tests
- verify both YouTube API and yt-dlp succeed
If only one test passes, treat that as a partial failure and keep debugging.
PigeonPod supports LOCAL and S3 storage modes.
Switching storage can be a valid advanced move when:
- local disk is no longer the right fit
- you want object storage for operational reasons
Important limitation:
- switching storage mode does not migrate old media automatically
That means:
- new tasks may use the new storage mode
- old files may stay where they were unless you migrate them yourself
Safe workflow:
- back up your data
- confirm the target storage works with the built-in test
- plan media migration separately
- only then switch modes
If you switch casually, old episodes may become inaccessible.
PigeonPod allows custom yt-dlp arguments for advanced cases.
Use this only when:
- you have a specific upstream compatibility problem
- you know what the argument does
- you are prepared to remove it if downloads start failing
Do not use custom yt-dlp arguments as a first-line tuning tool.
Good mindset:
- default first
- small, deliberate override second
- remove the override first when debugging
If downloads become unstable after adding custom arguments, assume the custom arguments are guilty until proven otherwise.
PigeonPod can manage the yt-dlp runtime under /data.
This is useful when:
- upstream sites change behavior
- a newer yt-dlp version fixes extraction issues
- you want controlled updates from the UI
Important behavior:
- the managed yt-dlp runtime survives container recreation because it is stored under
/data - updating the app image and updating yt-dlp are related but different actions
Practical advice:
- do not update yt-dlp blindly on a stable setup
- update it when you have a real reason, then verify one known-good download
If you want to patch PigeonPod or test your own changes, build your own image from the repository root.
The project already includes a multi-stage Dockerfile that:
- builds the frontend
- packages the backend
- creates the runtime image
Basic local build:
docker build -t pigeon-pod:local .Then update your compose file to use:
pigeon-pod:local
Use this when:
- you changed source code
- you want to validate a patch before pushing it
- you need a custom image for your own deployment
If you need to go beyond deployment customization and actually change behavior, the wiki should stop being your primary source.
For deeper work, go to the repository docs:
Those documents are better suited for:
- architecture understanding
- implementation planning
- extension work
- code-level reasoning
If you are not sure, it is not private enough. Keep built-in auth enabled.
That usually means:
- the proxy config is only partially correct
- YouTube API and yt-dlp are behaving differently through that proxy
Use the built-in tests and debug them separately.
That usually means media migration was skipped. The storage switch itself does not move historical files for you.
Remove the custom arguments first. Advanced overrides increase the debugging surface.
Repository · Releases · Issues · Discussions
Security note: Do not expose an auth-disabled PigeonPod instance directly to the public Internet.