v0.7.4

What's Changed

🔧 Other changes

• build(deps): bump astral-sh/uv from 0.12.13 to 0.12.17 in /docker by @dependabot[bot] in #162

Full Changelog: v0.7.3...v0.7.4

v0.7.3

What's Changed

🔧 Other changes

• build(deps): bump anchore/sbom-action from 0.24.0 to 0.24.2 by @dependabot[bot] in #150
• build(deps): bump websockets from 17.0.1 to 17.1 in /backend in the python-dependencies group by @dependabot[bot] in #151
• build(deps): bump authlib from 1.7.2 to 1.8.0 in /backend in the python-dependencies group by @dependabot[bot] in #152
• build(deps): bump astral-sh/uv from 0.12.7 to 0.12.10 in /docker by @dependabot[bot] in #153
• build(deps): bump python from cae66f2 to cad9a2c in /docker by @dependabot[bot] in #154
• fix: patch vulnerable container runtime packages by @konkos1 in #155
• build(deps): bump astral-sh/setup-uv from 10.0.1 to 10.1.0 by @dependabot[bot] in #156
• build(deps): bump the python-dependencies group in /backend with 2 updates by @dependabot[bot] in #157
• build(deps): bump astral-sh/uv from 0.12.10 to 0.12.13 in /docker by @dependabot[bot] in #158
• build(deps): bump docker/build-push-action from 7.3.0 to 7.4.0 by @dependabot[bot] in #159
• build(deps): bump docker/setup-buildx-action from 4.3.0 to 4.4.1 by @dependabot[bot] in #160
• build(deps): bump the python-dependencies group in /backend with 5 updates by @dependabot[bot] in #161

Full Changelog: v0.7.2...v0.7.3

v0.7.2

🛰️ OpenSecDash v0.7.2: The Dashboard Has Learned Its ASNs — and Its Updates Can Speak Up

OpenSecDash v0.7.2 is a response-policy, network-context, historical-visibility, and notification update. It adds permanent local ASN ban policies backed by ordinary CrowdSec IP decisions, keeps ASN organizations separate from IP-specific provider names, adds notifications for ASN activity and newly available asset versions, and extends the Rollup Explorer with a yearly view.

An Autonomous System Number, or ASN, identifies a network on the internet. Providers and hosting companies use ASNs to exchange routing information, which makes them a useful way to recognize where groups of public IP addresses belong.

In other words: the dashboard can now remember that an entire internet neighborhood has been troublesome, while still asking CrowdSec to lock out only the addresses it has actually seen. It can also let you know when one of the applications in your homelab has a new release waiting. Even a homelab firewall should avoid starting a diplomatic incident with half the routing table, and even a homelab administrator should not need to patrol every release page by hand.

⚠️ Upgrade Notes: No Breaking Changes

Existing Docker installations can upgrade without changing their deployment configuration. The new ASN policy tables, organization fields, and notification defaults are applied automatically through the normal database migration and startup processes.

There are four details worth knowing:

• Existing notification choices are preserved. Newly created event, system, ASN, asset-update, and Insight rules start disabled, so notifications remain explicitly opt-in. Rules that an administrator already enabled or disabled keep their saved state.
• Asset-update notifications are opt-in. Configure SMTP, enable notifications globally, and then enable the separate Asset update available rule on the Notifications page. Existing available updates do not generate retroactive mail merely because the rule was added.
• Bare-metal installations should update to Python 3.14.7. This is the pinned and validated runtime for v0.7.2; Docker users receive it with the image.
• Permanent ASN enforcement is opt-in and dependency-aware. Creating a real policy requires usable GeoIP and CrowdSec integrations, an Operator or Admin account, and Action simulation to be disabled. The upgrade does not create policies or send new data to an external service.

No surprise bans, no retroactive sweep through old events, and no notification rule waking up simply because an upgrade found the light switch.

➡️ Upgrade details:
Updating OpenSecDash

🚫 Permanent ASN Policies, Carefully Applied

Operators and administrators can now mark an unwanted ASN once and let OpenSecDash respond when future public-IP events are enriched with that ASN. The action is available from the optional ASN column in Events and Access, and the resulting policies are managed on the CrowdSec page.

The word permanent describes the local OpenSecDash policy, not an endless CrowdSec ban. Each newly observed match creates a normal global scope=Ip decision for seven days. OpenSecDash does not send native ASN decisions, expand BGP prefixes, scan historical events, or renew bans on a timer. Standard CrowdSec bouncers therefore continue to work with the IP decisions they already understand.

The workflow keeps ownership deliberately narrow:

• Only newly stored public-IP events that complete GeoIP enrichment can match a policy.
• Exact CrowdSec decision IDs are tracked, so policy cleanup never broadly unbans an address or touches an unrelated decision.
• Manually unbanning a policy-owned IP creates an exception for that ASN/IP pair only.
• Reclassification to a different, non-blocked ASN releases only the old policy-owned decision; failed releases remain visible and retryable.
• Removing a policy cleans up only decisions that still match its recorded ownership, origin, and scenario.

Every successful automatic ban also creates a high-confidence IP Explorer Insight and contributes to ban counters, CrowdSec history, the Dashboard, and rollups. ASN-specific scenarios keep their detail in event history while summary views group them under Manual permanent ASN ban, because a top-scenarios chart containing 47 nearly identical AS numbers is technically accurate but emotionally unhelpful.

Important: The first request is always observed before this workflow can react. GeoIP enrichment, the CrowdSec LAPI call, and bouncer synchronization happen afterward, so enforcement can begin no earlier than a later request and is not guaranteed by the second one.

➡️ Policy setup, behavior, and recovery:
CrowdSec

🏷️ ASN Organizations Are Their Own Data Now

GeoIP enrichment now stores the ASN organization separately from the IP-specific ISP or company name. Events and Access can show both the normalized ASN and its organization, while permanent policies retain the latest organization as a reviewable display snapshot.

That distinction matters because an ASN number is the policy key, while organization names are neither authoritative nor immutable. Providers can return stale data, companies can rename themselves, and ASNs can change hands. OpenSecDash therefore waits for a substantially different organization to appear three times across at least two IPs before raising a review warning. Cosmetic differences in case, whitespace, punctuation, and common legal suffixes do not manufacture drama.

Acknowledging the warning records that somebody reviewed it. It does not prove an ownership transfer, pause the policy, or silently remove decisions; those remain separate, confirmed actions.

➡️ Classification limits and privacy details:
GeoIP

🔔 ASN Activity Can Send an Email — If You Ask It To

Notifications cover successful permanent ASN-policy bans and confirmed ASN-organization changes. Ban messages include the affected IP, ASN, organization snapshot, decision duration, and CrowdSec scenario. Organization-change messages include both snapshots and the time the change was confirmed, giving an administrator enough context to investigate without treating GeoIP as an oracle.

All newly created rules are disabled. Enabling global notifications and configuring SMTP is still not enough by itself; each event, system, ASN, asset-update, or Insight rule must be selected explicitly. Existing saved choices survive the upgrade.

➡️ Rule behavior and SMTP setup:
Notifications

📦 New Asset Updates Can Send an Email Too

The new Asset update available rule can send an email when OpenSecDash first detects that an asset is outdated or when a different latest version appears later. Repeated checks of the same available version do not create duplicate notifications.

Each message includes the update-relevant details that are available: asset and system names, VMID, asset and system types, inventory source, installed version, available version, host URL, and check time. It also contains a direct link to the matching GitHub release notes and, when an OpenSecDash base URL is configured, a link back to the affected system in the Asset Explorer. If several updates are waiting, the digest keeps the details and release-notes link for every included asset.

The rule starts disabled, just like every other newly created notification rule. OpenSecDash does not send existing inventory data anywhere unless an administrator configures SMTP and explicitly enables both notifications and this rule.

➡️ Asset inventory and update checks:
Asset update checks

➡️ Rule behavior and SMTP setup:
Notifications

📅 The Rollup Explorer Thinks in Years

The Rollup Explorer can now summarize a complete calendar year, including the current year to date. It combines recent daily rollups with compacted monthly rows, so the view remains useful even after raw events have left the retention window.

Yearly summaries include the same totals and breakdowns as daily and monthly views: internal and external access, security events, bans, geoblocks, total events, event types, scenarios, and countries. Long-term visibility no longer requires twelve browser tabs and the sort of mental arithmetic usually reserved for tax season.

➡️ Historical summaries and retention:
Dashboard rollups

✨ Smaller Improvements and Fixes

• The mobile navigation menu works again, including after responsive page transitions.
• Mobile search keeps its value during refreshes instead of developing selective amnesia.
• CrowdSec ASN management sections preserve their expanded or collapsed state during updates.
• Python moves to 3.14.7, Node.js to the 24 LTS line, Tailwind CSS to 4.3.3, and htmx to 2.0.10.
• Runtime, build, release, and security dependencies received routine updates, with generated third-party notices kept in sync.
• Release finalization now receives the repository context it needs, reducing the chance that the last step of a release suddenly forgets which release it is finishing.

🎯 What This Release Represents

v0.7.x gives homelab operators a durable response to recurring traffic from an unwanted ASN without pretending that an ASN is a static list of addresses or that GeoIP da...

v0.7.1

🛰️ OpenSecDash v0.7.1: The Dashboard Has Learned Its ASNs — and Its Updates Can Speak Up

OpenSecDash v0.7.1 is a response-policy, network-context, historical-visibility, and notification update. It adds permanent local ASN ban policies backed by ordinary CrowdSec IP decisions, keeps ASN organizations separate from IP-specific provider names, adds notifications for ASN activity and newly available asset versions, and extends the Rollup Explorer with a yearly view.

An Autonomous System Number, or ASN, identifies a network on the internet. Providers and hosting companies use ASNs to exchange routing information, which makes them a useful way to recognize where groups of public IP addresses belong.

In other words: the dashboard can now remember that an entire internet neighborhood has been troublesome, while still asking CrowdSec to lock out only the addresses it has actually seen. It can also let you know when one of the applications in your homelab has a new release waiting. Even a homelab firewall should avoid starting a diplomatic incident with half the routing table, and even a homelab administrator should not need to patrol every release page by hand.

⚠️ Upgrade Notes: No Breaking Changes

Existing Docker installations can upgrade without changing their deployment configuration. The new ASN policy tables, organization fields, and notification defaults are applied automatically through the normal database migration and startup processes.

There are four details worth knowing:

• Existing notification choices are preserved. Newly created event, system, ASN, asset-update, and Insight rules start disabled, so notifications remain explicitly opt-in. Rules that an administrator already enabled or disabled keep their saved state.
• Asset-update notifications are opt-in. Configure SMTP, enable notifications globally, and then enable the separate Asset update available rule on the Notifications page. Existing available updates do not generate retroactive mail merely because the rule was added.
• Bare-metal installations should update to Python 3.14.7. This is the pinned and validated runtime for v0.7.1; Docker users receive it with the image.
• Permanent ASN enforcement is opt-in and dependency-aware. Creating a real policy requires usable GeoIP and CrowdSec integrations, an Operator or Admin account, and Action simulation to be disabled. The upgrade does not create policies or send new data to an external service.

No surprise bans, no retroactive sweep through old events, and no notification rule waking up simply because an upgrade found the light switch.

➡️ Upgrade details:
Updating OpenSecDash

🚫 Permanent ASN Policies, Carefully Applied

Operators and administrators can now mark an unwanted ASN once and let OpenSecDash respond when future public-IP events are enriched with that ASN. The action is available from the optional ASN column in Events and Access, and the resulting policies are managed on the CrowdSec page.

The word permanent describes the local OpenSecDash policy, not an endless CrowdSec ban. Each newly observed match creates a normal global scope=Ip decision for seven days. OpenSecDash does not send native ASN decisions, expand BGP prefixes, scan historical events, or renew bans on a timer. Standard CrowdSec bouncers therefore continue to work with the IP decisions they already understand.

The workflow keeps ownership deliberately narrow:

• Only newly stored public-IP events that complete GeoIP enrichment can match a policy.
• Exact CrowdSec decision IDs are tracked, so policy cleanup never broadly unbans an address or touches an unrelated decision.
• Manually unbanning a policy-owned IP creates an exception for that ASN/IP pair only.
• Reclassification to a different, non-blocked ASN releases only the old policy-owned decision; failed releases remain visible and retryable.
• Removing a policy cleans up only decisions that still match its recorded ownership, origin, and scenario.

Every successful automatic ban also creates a high-confidence IP Explorer Insight and contributes to ban counters, CrowdSec history, the Dashboard, and rollups. ASN-specific scenarios keep their detail in event history while summary views group them under Manual permanent ASN ban, because a top-scenarios chart containing 47 nearly identical AS numbers is technically accurate but emotionally unhelpful.

Important: The first request is always observed before this workflow can react. GeoIP enrichment, the CrowdSec LAPI call, and bouncer synchronization happen afterward, so enforcement can begin no earlier than a later request and is not guaranteed by the second one.

➡️ Policy setup, behavior, and recovery:
CrowdSec

🏷️ ASN Organizations Are Their Own Data Now

GeoIP enrichment now stores the ASN organization separately from the IP-specific ISP or company name. Events and Access can show both the normalized ASN and its organization, while permanent policies retain the latest organization as a reviewable display snapshot.

That distinction matters because an ASN number is the policy key, while organization names are neither authoritative nor immutable. Providers can return stale data, companies can rename themselves, and ASNs can change hands. OpenSecDash therefore waits for a substantially different organization to appear three times across at least two IPs before raising a review warning. Cosmetic differences in case, whitespace, punctuation, and common legal suffixes do not manufacture drama.

Acknowledging the warning records that somebody reviewed it. It does not prove an ownership transfer, pause the policy, or silently remove decisions; those remain separate, confirmed actions.

➡️ Classification limits and privacy details:
GeoIP

🔔 ASN Activity Can Send an Email — If You Ask It To

Notifications cover successful permanent ASN-policy bans and confirmed ASN-organization changes. Ban messages include the affected IP, ASN, organization snapshot, decision duration, and CrowdSec scenario. Organization-change messages include both snapshots and the time the change was confirmed, giving an administrator enough context to investigate without treating GeoIP as an oracle.

All newly created rules are disabled. Enabling global notifications and configuring SMTP is still not enough by itself; each event, system, ASN, asset-update, or Insight rule must be selected explicitly. Existing saved choices survive the upgrade.

➡️ Rule behavior and SMTP setup:
Notifications

📦 New Asset Updates Can Send an Email Too

The new Asset update available rule can send an email when OpenSecDash first detects that an asset is outdated or when a different latest version appears later. Repeated checks of the same available version do not create duplicate notifications.

Each message includes the update-relevant details that are available: asset and system names, VMID, asset and system types, inventory source, installed version, available version, host URL, and check time. It also contains a direct link to the matching GitHub release notes and, when an OpenSecDash base URL is configured, a link back to the affected system in the Asset Explorer. If several updates are waiting, the digest keeps the details and release-notes link for every included asset.

The rule starts disabled, just like every other newly created notification rule. OpenSecDash does not send existing inventory data anywhere unless an administrator configures SMTP and explicitly enables both notifications and this rule.

➡️ Asset inventory and update checks:
Asset update checks

➡️ Rule behavior and SMTP setup:
Notifications

📅 The Rollup Explorer Thinks in Years

The Rollup Explorer can now summarize a complete calendar year, including the current year to date. It combines recent daily rollups with compacted monthly rows, so the view remains useful even after raw events have left the retention window.

Yearly summaries include the same totals and breakdowns as daily and monthly views: internal and external access, security events, bans, geoblocks, total events, event types, scenarios, and countries. Long-term visibility no longer requires twelve browser tabs and the sort of mental arithmetic usually reserved for tax season.

➡️ Historical summaries and retention:
Dashboard rollups

✨ Smaller Improvements and Fixes

• The mobile navigation menu works again, including after responsive page transitions.
• Mobile search keeps its value during refreshes instead of developing selective amnesia.
• CrowdSec ASN management sections preserve their expanded or collapsed state during updates.
• Python moves to 3.14.7, Node.js to the 24 LTS line, Tailwind CSS to 4.3.3, and htmx to 2.0.10.
• Runtime, build, release, and security dependencies received routine updates, with generated third-party notices kept in sync.
• Release finalization now receives the repository context it needs, reducing the chance that the last step of a release suddenly forgets which release it is finishing.

🎯 What This Release Represents

v0.7.1 gives homelab operators a durable response to recurring traffic from an unwanted ASN without pretending that an ASN is a static list of addresses or that GeoIP da...

v0.7.0

🛰️ OpenSecDash v0.7.0: The Dashboard Has Learned Its ASNs

OpenSecDash v0.7.0 is a response-policy, network-context, and historical-visibility update. It adds permanent local ASN ban policies backed by ordinary CrowdSec IP decisions, keeps ASN organizations separate from IP-specific provider names, adds notifications for ASN activity, and extends the Rollup Explorer with a yearly view.

An Autonomous System Number, or ASN, identifies a network on the internet. Providers and hosting companies use ASNs to exchange routing information, which makes them a useful way to recognize where groups of public IP addresses belong.

In other words: the dashboard can now remember that an entire internet neighborhood has been troublesome, while still asking CrowdSec to lock out only the addresses it has actually seen. Even a homelab firewall should avoid starting a diplomatic incident with half the routing table.

⚠️ Upgrade Notes: No Breaking Changes

Existing Docker installations can upgrade without changing their deployment configuration. The new ASN policy tables, organization fields, and notification defaults are applied automatically through the normal database migration process.

There are three details worth knowing:

• Existing notification choices are preserved. Newly created event, system, ASN, and Insight rules now start disabled, so notifications remain explicitly opt-in. Rules that an administrator already enabled or disabled keep their saved state.
• Bare-metal installations should update to Python 3.14.7. This is the pinned and validated runtime for v0.7.0; Docker users receive it with the image.
• Permanent ASN enforcement is opt-in and dependency-aware. Creating a real policy requires usable GeoIP and CrowdSec integrations, an Operator or Admin account, and Action simulation to be disabled. The upgrade does not create policies or send new data to an external service.

No surprise bans, no retroactive sweep through old events, and no notification rule waking up simply because a migration found the light switch.

➡️ Upgrade details:
Updating OpenSecDash

🚫 Permanent ASN Policies, Carefully Applied

Operators and administrators can now mark an unwanted ASN once and let OpenSecDash respond when future public-IP events are enriched with that ASN. The action is available from the optional ASN column in Events and Access, and the resulting policies are managed on the CrowdSec page.

The word permanent describes the local OpenSecDash policy, not an endless CrowdSec ban. Each newly observed match creates a normal global scope=Ip decision for seven days. OpenSecDash does not send native ASN decisions, expand BGP prefixes, scan historical events, or renew bans on a timer. Standard CrowdSec bouncers therefore continue to work with the IP decisions they already understand.

The workflow keeps ownership deliberately narrow:

• Only newly stored public-IP events that complete GeoIP enrichment can match a policy.
• Exact CrowdSec decision IDs are tracked, so policy cleanup never broadly unbans an address or touches an unrelated decision.
• Manually unbanning a policy-owned IP creates an exception for that ASN/IP pair only.
• Reclassification to a different, non-blocked ASN releases only the old policy-owned decision; failed releases remain visible and retryable.
• Removing a policy cleans up only decisions that still match its recorded ownership, origin, and scenario.

Every successful automatic ban also creates a high-confidence IP Explorer Insight and contributes to ban counters, CrowdSec history, the Dashboard, and rollups. ASN-specific scenarios keep their detail in event history while summary views group them under Manual permanent ASN ban, because a top-scenarios chart containing 47 nearly identical AS numbers is technically accurate but emotionally unhelpful.

Important: The first request is always observed before this workflow can react. GeoIP enrichment, the CrowdSec LAPI call, and bouncer synchronization happen afterward, so enforcement can begin no earlier than a later request and is not guaranteed by the second one.

➡️ Policy setup, behavior, and recovery:
CrowdSec

🏷️ ASN Organizations Are Their Own Data Now

GeoIP enrichment now stores the ASN organization separately from the IP-specific ISP or company name. Events and Access can show both the normalized ASN and its organization, while permanent policies retain the latest organization as a reviewable display snapshot.

That distinction matters because an ASN number is the policy key, while organization names are neither authoritative nor immutable. Providers can return stale data, companies can rename themselves, and ASNs can change hands. OpenSecDash therefore waits for a substantially different organization to appear three times across at least two IPs before raising a review warning. Cosmetic differences in case, whitespace, punctuation, and common legal suffixes do not manufacture drama.

Acknowledging the warning records that somebody reviewed it. It does not prove an ownership transfer, pause the policy, or silently remove decisions; those remain separate, confirmed actions.

➡️ Classification limits and privacy details:
GeoIP

🔔 ASN Activity Can Send an Email — If You Ask It To

Notifications now cover successful permanent ASN-policy bans and confirmed ASN-organization changes. Ban messages include the affected IP, ASN, organization snapshot, decision duration, and CrowdSec scenario. Organization-change messages include both snapshots and the time the change was confirmed, giving an administrator enough context to investigate without treating GeoIP as an oracle.

All newly created rules are disabled. Enabling global notifications and configuring SMTP is still not enough by itself; each event, system, ASN, or Insight rule must be selected explicitly. Existing saved choices survive the upgrade.

➡️ Rule behavior and SMTP setup:
Notifications

📅 The Rollup Explorer Thinks in Years

The Rollup Explorer can now summarize a complete calendar year, including the current year to date. It combines recent daily rollups with compacted monthly rows, so the view remains useful even after raw events have left the retention window.

Yearly summaries include the same totals and breakdowns as daily and monthly views: internal and external access, security events, bans, geoblocks, total events, event types, scenarios, and countries. Long-term visibility no longer requires twelve browser tabs and the sort of mental arithmetic usually reserved for tax season.

➡️ Historical summaries and retention:
Dashboard rollups

✨ Smaller Improvements and Fixes

• The mobile navigation menu works again, including after responsive page transitions.
• Mobile search keeps its value during refreshes instead of developing selective amnesia.
• CrowdSec ASN management sections preserve their expanded or collapsed state during updates.
• Python moves to 3.14.7, Node.js to the 24 LTS line, Tailwind CSS to 4.3.3, and htmx to 2.0.10.
• Runtime, build, release, and security dependencies received routine updates, with generated third-party notices kept in sync.
• Release finalization now receives the repository context it needs, reducing the chance that the last step of a release suddenly forgets which release it is finishing.

🎯 What This Release Represents

v0.7.0 gives homelab operators a durable response to recurring traffic from an unwanted ASN without pretending that an ASN is a static list of addresses or that GeoIP data is unquestionable truth. Policies stay local, enforcement stays limited to observed IPs, ownership is recorded precisely, and unusual organization changes remain visible for human review.

At the same time, notification defaults become more deliberate and historical rollups become easier to inspect across a full year. The result is broader security context with deliberately narrow actions: remember the neighborhood, verify the address, and keep the giant red BAN THE INTERNET button safely imaginary.

---

What's Changed

✨ Enhancements

• feat: permanent asn bans by @konkos1 in #131
• feat: asn notifications by @konkos1 in #134
• feat: add yearly rollup view by @konkos1 in #135

🐛 Fixes

• fix: restore mobile navigation menu with Tailwind 4 by @konkos1 in #122
• fix: preserve mobile search during refresh by @konkos1 in #123
• fix: preserve crowdsec asn section state by @konkos1 in #132
• feat: separate asn organization data by @konkos1 in #133
• fix: speed up bounded event searches by @konkos1 in #136

🔧 Other changes

• build(deps): bump actions/upload-artifact from 6.0.0 to 7.0.1 by @dependabot[bot] in #109
• build(deps): bump cryptography from 49.0.0 to 50.0.0 in /backend by @dependabot[bot] in #112
• build(deps): bump astral-sh/uv from 0.11.32 to 0.12.2 in /docker by @dependabot[bot] in #115...

v0.6.0

🔔 OpenSecDash v0.6.0: Every Insight Gets Its Own Bell

OpenSecDash v0.6.0 is a visibility, notification, and release-transparency update. It adds individual notification controls for every Insight, a privacy-conscious IPLocate GeoIP option, provider reachability diagnostics, a more useful 30-day Dashboard trend, and complete third-party license evidence.

In other words: the dashboard has stopped ringing one large alarm bell for every Insight. It now has a labeled bell for each one, knows whether somebody installed the wiring, and can explain why a bell is temporarily quiet.

⚠️ Upgrade Notes: No Breaking Changes

Existing installations can upgrade without changing their deployment configuration. Database and settings updates run automatically with the normal migration process.

There are three behavior changes worth knowing about:

• Existing GeoIP settings are preserved. An installation using ip-api.com keeps using it; the upgrade never switches providers or starts a new external data flow. Only new installations pre-select IPLocate, and GeoIP still starts disabled.
• The shared Scanner detected notification rule is retired. If it was enabled, currently known high-severity Insights inherit that enabled state as separate rules. The old wildcard rule is disabled to prevent duplicate mail. New Insight rules start disabled.
• Custom event-producing plugins should declare event_types. OpenSecDash uses this metadata to determine whether dependent Insight notification rules are available. Missing metadata does not stop the plugin, but its dependent notification controls cannot be enabled until their event producers are known.

No surprise provider swap, no surprise email storm, and no surprise wizard demanding an enterprise architecture diagram.

➡️ Upgrade details:
Updating OpenSecDash

🔔 One Notification Rule per Insight

Every built-in, downloaded, or plugin-provided Insight now receives its own persistent notification rule. Administrators can choose exactly which findings deserve an email instead of enabling one shared high-severity wildcard.

• Each Insight keeps its own enabled state, time window, and cooldown across restarts and ruleset updates.
• Declarative ruleset updates can refresh names and metadata without replacing the administrator's choices.
• A rule is selectable only while enabled plugins can produce all event types required by that Insight.
• Disabling a required plugin temporarily disables the control but preserves its saved value. Re-enable the plugin and the rule returns with its previous choice.
• Removed Insights are retired cleanly instead of leaving active notification rules behind like tiny email-producing ghosts.

The availability check follows enabled plugin capabilities, not temporary health. A short-lived plugin error therefore does not erase configuration or make controls flicker.

➡️ Rule behavior and SMTP setup:
Notifications

🌍 GeoIP Gets a Safer Provider Choice

The GeoIP plugin now supports the IPLocate EU endpoint alongside the existing ip-api.com integration. New installations pre-select IPLocate while keeping GeoIP disabled, so no lookup leaves the homelab until an administrator opts in.

IPLocate lookups use a fixed HTTPS EU endpoint, verify certificates, refuse redirects, and send the required API key in a request header rather than the URL. The key is write-only in Settings: the browser only learns whether one is stored, an empty field keeps it, and deletion requires a separate confirmed action. OpenSecDash requests and stores only country, city, ASN, and provider information; threat scores, coordinates, and other unused response fields stay out.

The legacy ip-api.com provider remains available without an API key, including for existing installations, but still uses unencrypted HTTP. There is no automatic fallback between providers. Cache entries are provider-specific, so switching providers refreshes an address instead of quietly serving data from the old source.

GeoIP enrichment now lives fully inside the plugin behind a generic bounded enrichment hook. Failed and incomplete lookups are retried without blocking the application event loop, while public-address checks ensure private, local, reserved, and otherwise non-global addresses never reach a remote provider.

➡️ Provider setup, privacy details, and caching:
GeoIP

🩺 GeoIP Diagnostics Report Real Reachability

Diagnostics now reports the outcome and time of the latest real lookup for the selected GeoIP provider. It does not generate a separate probe just to make the status light feel busy.

Before the first lookup, reachability is shown as unverified. A transport failure adds practical DNS, firewall, proxy, and outbound-connection checks; a later successful lookup restores the normal provider status automatically. Debug reports include only aggregate enrichment and cache health, never the looked-up address, API key, location result, or raw provider error.

📈 The 30-Day Trend Keeps Its Daily Detail

Daily rollups are now retained for every calendar month that still overlaps the Dashboard's rolling 30-day trend. A completed month is compacted only after all of its days leave that window, so month boundaries no longer turn recent daily data into a coarser summary too early.

This remains independent of raw-event retention: even a homelab with a shorter raw data window keeps enough daily rollups for the complete Dashboard trend. Older completed months still become compact monthly rows, keeping SQLite pleasantly un-dramatic.

➡️ Retention and historical summaries:
Dashboard rollups

📜 Licenses and Source Evidence Are Now Part of the Release

OpenSecDash now generates and verifies third-party notices for Python runtime packages, browser components, and website dependencies. A public Licenses page exposes the project license, bundled component notices, and source-availability information without requiring sign-in.

Tagged releases add the evidence needed to match the published container to its source:

• generated application and website notices;
• an SPDX software bill of materials;
• the Linux container package and source report;
• verified source references and archives for covered Python dependencies; and
• a corresponding-source archive for container packages that require it.

The release workflow checks the actual Linux runtime inventory, verifies source archive digests and sizes against the lockfile, and keeps the GitHub Release as a draft until both the evidence and the verified image are ready. Legal paperwork may not be the most exciting Dashboard widget, but it is an excellent one to have before somebody asks.

✨ Smaller Improvements and Fixes

• Asset filters now use checkboxes, making multi-value selections clearer and easier to adjust.
• Account and sign-out navigation uses dedicated icons, while authentication and Settings text is shorter and more consistent in English and German.
• Informational hints have clearer styling, and the offline page now directs users back to the application more cleanly.
• Browser interactions affected by the strict Content Security Policy work again without reintroducing inline event handlers.
• GeoIP provider configuration errors survive background refreshes, so Diagnostics does not accidentally hide the useful part of a failure.
• Event-notification deduplication stays bounded and refreshes pending payloads after enrichment without queueing the same event twice.
• FastAPI, httpx2, uv, and release workflow actions received routine dependency updates.

🎯 What This Release Represents

v0.6.0 makes OpenSecDash more selective about what it reports, more transparent about remote enrichment, and more precise about what it ships. The user-facing controls stay small and understandable, while plugin metadata, diagnostics, and release evidence do more of the careful bookkeeping underneath.

The result remains deliberately homelab-sized: one dashboard, explicit external data flows, useful investigation context, and fewer mysterious bells ringing at 03:00.

---

What's Changed

✨ Enhancements

• feat: add geoip provider IPlocate by @konkos1 in #101
• feat: third party license compliance by @konkos1 in #102
• change: use checkboxes for asset filters by @konkos1 in #104
• feat: add per-insight notification rules by @konkos1 in #105
• enhance: report GeoIP reachability in diagnostics by @konkos1 in #106

🐛 Fixes

• fix: restore csp-safe browser interactions by @konkos1 in #99
• fix: UI/Text improvements by @konkos1 in #100
• fix: retain daily rollups for dashboard trend by @konkos1 in #103
• fix: post v0.5 review findings by @konkos1 in #107

🔧 Other changes

• build(deps): bump astral-sh/setup-uv from 7.6.0 to 9.0.0 by @dependabot[bot] in #89
• build(deps): bump docker/login-action from 4.4.0 to 4.6.0 by @dependabot[bot] in #90
• build(deps): bump actions/download-artifact from 7.0.0 to 8.0.1 by ...

v0.5.0

🔐 OpenSecDash v0.5.0: The Front Door Now Has a Lock

OpenSecDash v0.5.0 is a security, reliability, and operations release. It adds optional OpenID Connect sign-in, a protected first-admin setup for new installations, safer remote integrations, stronger browser and input boundaries, and release gates for large databases and real upgrades.

In other words: the dashboard has not merely received another shiny graph. It has learned to lock the front door, check who is knocking, and avoid drinking arbitrary JSON from the internet.

⚠️ Breaking Changes: Read Before Upgrading

Action may be required: Review the authentication, SMTP, bare-metal, and custom container-command notes below before deploying v0.5.0. Surprise lockouts are funny only when they happen to somebody else's lab.

🔑 Internal Sign-In Is Now the Default for New Installations

Brand-new installations no longer start with an open dashboard. The first visit opens a restricted setup page where the first local Admin account is created. Completing that setup requires a trusted reverse proxy, HTTPS on external port 443, an explicitly configured OSD_TRUSTED_PROXIES value, and a matching authentication hostname.

To run a new installation without OpenSecDash's internal sign-in—for example behind a VPN or an existing forward-auth layer—set OSD_AUTH_DISABLED=true and restart. Every visitor who can reach the instance then has full access, so the surrounding network or authentication proxy must provide the protection.

Existing installations are not locked out by the upgrade:

• Existing installations with internal sign-in enabled continue unchanged.
• Existing open installations remain open and fully usable, but show a permanent security prompt until an administrator enables internal sign-in or deliberately sets OSD_AUTH_DISABLED=true.
• Existing users, roles, sessions, password hashes, OIDC settings, and authentication hostnames are preserved.

The former Disable internal sign-in button has been removed. Once internal sign-in is enabled, OSD_AUTH_DISABLED=true is the only bypass and recovery mechanism.

➡️ Setup, migration behavior, and recovery:
Authentication

✉️ SMTP TLS Certificates Are Now Verified

STARTTLS and SSL/TLS connections now verify both the mail-server certificate and its hostname. Installations using a public CA should continue to work without changes.

Action required for private or self-signed mail CAs: Mount the CA certificate into the container and configure Custom CA certificate file. Certificate verification cannot be disabled.

➡️ SMTP setup:
Notifications

🐍 Bare-Metal Installations Use the Pinned Python Runtime

The exact Python version in backend/.python-version—3.14.6 for this release—is now the validated runtime for development, CI, release checks, and production. Bare-metal operators should install that version and recreate or synchronize the environment with the pinned uv release before restarting OpenSecDash. Docker users receive the correct runtime with the image.

➡️ Updated installation steps:
Bare-metal installation

🐳 Custom Container Commands No Longer Run Through a Shell

The standard image command is unchanged from an operator's perspective, but the entrypoint now launches Uvicorn directly as PID 1. This gives the process clean signal handling and graceful shutdown.

Action required only if the image command is overridden: Pass the executable and arguments in exec/array form. Shell expansion, pipelines, and compound command strings are no longer interpreted implicitly.

🧱 Update Your Compose Deployment

Existing Compose deployments continue to start, but operators should update their docker-compose.yml using the new example. The hardened configuration makes the container root filesystem read-only, provides a small temporary filesystem, enables no-new-privileges, drops unnecessary Linux capabilities, and adds sensible CPU, memory, and process limits.

The container keeps only CHOWN, SETUID, and SETGID during startup so it can repair ownership of existing /data volumes before launching OpenSecDash as its unprivileged application user. Keep these three capabilities unless volume ownership is managed separately and the consequences have been tested.

Recommended action for Docker Compose users: Compare your deployment with the current docker-compose.example.yml and adopt the new hardening options. Adjust the resource limits to match unusually large event volumes, but keep the security boundaries wherever possible.

➡️ Configuration details and volume-upgrade guidance:
Docker installation

✨ What This Release Represents

The headline addition is optional single sign-on with one OpenID Connect provider, such as Authentik, Authelia, Keycloak, or Pocket ID. Password sign-in remains available by default, provider accounts map to local OpenSecDash users, and roles remain under local administrator control. Existing users and sessions survive the database migration.

The less visible work is just as important:

• 🛡️ Global security headers, CSRF origin checks, safer redirects, bounded request and response bodies, and stricter permissions reduce the blast radius of exposed routes.
• 🌐 Remote integrations validate destinations, redirects, TLS behavior, and response sizes more carefully while keeping private homelab services usable.
• ⚡ Event search, live updates, startup maintenance, and background database sessions behave predictably on large SQLite installations.
• 📦 Locked dependencies, runtime-parity checks, upgrade benchmarks, container scans, and a hardened Compose example make the shipped artifact match the tested one.
• 🔎 Remote GeoIP is off by default for new installations because the bundled free provider receives uncached public IPs over plain HTTP. Existing explicit settings are preserved and surfaced with a warning.

Together, these changes make OpenSecDash more defensive without turning it into an enterprise maze: one container, one SQLite database, understandable controls, and no new telemetry or hidden external data flows.

➡️ Full upgrade guidance:
Updating OpenSecDash

---

What's Changed

⚠️ Breaking changes

• Auth admin onboarding by @konkos1 in #80

✨ Enhancements

• App hardening by @konkos1 in #70
• OIDC authentication by @konkos1 in #77
• Expand authentication debug report by @konkos1 in #97
• Global csrf origin check by @konkos1 in #58
• Harden login backoff against xff spoofing by @konkos1 in #60
• Verify smtp tls certificates by @konkos1 in #61
• Seed legacy settings in upgrade benchmark fixture by @konkos1 in #81
• Key login throttling on trusted client, not shared proxy by @konkos1 in #82
• Enforce insight rule size limits while streaming download by @konkos1 in #83
• Harden login throttling against rotation, account DoS by @konkos1 in #84
• Harden deployment and remote integrations by @konkos1 in #88
• Lock oidc provider controls with password login off by @konkos1 in #94

🐛 Fixes

• Centralize safe local redirects by @konkos1 in #59
• Move legacy view migration out of get requests by @konkos1 in #62
• Persist offline detection state by @konkos1 in #63
• Fold asset lookup into event query by @konkos1 in #64
• Index insight cooldown queries by @konkos1 in #65
• Own background loop sessions in their worker thread by @konkos1 in #76
• Bound login verification without shared lockouts by @konkos1 in #86
• Close remaining review findings by @konkos1 in #87
• Keep github token editable without asset plugins by @konkos1 in #95
• Fix dashboard empty state banner by @konkos1 in #96
• Match canonical CrowdSec decision IPs by @konkos1 in #98

🔧 Other changes

• build(deps): bump the python-dependencies group across 1 directory with 4 updates by @dependabot[bot] in #69
• build(deps): bump actions/setup-python from 6.3.0 to 7.0.0 by @dependabot[bot] in #72
• build(deps): bump actions/setup-node from 6.5.0 to 7.0.0 by @dependabot[bot] in #73
• build(deps): bump anchore/sbom-action from 0.20.6 to 0.24.0 by @dependabot[bot] in https://...

v0.4.2

🚀 The Biggest OpenSecDash Update Yet

The release v0.4.x is a major milestone for OpenSecDash and the most substantial update in the project's history. Since v0.3.1, we have not merely added isolated features: core parts of the application have been expanded, redesigned, and brought together into a more complete security experience. With this release, OpenSecDash includes the full feature set defined by the current Architecture Decision Records for the first stable v1 version. Further additions such as more notification channels, an asynchronous action queue, advanced Level 2 correlations, and full offline operation remain deliberately reserved for later versions.

✨ What This Release Represents

Major additions include the complete Action Framework for controlled and auditable responses, the redesigned Insights and correlation engine, a customizable plugin-driven dashboard, shared filters and saved views for Events and Access, and the new notification framework with SMTP support.

The release also introduces optional internal authentication with user roles, personal preferences, instance branding, a significantly improved responsive interface with installable PWA support, progressive loading for data-intensive areas, and secure reverse-proxy header handling.

Together, these changes evolve OpenSecDash from a compact security dashboard into a complete—but intentionally understandable—security interface for homelabs:

• 📥 Datasources collect security and infrastructure events.
• 🔎 Enrichment, Insights, and correlations add useful context.
• 📊 Explorers and the customizable dashboard support investigations.
• 🔔 Notifications surface relevant activity without unnecessary alert floods.
• 🛡️ Controlled Actions allow operators to respond directly.

Despite the much broader feature set, the project's technical direction remains unchanged: self-hosted, plugin-oriented, server-side rendered, transparent, and free from unnecessary external data flows.

⚠️ Breaking Change: CrowdSec Is Now LAPI-Only

Action required for cscli users: Configure a CrowdSec LAPI URL and dedicated machine credentials after upgrading. Existing connection-mode and cscli executable-path settings are no longer used.

The previous cscli integration has been removed. CrowdSec decision synchronization and ban/unban actions now operate exclusively through the CrowdSec Local API (LAPI). Installations that already use LAPI do not require a fundamental migration.

🔐 Why cscli Was Removed

The change was made because of security concerns with the previous subprocess model. Using cscli required mounting a host executable and CrowdSec configuration into the OpenSecDash container. A configurable executable path also created an unnecessary code-execution primitive if an attacker gained access to the settings and could place or select a suitable executable.

LAPI provides everything OpenSecDash needs without mounting host binaries or CrowdSec configuration files into the container. It uses dedicated machine credentials that can be revoked independently at any time. OpenSecDash also strictly validates the configured LAPI URL and does not follow redirects for authenticated LAPI requests, helping ensure that credentials and bearer tokens are sent only to the intended endpoint.

➡️ Migration and setup instructions are available in the CrowdSec documentation.

---

What's Changed

🐛 Fixes

• Restore moved settings by @konkos1 in #56
• Support touch tooltips on trend bars by @konkos1 in #57

Full Changelog: v0.4.1...v0.4.2

v0.4.1

🚀 The Biggest OpenSecDash Update Yet

The release v0.4.x is a major milestone for OpenSecDash and the most substantial update in the project's history. Since v0.3.1, we have not merely added isolated features: core parts of the application have been expanded, redesigned, and brought together into a more complete security experience. With this release, OpenSecDash includes the full feature set defined by the current Architecture Decision Records for the first stable v1 version. Further additions such as more notification channels, an asynchronous action queue, advanced Level 2 correlations, and full offline operation remain deliberately reserved for later versions.

✨ What This Release Represents

Major additions include the complete Action Framework for controlled and auditable responses, the redesigned Insights and correlation engine, a customizable plugin-driven dashboard, shared filters and saved views for Events and Access, and the new notification framework with SMTP support.

The release also introduces optional internal authentication with user roles, personal preferences, instance branding, a significantly improved responsive interface with installable PWA support, progressive loading for data-intensive areas, and secure reverse-proxy header handling.

Together, these changes evolve OpenSecDash from a compact security dashboard into a complete—but intentionally understandable—security interface for homelabs:

• 📥 Datasources collect security and infrastructure events.
• 🔎 Enrichment, Insights, and correlations add useful context.
• 📊 Explorers and the customizable dashboard support investigations.
• 🔔 Notifications surface relevant activity without unnecessary alert floods.
• 🛡️ Controlled Actions allow operators to respond directly.

Despite the much broader feature set, the project's technical direction remains unchanged: self-hosted, plugin-oriented, server-side rendered, transparent, and free from unnecessary external data flows.

⚠️ Breaking Change: CrowdSec Is Now LAPI-Only

Action required for cscli users: Configure a CrowdSec LAPI URL and dedicated machine credentials after upgrading. Existing connection-mode and cscli executable-path settings are no longer used.

The previous cscli integration has been removed. CrowdSec decision synchronization and ban/unban actions now operate exclusively through the CrowdSec Local API (LAPI). Installations that already use LAPI do not require a fundamental migration.

🔐 Why cscli Was Removed

The change was made because of security concerns with the previous subprocess model. Using cscli required mounting a host executable and CrowdSec configuration into the OpenSecDash container. A configurable executable path also created an unnecessary code-execution primitive if an attacker gained access to the settings and could place or select a suitable executable.

LAPI provides everything OpenSecDash needs without mounting host binaries or CrowdSec configuration files into the container. It uses dedicated machine credentials that can be revoked independently at any time. OpenSecDash also strictly validates the configured LAPI URL and does not follow redirects for authenticated LAPI requests, helping ensure that credentials and bearer tokens are sent only to the intended endpoint.

➡️ Migration and setup instructions are available in the CrowdSec documentation.

---

What's Changed

✨ Enhancements

• enhance: add branded HTML email notifications by @konkos1 in #51

🐛 Fixes

• Fix web manifest for pwa with OIDC by @konkos1 in #49
• Fix mobile views and top insights links by @konkos1 in #50
• enhance: update debug report contents by @konkos1 in #52
• Fix use htmx for setting blocks by @konkos1 in #53
• Fix set correct filter in top scenarios by @konkos1 in #55

Full Changelog: v0.4.0...v0.4.1

v0.4.0

🚀 The Biggest OpenSecDash Update Yet

This release is a major milestone for OpenSecDash and the most substantial update in the project's history. Since v0.3.1, we have not merely added isolated features: core parts of the application have been expanded, redesigned, and brought together into a more complete security experience. With this release, OpenSecDash includes the full feature set defined by the current Architecture Decision Records for the first stable v1 version. Further additions such as more notification channels, an asynchronous action queue, advanced Level 2 correlations, and full offline operation remain deliberately reserved for later versions.

✨ What This Release Represents

Major additions include the complete Action Framework for controlled and auditable responses, the redesigned Insights and correlation engine, a customizable plugin-driven dashboard, shared filters and saved views for Events and Access, and the new notification framework with SMTP support.

The release also introduces optional internal authentication with user roles, personal preferences, instance branding, a significantly improved responsive interface with installable PWA support, progressive loading for data-intensive areas, and secure reverse-proxy header handling.

Together, these changes evolve OpenSecDash from a compact security dashboard into a complete—but intentionally understandable—security interface for homelabs:

• 📥 Datasources collect security and infrastructure events.
• 🔎 Enrichment, Insights, and correlations add useful context.
• 📊 Explorers and the customizable dashboard support investigations.
• 🔔 Notifications surface relevant activity without unnecessary alert floods.
• 🛡️ Controlled Actions allow operators to respond directly.

Despite the much broader feature set, the project's technical direction remains unchanged: self-hosted, plugin-oriented, server-side rendered, transparent, and free from unnecessary external data flows.

⚠️ Breaking Change: CrowdSec Is Now LAPI-Only

Action required for cscli users: Configure a CrowdSec LAPI URL and dedicated machine credentials after upgrading. Existing connection-mode and cscli executable-path settings are no longer used.

The previous cscli integration has been removed. CrowdSec decision synchronization and ban/unban actions now operate exclusively through the CrowdSec Local API (LAPI). Installations that already use LAPI do not require a fundamental migration.

🔐 Why cscli Was Removed

The change was made because of security concerns with the previous subprocess model. Using cscli required mounting a host executable and CrowdSec configuration into the OpenSecDash container. A configurable executable path also created an unnecessary code-execution primitive if an attacker gained access to the settings and could place or select a suitable executable.

LAPI provides everything OpenSecDash needs without mounting host binaries or CrowdSec configuration files into the container. It uses dedicated machine credentials that can be revoked independently at any time. OpenSecDash also strictly validates the configured LAPI URL and does not follow redirects for authenticated LAPI requests, helping ensure that credentials and bearer tokens are sent only to the intended endpoint.

➡️ Migration and setup instructions are available in the CrowdSec documentation.

---

What's Changed

⚠️ Breaking changes

• fix: removed cscli (ADR-046) by @konkos1 in #46

✨ Enhancements

• Completed action framework by @konkos1 in #32
• Dashboard rework (adr-024) by @konkos1 in #35
• Insights completion (implements adr-015 and adr-030) by @konkos1 in #36
• Notification framework completion by @konkos1 in #37
• Query filter completion by @konkos1 in #38
• Instance branding (ADR-027) by @konkos1 in #39
• Proxy header middleware (ADR-028) by @konkos1 in #40
• Internal user management (ADR-028) by @konkos1 in #42
• Personal preferences and settings by @konkos1 in #43
• Mobile pwa completion (ADR-026 & ADR-026) by @konkos1 in #44
• Progressive widget loading (ADR-026 & ADR-026) by @konkos1 in #45

🐛 Fixes

• Fix review findings by @konkos1 in #47

Full Changelog: v0.3.1...v0.4.0