Skip to content

Releases: Theriark/nowlert-ce

Nowlert v3.0.0

Choose a tag to compare

@FortPT FortPT released this 03 Aug 09:32
0adcfe3

Nowlert v3.0.0 release notes

Nowlert v3.0.0 finalizes the Nowlert product identity. The application, WebUI,
deployment examples, container metadata, repository, release title, and public
image coordinates use Nowlert and Theriark consistently.

Highlights

  • Product identity: Nowlert
  • Company identity: Theriark
  • Intended repository: Theriark/nowlert-ce
  • Docker Hub image: theriark/nowlert-ce
  • GitHub Container Registry image: ghcr.io/theriark/nowlert-ce
  • Development and production Compose identities use nowlert
  • WebUI update checks and public icon URLs target the Nowlert repository
  • Route migration preserves distinct generic, Redfish, and home-lab identities

Upgrade

  1. Back up config, state, secrets, logs, and external backup metadata as
    one matched set.
  2. Keep the existing v2.5.5 image available.
  3. Change the image to theriark/nowlert-ce:3.0.0.
  4. Use the documented internal /nowlert mounts.
  5. Start Nowlert and verify schema, login, destinations, routes, secrets,
    history, and real notification delivery.
  6. Keep the pre-upgrade backup until acceptance testing is complete.

Repository and registry cutover

The release workflow refuses stable publication unless it runs from
Theriark/nowlert-ce. Do not create the v3.0.0 tag while the repository remains
under FortPT/nowlert.

Before publication, verify:

  • repository transfer and rename are complete;
  • branch protections and Actions permissions are active;
  • Docker Hub credentials can push to theriark/nowlert-ce;
  • GitHub Actions can push to ghcr.io/theriark/nowlert-ce;
  • public repository and raw icon URLs resolve correctly.

Runtime contract and rollback

Nowlert 3.0.0 retains:

  • the NOWLERT_* environment namespace;
  • X-Nowlert-Token;
  • existing signature and idempotency headers;
  • existing event and platform schemas;
  • nowlert_session and nowlert_csrf;
  • nowlert.db;
  • nowlert-asset://;
  • /nowlert container paths;
  • existing backup formats;
  • database schema 9.

Rollback requires stopping Nowlert, restoring the complete matched pre-upgrade
configuration and state backup, and starting the previously pinned v2.5.5
image.

Database and configuration

No new database schema is introduced:

  • database schema: 9
  • configuration model: platform_database_v1

Acceptance

Complete
docs/v3.0.0-acceptance-checklist.md
before creating the stable tag or changing production.

Notifinho v2.5.5

Choose a tag to compare

@github-actions github-actions released this 27 Jul 13:34
99524b5

Notifinho v2.5.5 release notes

Released 27 July 2026.

Notifinho v2.5.5 is a production corrective release for Microsoft Teams
destination tests and source icons.

Microsoft Teams delivery

The v2.5.4 generic destination-test card embedded the 30,813-byte Notifinho
PNG as a Base64 data URI. The resulting JSON payload was 43,034 bytes, above
Microsoft Teams' documented 28 KiB webhook-message limit. A Teams Workflow
could return HTTP 202 Accepted before its channel-post action later rejected
the oversized message, while the WebUI incorrectly said it was delivered.

v2.5.5:

  • uses public HTTPS image URLs for Microsoft Teams source icons;
  • keeps Discord on packaged multipart image attachments;
  • checks the serialized Teams card before every legacy or platform send;
  • rejects a payload larger than 28 KiB without making a webhook request;
  • records the safe teams_payload_too_large error for destination tests;
  • identifies HTTP 202 as accepted, with delivery not yet confirmed;
  • preserves the HPE iLO image and all existing source-specific card layouts.

Release images pin NOTIFINHO_TEAMS_ICON_BASE_URL to the immutable tagged
commit. Operators may override that environment variable with another
credential-free public HTTPS directory containing the same mapped filenames.

Schema and configuration

No database migration is required. v2.5.5 continues to use schema 9 and the
platform_database_v1 configuration model. Existing config.yaml, users,
destinations, routes, secrets, preferences, backups, and history remain
compatible.

Upgrade

  1. Back up the matched config, state, and secret mounts.
  2. Deploy fortpt/notifinho:2.5.5 without changing volumes or credentials.
  3. Confirm the application reports version 2.5.5 and schema 9.
  4. Send a generic Notifinho test to Microsoft Teams.
  5. Confirm the WebUI reports HTTP 202 as accepted, not delivered.
  6. Confirm the test card appears in the configured Teams channel.
  7. Send an HPE iLO source-aware test and confirm the HPE iLO image appears.
  8. Send one Discord test and confirm its packaged source image still appears.
  9. Confirm restart count remains zero and no delivery traceback is logged.

HTTP and HTTPS access

Listener, reverse-proxy, session, CSRF, cookie, and TLS behavior are unchanged
in v2.5.5. Existing HTTP or HTTPS deployment settings do not require changes.
Teams icon URLs must remain publicly retrievable over HTTPS because Microsoft
Teams fetches them independently of the Notifinho container.

Direct managed-mount deployment

Managed NFS and SMB backup mounts are unchanged. Existing direct and
Portainer-managed deployments must retain their current volume mappings,
mount options, credentials, and backup configuration.

Compatibility and rollback

Notifinho v2.5.5 retains schema 9, the platform_database_v1 model, and the
v2.5.4 database structure. No schema backup is created specifically for this
upgrade.

Rollback to v2.5.4 is schema-compatible, but v2.5.4 reintroduces the oversized
generic Teams test and Base64 source-image behavior. Stop the container before
changing image tags. Keep the normal matched config, state, and secrets backup
until real Teams and Discord acceptance checks pass.

Notifinho v2.5.4

Choose a tag to compare

@FortPT FortPT released this 27 Jul 09:59
c5959c6

Notifinho v2.5.4 release notes

Released 27 July 2026.

Notifinho v2.5.4 is a production corrective release for Discord packaged card
icons and persistent destination test health.

Discord packaged icons

The v2.5.3 image contained every mapped icon, but the v2 platform Discord
adapter sent the formatter payload as JSON and did not invoke the packaged-file
upload path. Discord therefore received the internal notifinho-asset://...
reference and rendered a broken image.

v2.5.4:

  • resolves the exact root or padded packaged PNG selected by the formatter;
  • sends the Components V2 payload as multipart/form-data;
  • references the file through attachment://filename;
  • requests wait=true from Discord;
  • verifies that the returned message contains the uploaded attachment and that
    the Thumbnail media links to it;
  • fails closed with a safe error if the icon is unavailable or Discord does not
    retain the association.

Destination health

Destination tests now persist these safe operational fields:

  • last_test_at;
  • last_test_outcome;
  • last_test_response_status;
  • last_test_error_code;
  • last_test_safe_error.

Destination cards show the safe failure reason. Routing Flow marks the
Destination node and its incoming arrow as failed after an unsuccessful test.
A successful retest immediately restores the healthy state. The result remains
available after browser refresh and container restart.

Schema migration

v2.5.4 advances the SQLite schema from 8 to 9. Migration 9 adds nullable test
health columns to destinations; existing destinations and routes are not
rewritten. The configuration model remains platform_database_v1.

Notifinho automatically creates a schema-8 database backup before migration.
Rollback to v2.5.3 requires stopping v2.5.4 and restoring that matching backup,
because v2.5.3 rejects a schema-9 database.

Upgrade

  1. Back up the matched config, state, and secret mounts.
  2. Deploy fortpt/notifinho:2.5.4 without changing volumes or credentials.
  3. Confirm the automatic schema-8 backup exists.
  4. Confirm the application reports version 2.5.4 and schema 9.
  5. Run a real Discord test for a padded source such as Xen Orchestra.
  6. Confirm the card contains the source icon instead of a broken placeholder.
  7. Run a failed destination test and confirm Routing Flow turns red and displays
    the safe reason.
  8. Correct the destination and retest; confirm Routing Flow returns green.
  9. Run one Microsoft Teams test and verify the packaged Base64 icon still works.

HTTP and HTTPS access

Listener, reverse-proxy, session, CSRF, cookie, and TLS behavior are unchanged
in v2.5.4. Existing HTTP or HTTPS deployment settings do not require changes.

Direct managed-mount deployment

Managed NFS and SMB backup mounts are unchanged. Existing direct and
Portainer-managed deployments must retain their current volume mappings,
mount options, credentials, and backup configuration.

Compatibility and rollback

Notifinho v2.5.4 upgrades the platform database from Schema 8 to Schema 9.
Migration 9 adds nullable destination test-health columns only. The
platform_database_v1 configuration model and config.yaml structure remain
unchanged.

Before migration, Notifinho creates a schema-8 backup in the state
schema-backups directory. Rolling back to v2.5.3 requires stopping v2.5.4 and
restoring the matching schema-8 database backup. Do not run v2.5.3 against a
schema-9 database.

Notifinho v2.5.3

Choose a tag to compare

@github-actions github-actions released this 27 Jul 01:35
ebbb47b

Notifinho v2.5.3 release notes

Released 27 July 2026.

Notifinho v2.5.3 is a schema-compatible corrective release for Synology input
selection, UniFi Protect webhook compatibility, and repository-independent
notification icons.

Synology

  • Synology is available through both SMTP and HTTP.
  • Existing Synology routes without input_type continue to infer SMTP.
  • Existing DSM email and authenticated webhook parsing is retained.

UniFi Protect

  • Valid Alarm Manager envelopes are accepted when outer alarm_id is absent.
  • timestamp remains required.
  • alarm must remain a dictionary.
  • Recognized nested shape and list validation remain enforced.
  • Missing optional alarm_id becomes an empty metadata value.

Self-contained notification icons

  • Discord and Microsoft Teams icons are loaded from the Docker image.
  • Discord uploads the exact selected root or padded asset as an attachment.
  • Microsoft Teams embeds the packaged icon as a Base64 data URI.
  • Release images no longer require public GitHub raw-content availability.
  • NOTIFINHO_ICON_BASE_URL and its build argument are removed.
  • NOTIFINHO_ICON_DIR is the local-directory override.
  • NOTIFINHO_DISCORD_ICON_DIR remains a compatible Discord fallback.

Upgrade

  1. Back up matched config, state, and secret directories.
  2. Pull fortpt/notifinho:2.5.3.
  3. Change only the image tag.
  4. Start Notifinho and confirm schema 8.
  5. Confirm Synology shows SMTP and HTTP.
  6. Send real Protect, Discord, and Teams tests.
  7. Complete docs/v2.5.3-acceptance-checklist.md.

HTTP and HTTPS access

Session, listener, reverse-proxy, and cookie behavior are unchanged.

Direct managed-mount deployment

Managed NFS/SMB behavior is unchanged.

Compatibility and rollback

Schema 8 remains unchanged and platform_database_v1 remains unchanged. No database
migration runs. The normalized config.yaml bootstrap structure is unchanged. After stopping v2.5.3, direct rollback to v2.5.2 is supported.
Keep the matched pre-upgrade backup until acceptance passes.

Notifinho v2.5.2

Choose a tag to compare

@github-actions github-actions released this 25 Jul 02:46
3aa7b1f

Notifinho v2.5.2 release notes

Released 25 July 2026.

v2.5.2 completes the approved Routing Flow presentation and hardens notification icon delivery.

Routing Flow

  • Disabled flow uses a yellow typographic prohibition symbol aligned with the working arrow.
  • Destination cards show the configured destination name first.
  • The second line shows the output platform and configured channel, for example Discord · #idrac-alerts.
  • Source, route, connector, and destination health remain independently coloured.

Notification icons

  • Xen Orchestra, Grafana, TrueNAS, Portainer, Home Assistant, Supermicro, and Zabbix use padded Discord-specific images so their visible thumbnail artwork is smaller.
  • Microsoft Teams keeps the existing official asset sizing.
  • WebUI source artwork, outbound regular assets, and Discord variants are all copied into and verified inside the release image.
  • Published images use an immutable commit-addressed GitHub raw URL for outbound card artwork. NOTIFINHO_ICON_BASE_URL remains available for mirrors and branded clones.

Settings layout

The Settings page now uses the full available workspace width, aligning its
panels with the Overview page while preserving responsive integration cards
and section spacing.

Upgrade

  1. Back up the mounted config, state, and secret directories.
  2. Pull fortpt/notifinho:2.5.2.
  3. Change only the image tag in the existing Portainer stack and re-pull the image.
  4. Confirm schema 8, a clean startup, Routing Flow labels, and real Discord/Teams test cards.
  5. Complete docs/v2.5.2-acceptance-checklist.md.

HTTP and HTTPS access

Session and listener behaviour are unchanged. Direct HTTP is appropriate only on a trusted network. Public access must terminate TLS at a trusted reverse proxy and enable HTTPS enforcement and secure cookies.

Direct managed-mount deployment

Managed NFS/SMB behaviour is unchanged and remains opt-in through the existing deployment override.

Compatibility and rollback

The normalized config.yaml structure introduced in v2.5.0 remains unchanged in this release.

Schema 8 remains unchanged and no database migration runs. Schema remains 8 and no database migration runs. After stopping v2.5.2, a direct image rollback to v2.5.1 is supported. Keep the matched pre-upgrade backup until production acceptance passes.

Notifinho v2.5.1

Choose a tag to compare

@github-actions github-actions released this 25 Jul 00:04
89c03d1

Notifinho v2.5.1 release notes

Released 25 July 2026.

v2.5.1 makes generic routes true fallbacks and normalizes the WebUI around the
three supported event inputs: SMTP, HTTP, and Redfish.

Fallback-only routing

  • Dedicated integration routes are evaluated before wildcard routes.
  • Wildcard routes run only when no dedicated route matches.
  • Multiple matching routes to the same destination produce one delivery using
    the highest-priority route.
  • Route filters support include and exclude lists for hosts/devices, events,
    severities, and statuses.
  • Existing Xen Orchestra success/skipped/failure switches are migrated once into
    route status filters. Xen Orchestra integration settings retain only the
    formatter option for job and run IDs.

WebUI normalization

  • Sources show only SMTP, HTTP, and Redfish input badges.
  • Redundant text such as “events received through HTTP” is removed.
  • Destination Enabled/Disabled and Shared/Private states are clickable.
  • The positive Credentials set badge is removed; only missing credentials and
    destination test outcomes are shown.
  • Applications is renamed to Event API tokens and explains that tokens are used
    only by external applications posting to /api/v2/events.
  • Token source scopes are selected from the complete integration catalogue, with
    optional custom source identifiers.
  • Integration behavior cards use consistent spacing and summaries.
  • Overview flow diagnostics are independent: source/input, route, and destination
    cards each report their own state. Green arrows mean working, yellow prohibition
    symbols mean disabled, and red X symbols mean unavailable or invalid.
  • The source-side status line follows the selected input instead of the destination.
  • The Inputs page exposes only the normalized SMTP, HTTP, and Redfish names.
  • Disabling the logical Redfish input acknowledges subscribed controllers without routing events, avoiding retry storms while the input is intentionally paused.
  • Regional and integration settings panels have a clear vertical gap.

Upgrade

  1. Back up the matched config, state, and secret directories.
  2. Validate the release candidate on VM-09 with a copied production snapshot.
  3. Deploy fortpt/notifinho:2.5.1 through the existing Portainer stack.
  4. Confirm schema 8, resource counts, fallback routing, destination controls,
    Event API token scopes, and real Discord/Teams delivery.
  5. Complete docs/v2.5.1-acceptance-checklist.md.

HTTP and HTTPS access

The same-origin WebUI and session boundary are unchanged. Direct HTTP remains
appropriate only on a trusted network. 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. This patch does not change mount
capabilities, container paths, or host-side credential handling.

Compatibility and rollback

The database remains on Schema 8, and config.yaml remains limited to process bootstrap, listener, and security settings. Rollback to v2.5.0 requires stopping v2.5.1 and
restoring the matched pre-upgrade state backup before starting the previous
image because the one-way Xen Orchestra route-filter migration changes stored
route data.

Notifinho v2.5.0

Choose a tag to compare

@github-actions github-actions released this 24 Jul 22:09
a7f683d

Notifinho v2.5.0 release notes

Released 24 July 2026.

v2.5.0 makes SQLite authoritative for every WebUI-managed resource and reduces
config.yaml to process bootstrap, listener, and security settings.

Database-authoritative resources

  • Destinations and routes no longer depend on YAML synchronization.
  • API applications, regional preferences, backup scheduling, integration
    behavior, aliases, and Redfish deduplication settings are WebUI-managed.
  • Destination credentials remain in private secret files referenced by SQLite.
  • Dynamic destination type changes preserve the destination ID, route links,
    delivery history, and secret rotation boundary.

Fault isolation

  • A damaged destination or route row is reported independently while valid rows
    remain available.
  • A damaged integration-settings row falls back to its safe default and is shown
    as needing repair without breaking other settings.
  • Unexpected API failures include a safe error code, endpoint, and reference ID;
    the matching server log contains the traceback without credential values.

Migration

The first successful start upgrades platform state to Schema 8, imports v2.4
YAML resources, and atomically removes these sections from config.yaml:

  • outputs
  • routing
  • api.tokens
  • notifications
  • presentation
  • home_assistant
  • redfish
  • platform.backups
  • webui.language

Existing token values continue working because their hashes are imported. The
migration preserves file ownership and mode and creates a YAML backup.

Upgrade

  1. Back up the matched config, state, and secrets directories.
  2. Validate the migration in an isolated container using a copy of production.
  3. Deploy fortpt/notifinho:2.5.0 through the existing Portainer stack.
  4. Confirm schema 8, resource counts, token authentication, test deliveries,
    aliases, regional settings, and scheduled backups.
  5. Complete docs/v2.5.0-acceptance-checklist.md.

HTTP and HTTPS access

The same-origin WebUI and session boundary are unchanged. Direct HTTP remains
appropriate only on a trusted network. 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. The migration moves backup schedule
and target selection into SQLite but does not change mount capabilities,
container paths, or host-side credential handling.

Compatibility and rollback

Rollback requires stopping v2.5.0 and restoring the matched pre-upgrade
config, state, and secrets backup before starting v2.4.0. v2.4.0 cannot
open schema 8 and normalized v2.5.0 YAML does not contain destinations or routes.

Notifinho v2.4.0

Choose a tag to compare

@github-actions github-actions released this 24 Jul 20:02
2ed45ad

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.

Notifinho v2.3.7

Choose a tag to compare

@FortPT FortPT released this 24 Jul 00:00
b978b59

Notifinho v2.3.7 release notes

Released 24 July 2026.

v2.3.7 supersedes the merged but unpublished v2.3.6 visual correction. It keeps
all WebUI Overview source cards and icon layout boxes identical to Home
Assistant while scaling only selected artwork inside those fixed boxes.
Platform schema 6 and the unified config.yaml model remain unchanged.

Fixed

  • Every Overview source card now uses the same row dimensions as Home Assistant.
  • Every desktop source icon keeps a 48 × 48 px layout box.
  • Every mobile source icon keeps a 44 × 44 px layout box.
  • Notifinho, Dell iDRAC, UniFi Network, UniFi Protect, QNAP, and Synology artwork
    is enlarged only with CSS transforms; the transform does not alter layout.
  • Redfish keeps the official packaged DMTF Redfish image at the normal Overview
    box size.
  • The v2.3.5 body-free inactive-source removal endpoint remains unchanged.
  • Notification payloads, source formatters, destination icons, and delivery
    rendering are not changed by this release.

HTTP and HTTPS access

v2.3.7 does not change the trusted-LAN HTTP or reverse-proxied HTTPS session,
cookie, CSRF, or same-origin asset contract.

Direct managed-mount deployment

v2.3.7 does not change the managed NFS/SMB backup override, mount behaviour, or
capability requirements. Continue using the existing production and
managed-backup Compose files.

Upgrade

  1. Back up the complete configuration, state, logs, and secrets mounts.
  2. Pull fortpt/notifinho:2.3.7.
  3. Redeploy with the existing Compose configuration.
  4. Force-refresh the WebUI once.
  5. Complete the v2.3.7 acceptance checklist.

Compatibility and rollback

v2.3.7 does not change the database or configuration schema. A direct rollback
to v2.3.5 remains supported when configuration and state are retained as one
matched set. v2.3.6 was not published and is not required as an intermediate
upgrade.

Notifinho v2.3.6

Choose a tag to compare

@FortPT FortPT released this 23 Jul 23:32
9c2c118

Notifinho v2.3.6 release notes

Released 24 July 2026.

v2.3.6 corrects the visual scope of the v2.3.5 source-icon change and replaces
the temporary Redfish artwork with the official DMTF Redfish identity. Platform
schema 6 and the unified config.yaml model remain unchanged.

Fixed

  • Restored every normal Overview source icon to the pre-v2.3.5 48 px size.
  • Kept enlargement limited to the requested Notifinho fallback, Dell iDRAC,
    UniFi Network, UniFi Protect, QNAP, and Synology identities.
  • Restored the normal Overview source-card height and column proportions so
    unrelated sources no longer consume additional space.
  • Changed the redfish source to the official DMTF Redfish logo.
  • Kept restful and rest_api aliases on the neutral REST API icon.
  • Retained the v2.3.5 body-free inactive-source removal endpoint.

Redfish asset

The release preparation retrieves the logo from DMTF's official Redfish site:

https://redfish.dmtf.org/sites/default/files/DMTF_Redfish_logo_R.jpg

The downloaded file is committed into the release tag so production containers
do not make an external request at runtime.

HTTP and HTTPS access

v2.3.6 does not change the existing trusted-LAN HTTP or reverse-proxied HTTPS
session, cookie, or CSRF contract. The Redfish logo is served as a packaged
same-origin WebUI asset; the browser does not retrieve it from DMTF at runtime.

Direct managed-mount deployment

v2.3.6 does not change the managed NFS/SMB backup override, mount behaviour, or
capability requirements. Continue using the existing production and
managed-backup Compose files documented for v2.3.5.

Upgrade

  1. Back up the complete configuration, state, logs, and secrets mounts.
  2. Pull fortpt/notifinho:2.3.6.
  3. Redeploy with the existing Compose configuration.
  4. Force-refresh the WebUI once.
  5. Complete the v2.3.6 acceptance checklist.

Compatibility and rollback

v2.3.6 does not change the database or configuration schema. A direct rollback
to v2.3.5 remains supported when configuration and state are retained as one
matched set.