Great tool really solves the "keep dozens of homelab services around without running them 24/7" problem cleanly. Ran into three related issues while running it in front of a Radarr/Sonarr/Prowlarr/Jellyseerr stack (behind NPM + Cloudflare Tunnel), all stemming from how activity/wake is detected via access-log streaming. Wanted to document them together since they're all the same root category of gap.
1. Idle timer doesn't reset during active use if the app relies on a persistent WebSocket connection
Radarr/Sonarr's UI uses SignalR, which opens a long-lived WebSocket for live updates. Nginx typically only logs an access-log line when a connection is established (or closes), not on every message sent over an already-open WebSocket. Result: if a user sits on the dashboard actively watching live updates, no new access-log lines are generated, so the idle reaper doesn't see it as "active" and can still stop the container mid-session.
Repro: open Sonarr's dashboard, leave it open without navigating, tail arr-proxy's access log — you'll see the initial page-load requests, then silence, even though the SignalR connection is still live and updating the UI.
2. Container-to-container traffic (bypassing the proxy) never resets the idle timer or triggers a wake
When one on-demand service needs to call another directly over the Docker network (e.g. Jellyseerr calling Radarr's API to add a movie, or qBittorrent notifying Radarr on download completion), that traffic never passes through arr-proxy, so the log watcher never sees it. If the target container is asleep, the request just gets connection-refused — silently. In our case, the workaround was pulling the "backend automation" containers out of on-demand entirely and only keeping the user-facing app (Jellyseerr) on-demand, but for anyone relying on group to handle inter-service dependencies, this is a real gap grouped containers still won't wake for background service-to-service calls that don't go through the reverse proxy.
3. Loading page redirects before the reverse proxy's own config regeneration catches up, causing a 502 flash
With nginx-proxy (docker-gen based), when the target container is marked "running" and passes ondemand's own readiness probe (backend responding), the loading page redirects immediately. But docker-gen needs a moment after container start to regenerate its own vhost config and reload nginx. There's a small window where ondemand correctly says "ready" but nginx-proxy itself doesn't have the route yet, so the redirect lands on a 502 before a manual refresh resolves it a second later.Possible fix: after the readiness probe passes, either add a short additional delay/retry loop client-side in the loading page's redirect logic before navigating, or have ondemand itself verify a request through the actual proxy (not just the backend) succeeds before signaling ready.
Happy to provide more logs/configs if useful — really appreciate the tool, these are all edge cases in an otherwise really well-designed setup!
Great tool really solves the "keep dozens of homelab services around without running them 24/7" problem cleanly. Ran into three related issues while running it in front of a Radarr/Sonarr/Prowlarr/Jellyseerr stack (behind NPM + Cloudflare Tunnel), all stemming from how activity/wake is detected via access-log streaming. Wanted to document them together since they're all the same root category of gap.
1. Idle timer doesn't reset during active use if the app relies on a persistent WebSocket connection
Radarr/Sonarr's UI uses SignalR, which opens a long-lived WebSocket for live updates. Nginx typically only logs an access-log line when a connection is established (or closes), not on every message sent over an already-open WebSocket. Result: if a user sits on the dashboard actively watching live updates, no new access-log lines are generated, so the idle reaper doesn't see it as "active" and can still stop the container mid-session.
Repro: open Sonarr's dashboard, leave it open without navigating, tail arr-proxy's access log — you'll see the initial page-load requests, then silence, even though the SignalR connection is still live and updating the UI.
2. Container-to-container traffic (bypassing the proxy) never resets the idle timer or triggers a wake
When one on-demand service needs to call another directly over the Docker network (e.g. Jellyseerr calling Radarr's API to add a movie, or qBittorrent notifying Radarr on download completion), that traffic never passes through arr-proxy, so the log watcher never sees it. If the target container is asleep, the request just gets connection-refused — silently. In our case, the workaround was pulling the "backend automation" containers out of on-demand entirely and only keeping the user-facing app (Jellyseerr) on-demand, but for anyone relying on group to handle inter-service dependencies, this is a real gap grouped containers still won't wake for background service-to-service calls that don't go through the reverse proxy.
3. Loading page redirects before the reverse proxy's own config regeneration catches up, causing a 502 flash
With nginx-proxy (docker-gen based), when the target container is marked "running" and passes ondemand's own readiness probe (backend responding), the loading page redirects immediately. But docker-gen needs a moment after container start to regenerate its own vhost config and reload nginx. There's a small window where ondemand correctly says "ready" but nginx-proxy itself doesn't have the route yet, so the redirect lands on a 502 before a manual refresh resolves it a second later.Possible fix: after the readiness probe passes, either add a short additional delay/retry loop client-side in the loading page's redirect logic before navigating, or have ondemand itself verify a request through the actual proxy (not just the backend) succeeds before signaling ready.
Happy to provide more logs/configs if useful — really appreciate the tool, these are all edge cases in an otherwise really well-designed setup!