Update ghcr.io/patchmon/patchmon-server Docker tag to v2.1.3

v2.1.3: Version 2.1.3

Compare Source

A bug-fix release: single sign-on with ADFS, Mattermost and Rocket.Chat webhooks, compliance content on installs outside the official Docker image, and laptops that showed as stale after waking.

Upgrading

docker compose pull
docker compose up -d

No compose changes, no new settings, no database changes. Nothing to do on your agents.

Fixes

Single sign-on failing with no email in UserInfo or id_token. Two causes, both fixed: ADFS sends single-valued claims as JSON arrays, which were not read, and an empty email in a provider's UserInfo response hid a valid one in the signed ID token. If you still see this on 2.1.3, there is a troubleshooting entry in Setting up OIDC SSO.

Mattermost and Rocket.Chat webhook destinations failed every delivery with HTTP 400. Both are now detected from their /hooks/<token> URL and sent a compatible payload. Existing destinations start working on upgrade, with nothing to configure.

Compliance content was not being served on installs outside the official Docker image, the Proxmox LXC script in particular. Agents asking for a datastream got a 503 while Compliance Settings reported the directory as empty, so this was broken rather than mislabelled. The release is now read from the datastreams themselves. If you saw that message and moved on, check your fleet's compliance versions after upgrading.

Laptops and other machines that suspend showed as stale for days after waking. The server now asks for a report when an agent reconnects past its update interval. If you shortened your update interval to work around this, you can put it back.

Worth knowing

• Generic webhook destinations: the JSON body has gained a top-level text key so any Slack-compatible receiver works without configuration. Existing fields are unchanged, but a receiver that rejects unknown keys will start returning 400.
• A single host reporting a malformed compliance version could stop SSG update checks for every host on that server, with only a logged warning. This is not new in 2.1.3.
• Downloads carry SHA256SUMS, an SBOM and a provenance attestation again. A packaging fault meant v2.1.0, v2.1.1 and v2.1.2 shipped without them.

Every change in this release

What is coming next

Bug fixes are tracked in GitHub milestones. Feature requests live on feedback.patchmon.net, where you can propose an idea, vote on existing ones, and see what has been accepted onto the roadmap.

Questions about this release

This release has its own thread under New Release Discussions. Open a new issue for a reproducible bug not already covered.

v2.1.2: Version 2.1.2

Compare Source

A small release that fixes single sign-on for Microsoft Entra ID, and adds a documented way out for any provider that cannot confirm email addresses.

Upgrading

docker compose pull
docker compose up -d

No compose changes and no new settings you have to touch. One new database column is added automatically on start.

If your SSO broke on v2.1.0 or v2.1.1

From v2.1.0, when PatchMon has to work out who you are from your email address rather than from an identity it has already stored, it requires your provider to confirm that address is verified. Otherwise anyone able to set their own email address at your provider could sign in as an existing PatchMon user. This applies when linking to an existing account and when creating one on first login, and stops applying once an account is linked.

Two widely used providers could not satisfy that. Here is where each now stands.

Microsoft Entra ID. Entra never sends the standard email_verified claim and there is no way to make it, so there was no fix short of turning off auto-creation. PatchMon now reads xms_edov instead, which is Microsoft's own "Email Domain Owner Verified" signal, added by Microsoft in response to nOAuth, the same account-takeover attack this check exists to prevent. Add it as an ID token optional claim on your app registration and sign in again. The verified email requirement has the steps, including the manifest route for when the portal marks the claim unrecognised. Nothing has to be relaxed.

Because the claim is Microsoft-proprietary, it is only accepted from a Microsoft issuer and only from the ID token, which is signature verified. Azure AD B2C and Entra External ID are not currently on that list. If a sign-in is still refused, the server log now says which check failed and why, rather than only reporting the outcome.

Authentik. Unchanged, and the answer is still to replace the default email scope mapping with one that reports the address as verified. Full steps are in The verified email requirement.

Keycloak, Okta and Google Workspace were never affected and need no action.

If your provider cannot confirm addresses at all

Some directories have no notion of a verified email address. There is now an explicit opt-in for those: Trust unverified email in Settings > OIDC, or OIDC_TRUST_UNVERIFIED_EMAIL=true. It is off by default.

Be clear about what it does. With it on, anyone who can set their own email address at your identity provider can sign in as an existing PatchMon user with that address. It is only a reasonable choice when you control who can change addresses in your directory. Every login it allows through is written to the log, so you can see whether it is being used.

If a real fix exists for your provider, use that instead. This is the fallback. Full detail in If your provider cannot assert verification at all.

Also in this release

• A provider that simply omitted the verified-email claim was treated the same as one that actively denied it. Those are now told apart, which is what makes the Entra fix possible.
• The rejection in the log now names the claims PatchMon looked for and points at the relevant guide section, rather than just stating the outcome.

Every change in this release

What is coming next

Bug fixes are tracked in GitHub milestones. Each milestone lists the issues targeted at that release, so you can follow anything you have reported through to the version it lands in.

Feature requests live on feedback.patchmon.net, where you can propose an idea, vote on existing ones, and see what has been accepted onto the roadmap.

Questions about this release

This release has its own discussion thread, filed under New Release Discussions. If something is unclear or an upgrade step has not gone to plan, check there first. Open a new issue for a reproducible bug not already covered.

v2.1.1: Version 2.1.1

Compare Source

A patch release. It clears the upgrade crash loop some installs hit on the way to v2.1.0, makes failed sign-ins visible in the log, stops antivirus quietly breaking Windows agent installs, and gives internal mail relays that offer no TLS a working configuration.

Upgrading

docker compose pull
docker compose up -d

Nothing in your docker-compose.yml changes and there are no new settings.

Two exceptions, both below: a stuck migration 42, and single sign-on with Authentik or Microsoft Entra ID. If neither applies, the two commands above are all there is to do.

If your server has been crash-looping since v2.1.0

You will see cannot set path in scalar (22023) and migration 42 marked dirty. It affects installs whose host_down alert config stored its metadata as the JSON value null. Nothing was left half applied.

Recovery, in this order:

1. Upgrade to v2.1.1 first. The fix has to be in place, or migration 42 fails again on the next boot.

2. Rewind the marker. The server will still be crash-looping, which is fine, the database container is up:

docker compose exec database psql -U patchmon_user -d patchmon_db

UPDATE schema_migrations SET version = 41, dirty = false;

Then docker compose restart server. Adjust the service name and credentials if you changed them from the stock compose file.

Full recovery guide: Server Troubleshooting.

If you use single sign-on

This one arrived in v2.1.0, not v2.1.1, It can stop SSO login working entirely, so it is worth reading before you upgrade from v2.0.x.

When PatchMon has to identify you by email address rather than by an identity it has already stored, it now requires your provider to confirm that the address is verified. Otherwise anyone who can set their own email address at your provider could sign in as an existing PatchMon user. It applies when linking to an existing account and when creating one on first login, and stops applying once an account is linked.

If your provider does not send that confirmation you get "Unable to sign in with this account", and the server log shows oidc login rejected: unverified email claim.

Step-by-step instructions for both providers: The verified email requirement.

Thanks to the people on #​1048 who worked out the Authentik fix and posted it before we had documented any of it.

What else changed

Sign-in

• Failed sign-ins are now logged. Previously a stock install recorded nothing at all when a login was rejected, so you could not tell a wrong password from a mistyped username, or see that anyone was trying.
• Guessing a username that does not exist now counts toward the account lockout. Previously only a real username could reach a 429, and that difference confirmed which accounts existed.

Windows agent

• Installs no longer die with Access is denied when antivirus holds the freshly downloaded binary. The installer waits for the scan, clears the download marker, and if it still fails it prints how to fix it instead of a stack trace. Troubleshooting on Windows

Email

• Relays that require authentication but offer no TLS now have a working configuration, as an explicit per-destination opt-in. It sends your credentials in the clear, so only enable it on a network you control. Enabling STARTTLS on the relay, even with your own internal CA, remains the better answer. Notification Destinations

Under the hood

• A dirty migration now prints the exact recovery SQL instead of leaving you to work it out.
• Built with Go 1.26.6, closing seven Go standard library vulnerabilities.

Documentation

• A complete plain-manifest Kubernetes deployment path alongside the Helm chart, for Argo CD, Flux and k3s. Includes the PostgreSQL volume mistake that silently empties your database on every redeploy. Installing PatchMon on Kubernetes
• Windows troubleshooting for the access-denied install failure.
• A "Failed Login Attempts in the Log" section, and a rewritten Account Lockout section.
• Removed an instruction to run migrations with docker compose run --rm --entrypoint migrate server up. No migrate binary exists in the image, so that could never have worked.

Every change in this release

Changes since v2.1.0.

What is coming next

Bug fixes are tracked in GitHub milestones. Each milestone lists the issues targeted at that release, so you can follow anything you have reported through to the version it lands in.

Feature requests live on feedback.patchmon.net, where you can propose an idea, vote on existing ones, and see what has been accepted onto the roadmap.

Questions about this release

This release has its own discussion thread, filed under New Release Discussions. If something is unclear or an upgrade step has not gone to plan, check there first. Open a new issue for a reproducible bug not already covered.

v2.1.0: Version 2.1.0

Compare Source

A performance, reliability and security release, tested against fleets of 1,000+ hosts.

Read this before upgrading

Three lines in your docker-compose.yml changed. docker compose pull will not apply them, because your compose file is yours.

In the server service:

    ports:
      - "${PORT:-3000}:${PORT:-3000}"   # was "3000:3000"
    hostname: patchmon-server           # new

In the guacd service:

    image: guacamole/guacd:1.6.0        # was :latest

Then:

docker compose pull
docker compose up -d

Skip those lines and PatchMon still starts, but changing PORT will break the healthcheck and remote console will not run on ARM.

Migrations run at startup and there are no other steps. Large fleets should expect a pause on first boot while the database rebuilds indexes: a few seconds on SSD or NVMe, a few minutes on slower storage. PatchMon does not serve requests while this runs, so give it time rather than assuming it has hung.

Afterwards, update your agents and set the TLS mode on each email destination.

Two dashboard numbers will change, both because they were wrong before:

• Hosts PatchMon holds no package data for were counted as Up to date. They now appear under a new Awaiting data slice, so your "Up to date" figure may drop.
• GetHomepage widget totals left out hosts you had created but not yet enrolled. The widget now counts the same way as the dashboard, so the total may rise.

The feedback portal is live

Ideas, voting, the roadmap and the changelog now live at feedback.patchmon.net. GitHub Issues stays for bug reports.

How the feedback portal works

Agents send far less, and you can see what they sent

• Agents upload only what has actually changed. A routine check-in drops from around 2 MB to around 1 KB.
• The Package Reports and Agent Queue tabs are replaced by a single Agent Activity timeline: every check-in, what kind it was, and which sections were updated or skipped. History is kept for 30 days by default and is configurable.
• Update your agents to get the reduced traffic. Older agents keep working as they are.

You can tell at a glance what is actually wrong

• Four separate status pills per host: connection, reporting, reboot pending and updates. A dropped connection no longer looks the same as a dead host.
• Status reads correctly without relying on colour alone.
• Uptime is live, rather than frozen at whatever the last report said.
• The host down alert watches the live connection instead of inferring from how long ago a host last reported. It reacts in seconds and stops flagging hosts that are plainly still connected. It is now called Host Agent Down.

Large fleets are fast again

• The Packages page loads in a fraction of a second where it previously took around ten.
• Hosts, Packages, Repositories and Alerts are paginated, with a page size that sticks between visits.
• The dashboard and sidebar no longer pull your entire host list just to show a count.
• The package total is no longer capped at 10,000, so the figure matches your database.
• Package search no longer errors out on Docker installs.

Patch runs no longer get stuck

• Stalled runs are timed out and cleared automatically instead of sitting at "running" for ever, and the timeout is configurable.
• A run is marked as disconnected if the agent drops mid-patch, and corrected if the agent comes back with a result.
• Stop Run always stops the run, even when the agent is offline, unresponsive, or holding open output from a child process.
• Long-running jobs that are genuinely still working are no longer marked as timed out.

Your distribution is read correctly

A large sweep through how the agent reads each package manager, so counts match what the host itself reports.

• Fedora and RHEL family: correct upgrade commands rather than install, banner lines no longer parsed as packages, duplicate upgradable entries removed.
• Rocky Linux: RLSA- security advisories are recognised, so security updates are classified correctly.
• Debian and Ubuntu: deb822 sources files are read properly, security updates are identified from the origin rather than the whole line, and patch all applies upgrades that pull in new packages instead of leaving them pending for ever.
• Raspberry Pi: security updates are no longer misfiled as ordinary updates, and multiple installed kernel variants no longer produce a false reboot required.
• Arch and Manjaro: inventory is collected without needing pacman-contrib, kernel detection is fixed, and a broken pacman database is reported as an error rather than as no updates.
• FreeBSD: the correct installer is served.
• LXC containers: uptime is the container's own rather than the host's.
• A host that failed to check for updates is reported as failed, rather than as fully patched.

Windows

• Windows hosts that never appeared in PatchMon at all should now appear. Some installers write stray null characters into their registry entries, and a single one anywhere in a host's package list caused every report from that host to be rejected. MeshCentral's agent is a common source, so this may account for missing hosts in mixed fleets. The same protection now covers Docker and compliance data.
• The agent no longer resets its own server address on first start.
• Updating the agent no longer fails with "Access is denied".
• The uninstall script works on PowerShell 5.1.
• Non-English characters are handled correctly in reports, collectors and install scripts.
• Reboot detection reads the registry consistently, and the agent reports its real version instead of 0.0.0.
• Windows builds, linting and runtime tests now run in CI.

Email that tells you why it failed

• SMTP destinations have a proper TLS choice (STARTTLS, SSL, none, or automatic) instead of a single toggle. Existing destinations keep working, but picking the right one means a broken or tampered relay fails rather than quietly sending anyway.
• Port 465 servers requiring implicit TLS now work, instead of failing with an end-of-file error.
• A new Send test email button does a real send and tells you which step failed, whether that is the connection, TLS, the login or delivery, with the mail server's own message.
• Long lines and long subjects are encoded properly rather than being mangled in transit.

Security

• Client IP addresses could be spoofed behind a reverse proxy, which affected rate limiting, login lockouts and activity log entries. A new trusted proxy setting controls which upstream addresses are believed, and the default is correct for standard deployments.
• The rate limiter could leave a counter with no expiry, stranding an address at HTTP 429 with no way back.
• Every issued token is bound to a session, and refresh tokens are no longer accepted in place of a sign-in token, so signing out, revoking a session, changing a password and deactivating an account take effect immediately.
• Accounts created through the initial setup or the sign-up page could not be signed out remotely, because their session had no way to be revoked.
• Linking a Discord or single sign-on identity to an existing account now requires a verified email address and explicit confirmation from the account owner, rather than happening automatically on an email match.
• Two-factor verification requires the first sign-in step to be completed successfully before the code is accepted.
• Sign-in messages are uniform, and no longer vary depending on whether an account exists for the address entered.
• Single sign-on fixes: an error during sign-on could assign the wrong role to a new account, logins were rejected when the provider reported email verification in an unexpected format, and saving settings while a user was signing in applied the wrong auto-create behaviour to that login.
• The idle session timeout setting now works.
• Server address, port and package name inputs are validated more strictly before they reach the installer scripts or the system package manager.
• Repository credentials are redacted from agent logs, including when an update check fails.
• Images and release binaries are published with an SBOM and build provenance.

The API now agrees with the interface

If you have ever queried the API and found a host reported as active while the interface showed it as Inactive, that is fixed.

The status field was never a liveness signal. It records how far a host got through enrolment, so once a host has checked in it stays active for ever, even if it never reports again. The interface has always calculated liveness separately, on the fly, from when the host last reported.

Rather than change what status means and break anyone relying on it, host responses now carry an extra effective_status field holding exactly what the interface displays: pending, active or inactive. It is available on the scoped hosts API, the admin host list, the hosts-in-a-group listing and host detail. Alongside it, reporting_state tells you how fresh a host's data is (reporting, overdue, stale) and update_state tells you whether it needs patching.

The API documentation now sets out which of these four fields answers which question.

Also in this release

• Compliance scanner installs complete reliably, including on Ubuntu 24.04 and Rocky Linux 8 and 9. Scan history and rules search and sort properly, timings are correct, and stalled scans are swept hourly rather than daily.
• The daily compliance content check no longer re-downloads the same archive every day.
• Remote console runs on ARM again.
• Changing the PORT setting works, rather than breaking the healthcheck.
• Background jobs honour Redis TLS and Redis usernames, so they no longer fail while the rest of the server connects fine.
• A sweep through every filter, sort and clickable stat card in the app so they all do what they say.
• Refresh now refreshes the whole screen rather than a single panel, and routine actions no longer wipe unsaved edits elsewhere on the page.
• The legacy bare-metal installer is removed.
• Dependency and toolchain updates across the server, agent and frontend.

New and changed settings

All new settings are optional and defaulted correctly. None needs setting on a standard install.

One default has changed. ENABLE_LOGGING now defaults to true. The server previously wrote no application logs at all unless this was explicitly turned on, which made every "check the logs" instruction useless. If you have ENABLE_LOGGING=false in your .env, or logging turned off in Settings, that is still honoured. If you never set it, you will start seeing logs after upgrading.

Every fix in this release

Changes since v2.0.2. Numbers refer to issues and pull requests on github.com/PatchMon/PatchMon. Where a fix landed without a pull request, the commit is given instead.

Agent: package managers and OS detection

Agent: Windows

Agent: connectivity and reporting

Patching

Compliance

Dashboard, hosts and interface

Integration API

Sign-in, users and settings

Email

Server, Docker and infrastructure

Changes without an issue number

What is coming next

Bug fixes are tracked in GitHub milestones. Each milestone lists the issues targeted at that release, so you can see which fixes are queued for the next version and follow anything you have reported through to the release it lands in. The milestone for this release records every fix that went into it.

Feature requests are not tracked on GitHub. They live on feedback.patchmon.net, where you can propose an idea, vote on the ones already there, and see what has been accepted onto the roadmap.

Please do note, that future releases will be small and in more of an agile format, the community got together and we discussed this and other project status / plans - the recording of this is on the YouTube channel.

We understand that there are still some bugs under Compliance, Windows integration and Docker integration. These are going to be addressed over the next few more minor releases.

Questions about this release

This release has its own discussion thread, linked at the top of this release page and filed under New Release Discussions.

If something here is unclear, an upgrade step has not gone to plan, or you think this release has changed behaviour you were relying on, please check that thread first. Others are likely to have hit the same thing, and answers about this specific release are collected there rather than spread across new issues.

Open a new issue for a bug you can reproduce that is not already covered in the thread.

Many thanks, from Iby and the PatchMon team.