01 / THE ROLE
In this lab.
FreshRSS was evaluated in UAT and promoted into the application environment. It uses persistent Docker volumes and SQLite. Scheduled refreshes collect subscribed feeds, while Homepage displays a compact subscription and unread summary instead of duplicating the reader interface.
02 / THE CONNECTIONS
Follow the flow.
A responsibility view: branches show related components, rather than physical placement or a single request path.
03 / How it works
How it works.
The reader periodically fetches feed updates and stores reading state. The application UI is used to browse entries; a separate API-backed integration supplies the Homepage summary. Refreshing external feeds and serving the local interface are distinct behaviours.
04 / Persistent data & recovery
Persistent data & recovery.
Protect the subscription list, preferences and reading state according to their value. Recovery needs the persistent application data, not merely the image. Public examples use neutral feed content and never reveal private subscriptions or user details.
05 / How to check it
How to check it.
Production onboarding included a Zabbix HTTPS scenario with expected status, FreshRSS identity and latency, plus dynamic dashboard integration. To validate function more deeply, check an actual refresh and a known feed entry; a frontend probe does not prove every external feed is current.
06 / Decisions & limits
Decisions & limits.
The application was chosen after a different dashboard experiment did not fit the reading workflow. Keeping the reader dedicated and exposing only a compact summary in Homepage makes their responsibilities clearer.