01 / THE ROLE
In this lab.
The documented stack includes Firefly III, a data-importer component and a scheduled component, with MySQL as the database engine and persistent application storage. This page explains the deployment pattern, not the private financial records or the identity of any account.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Input or import
- STEP 02Firefly application
- STEP 03MySQL & files
- STEP 04Private reports
03 / How it works
How it works.
The core application stores and presents financial information. The importer is a separate component that helps bring external input into the application, and scheduled work has its own execution path. A functioning core page does not prove an import or scheduled operation completed.
04 / Persistent data & recovery
Persistent data & recovery.
Database contents, relevant files and application configuration form the recovery set. Required encryption or integration material must be available through the secure recovery procedure. The public site contains no transaction examples taken from real data.
05 / How to check it
How to check it.
Validate frontend identity separately from an authorised functional operation. For an isolated restore test, use neutral records and disable external side effects before checking an import path. Never validate by exposing real reports in screenshots.
06 / Decisions & limits
Decisions & limits.
An application with several cooperating components needs acceptance checks for each meaningful workflow. The database, importer and scheduler should not disappear behind a single container-health indicator.