Notifinho v2.4.0
Notifinho v2.4.0 release notes
Integrations replace discovered sources
The Sources page now presents the complete built-in integration catalogue.
Each integration expands to show its available SMTP, HTTP, or Redfish inputs.
Integrations are always available and no longer expose status, removal controls,
or internal parser identifiers.
Input-aware routes
Route add/edit uses labelled choices such as Zabbix (SMTP), Zabbix (HTTP),
Generic (HTTP), and Generic (Redfish). The route keeps the existing source key
for parser compatibility and adds an explicit input type.
Safe destination changes
Destination display names are unique across all output types. Duplicate names
return HTTP 409 before YAML is changed. Destination type changes require fresh
credentials, update every YAML route reference, preserve the destination ID and
history, and roll back on synchronization failure.
Upgrade
Create state and configuration backups, deploy the v2.4.0 image, and start the
container with the existing mounted config.yaml, state, secrets, and logs.
Schema 7 adds a route input column and the private integration category table.
The first synchronization imports known legacy source categories into SQLite,
removes source visibility metadata from YAML, and removes the test-only route
named Home Lab Generic.
HTTP and HTTPS access
The same-origin WebUI continues to use the configured HTTP listener. Direct
HTTP remains suitable only for trusted networks. Public or untrusted access
must terminate TLS at a trusted reverse proxy and enable HTTPS enforcement and
secure cookies.
Direct managed-mount deployment
Managed NFS/SMB backup mounts remain opt-in and require the existing deployment
override. The integrations migration does not change backup target paths,
mount capabilities, or scheduled-backup behavior.
Compatibility and rollback
Existing destinations, routes, credentials, filters, and delivery history are
preserved. Route input is inferred conservatively for legacy entries. Every
WebUI YAML mutation creates a backup and uses an atomic replacement that keeps
the original file owner and mode. Failed synchronization restores the previous
config.yaml. To roll back the application, stop v2.4.0, restore the state and
configuration backups created before deployment, and start the previous image.
Acceptance
Complete docs/v2.4.0-acceptance-checklist.md in the isolated VM-09 container
before production deployment.