DEV Community: puppet

Puppetlabs Modules Now Have Tiered Review Cycles

Jason St-Cyr — Tue, 14 Jul 2026 14:16:39 +0000

If you've been watching the Puppetlabs namespace on the Forge (or waiting on a pull request you opened) you've likely noticed that the pace of inclusion of community pull requests and fixes into the module releases has slowed over the last several cycles. That isn't how we want to serve the community that built these modules with us. The team has been reviewing how we can improve and this post is our commitment to do better. Here are the steps we're taking now:

Clear tiers with review cadences. Modules in the puppetlabs namespace will be grouped into three tiers, each with a defined review schedule (weekly, monthly, or quarterly).
Defining what “review cadence” means in practice. Every community PR gets engineering review in the next scheduled cycle for that module’s tier.
Showing progress monthly. We’ll continue to publish the monthly Modules Roundup covering what was released.

A Tiered Approach to Priorities

We've categorized supported modules in the puppetlabs namespace into three tiers, each with a defined community review cadence:

Tier	Count	Community review cadence
Tier 1: core, business-critical modules	25	Weekly
Tier 2: important, meaningfully used modules	19	Monthly
Tier 3: niche or low-usage modules	22	Quarterly

What a Review Cadence Means

Every community pull request (PR) on a module in the puppetlabs namespace gets engineering review during the next scheduled cycle for that module's tier. This doesn’t mean that every PR will be accepted. Sometimes a pull request needs feedback or changes, some pull requests won't fit a module's direction, but the cadence is intended to make sure that PRs will no longer sit quietly in a queue. That is the baseline we're holding ourselves to with these tiers and review cadences.

We do have a backlog of requests over the years and we will be working through that backlog as well, but priority will be given to active contributions for the purposes of our review cadence.

Tier 1: Our highest-priority modules

The following modules are our committed Tier 1 set. These modules will get a weekly review, with nightly CI coverage, and get priority on maintenance capacity:

puppetlabs-apache
puppetlabs-apt
puppetlabs-augeas_core
puppetlabs-concat
puppetlabs-cron_core
puppetlabs-docker
puppetlabs-firewall
puppetlabs-haproxy
puppetlabs-inifile
puppetlabs-java
puppetlabs-java_ks
puppetlabs-lvm
puppetlabs-mount_core
puppetlabs-mysql
puppetlabs-ntp
puppetlabs-package
puppetlabs-postgresql
puppetlabs-powershell
puppetlabs-reboot
puppetlabs-registry
puppetlabs-ruby_task_helper
puppetlabs-service
puppetlabs-sshkeys_core
puppetlabs-stdlib
puppetlabs-vcsrepo

Tier 2: Monthly reviews

The following modules have currently been assigned to our Tier 2 for prioritization. These modules will get a monthly review.

puppetlabs-accounts
puppetlabs-acl
puppetlabs-bolt_shim
puppetlabs-chocolatey
puppetlabs-facter_task
puppetlabs-iis
puppetlabs-kubernetes
puppetlabs-motd
puppetlabs-mount_iso
puppetlabs-node_encrypt
puppetlabs-puppet_conf
puppetlabs-satellite_pe_tools
puppetlabs-scheduled_task
puppetlabs-sqlserver
puppetlabs-sslcertificate
puppetlabs-tomcat
puppetlabs-windows_env
puppetlabs-windows_eventlog
puppetlabs-wsus_client

Tier 3: Quarterly reviews

The modules assigned to Tier 3 are still supported but will not generally be getting a high degree of priority. These modules will be reviewed quarterly and released as needed.

ca_extend
influxdb
puppet_operational_dashboards
puppetlabs-bash_task_helper
puppetlabs-dropsonde
puppetlabs-dsc_lite
puppetlabs-facts
puppetlabs-host_core
puppetlabs-node_manager
puppetlabs-pe_databases
puppetlabs-pe_event_forwarding
puppetlabs-pe_status_check
puppetlabs-puppet_bolt_server
puppetlabs-puppet_metrics_collector
puppetlabs-puppet_status_check
puppetlabs-selinux_core
puppetlabs-splunk_hec
puppetlabs-yumrepo_core
puppetlabs-zfs_core
puppetlabs-zone_core
ruby-pwsh
support-tasks

The Product and Engineering teams are still reviewing the puppetlabs modules for final placement in Tier 2 or Tier 3 and will follow the cadence associated with their tier once that placement is confirmed. Ultimately, the lists above might shift slightly as the team finds that some modules might need more attention than others.

What has already shipped?

It is one thing to say you will do better and quite another to follow through. We’re sharing this now because we have tangible changes already underway. In a focused sprint on Tier 1 modules, the team triaged and actioned several open community pull requests, some merged after review, some closed after discussion, others consolidated with newer work. You’ll see several modules released this month and next with these merged changes on the Forge. Keep an eye on the Forge modules list or check out the next Puppet Modules Roundup post for a summary!

On the Issues With CI for community PRs

We're aware that testing community contributions has been harder than it should be. The current pull request model makes it difficult to run the full acceptance test suite against a contributor's PR without manual effort by Perforce employees, which slows reviews and discourages contributions. Solving this is a priority for the team and we have been prototyping an improved approach that will meet both user expectations and maintaining a secure infrastructure. We’ll share specifics once it's working end-to-end. This is a known gap we're committed to closing.

How We'll Show Our Work

Monthly Modules Roundup. We publish a roundup each month covering what modules have been released, who contributed, and what’s next. You can follow the series here: Puppetlabs Modules Roundup on dev.to.
Contributor recognition. The release notes on the Forge and in the monthly roundup will call out merged community PRs by name.
Public GitHub transparency. We will be following up with contributors directly in pull requests and issues in our open source modules. In advance of a release, we will continue to merge and close PRs so that you can see what will be included in an upcoming release.

How can you help?

Keep contributing! Keep filing issues. Keep telling us when a module is in your way. If a PR of yours has stalled out, please rebase it or comment on the PR. And if the tiering above looks wrong for how you use Puppet day-to-day, let us know! The whole point of publishing this article is so that the community can understand what is changing and also to invite you to shape where the priority goes.

Tiering is not a one-way decision. 

The tiers outlined here have been based on the activity we have observed in our analytics and the importance identified by customers. If a module you depend on isn't in the tier you think it should be, or perhaps a long-waiting PR or issue is blocking you, reach out via the Puppet Community Slack or leave a comment on the monthly Puppet Modules Roundup posts. We want your input to make sure the tiering meet the needs of all our users.

Driving Value from Puppet Metrics: Puppet Observability Data Connector

klab-systems — Mon, 13 Jul 2026 16:28:45 +0000

What is the Puppet Observability Data Connector?

The Puppet Observability Data Connector is a premium Forge module included with Puppet Enterprise Advanced (PEA). This module provides a deeper dive into your Puppet agent reports. Visualizing these metrics gives you a great way to identify what is healthy and unhealthy in your environment.

Behind the scenes, this module provides 2 core functionalities.

It provides a report processor to convert Puppet reports into usable metrics.
It manages an exporter to serve these metrics for your time series database to scrape.

Example Metrics

Failed nodes
Changed nodes
Catalog cache failures
Stale nodes
Corrective changes
Out of sync resources
Average total run time
Max run time
Run time breakdowns
- Total run time
- Fact generation time
- Catalog application time
- Config retrieval time
- Plugin sync time
- Convert catalog time
Managed resource count by host
Managed resource count over time
Catalog application time trends

Using the metrics provided by Puppet Observability Data Connector, you can make impactful dashboards. Below are some examples that I have created.

Note: All dashboards can be filtered by the environment and/or host. All thresholds for color coding can be modified to fit your environment.

Fleet Status Dashboard Example

This example 'Fleet Status' dashboard provides an always-open first-look insight into whether anything in your fleet requires immediate attention. I will break this down by section.

When to Use a Fleet Status Dashboard?

After deploying Puppet code to confirm no regressions
During incidents to identify affected nodes
As part of a daily ops review to verify fleet-wide compliance

Fleet Health Summary (stat panels)

A top-level count of nodes in each state from the most recent run. Six stats that give you an instant fleet pulse without scrolling.

What this tells you:

Term	Description
Total Nodes Reporting	Quantity of nodes submitting reports; this number should be 1:1 with the amount of Puppet agent managed nodes in your environment
Failed Nodes	Nodes where `puppet_status{state="failed"} == 1;` any non-zero value requires immediate investigation
Changed Nodes	Nodes where Puppet applied changes in the last run; expected after a code push, unexpected otherwise
Unchanged Nodes	Nodes fully converged — your desired steady state
Catalog Cache Failures	Nodes that could not obtain a fresh catalog and fell back to a cached one. Triggers on server/network unreachable or any catalog compilation error (duplicate resource declaration, undefined variable, syntax error, missing module)
Stale Nodes (>2h)	Nodes that haven't reported in over two run intervals; the agent may be down, hung, or disconnected

Node Run Status (bar gauges)

Per-node breakdowns of the two most critical run-level signals.

What this tells you:

Term	Description
Time Since Last Puppet Run	Minutes since each node last phoned home. Green = within one run interval (~30 min), yellow = approaching stale, red = definitely stale. Use to find silent failures where the agent has stopped running entirely.
Transaction Completed by Host	Whether the last run completed (1) or was aborted mid-run (0). An aborted transaction means the node's actual state is unknown — treat it the same as a failure.

Compliance & Drift (stats + bar gauges + time series)

This section separates intentional changes (deployments) from unintentional drift (external actors modifying managed state).

What this tells you:

Term	Description
Total Corrective Changes (Fleet)	Aggregate count of corrective changes across all nodes. A corrective change means Puppet found a resource in the wrong state and fixed it — something external changed it. Persistent non-zero values are a compliance red flag.
Total Failed Resources (Fleet)	Resources that Puppet attempted to enforce but could not. Non-zero always warrants investigation.
Total Event Failures (Fleet)	Resource-level event failures, which can appear even on nodes not marked failed. Catches partial failures.
Total Out-of-Sync Resources (Fleet)	Resources declared in the catalog but not yet in the desired state. Elevated values indicate pending convergence or a broken dependency chain.
Corrective Changes by Host	Identifies which specific nodes are experiencing drift. Nodes with persistent corrective changes may have rogue processes or manual interventions overwriting Puppet-managed state.
Failed Resources by Host	Identifies which nodes have broken resources. Cross-reference with the node's Puppet report for the specific resource type and error message.
Corrective Changes Over Time	Trend view — spikes correlate with manual changes, automated tooling conflicts, or software self-repair mechanisms overwriting managed files.
Failed Resources Over Time	Trend view — a step-change increase after a code push indicates a bug in new Puppet code. A gradual increase may indicate environment drift.

Catalog Cache Status (stats + bar gauge)

Catalog cache usage is a leading indicator of Puppet infrastructure health, often surfacing issues before nodes start failing outright.

What this tells you:

Term	Description
Nodes: Cache Used on Failure	A fresh catalog could not be obtained. Common causes: Puppet server unreachable, network failure, or a catalog compilation error (duplicate resource declaration, undefined variable, syntax error, missing module). The node ran with a potentially stale catalog — investigate PE server logs and the agent's last run report.
Nodes: Cache Explicitly Requested	Nodes intentionally running offline (e.g., --use-cached-catalog). Expected during planned maintenance; unexpected otherwise.
Nodes: No Cache (Fresh Catalog)	Healthy nodes compiling a fresh catalog every run — your desired steady state.
Catalog Cache on Failure – by Host	Pinpoints which nodes are falling back to cache. Use to determine whether it's a widespread compiler/network issue or a node-specific catalog compilation error (check that node's agent log for the exact cause).

Full Dashboard Snapshot

Run Performance Example Dashboard

This example 'Run Performance' dashboard acts as your performance and capacity planning dashboard. It answers whether Puppet is running efficiently and helps you locate bottlenecks before they become outages. I will break this down by section.

When to use a Run Performance dashboard?

Run times are creeping up across the fleet
After adding new modules or resource types to identify compile/apply costs
To compare performance across environments (production vs. feature_demo)
When planning infrastructure scaling (for example, adding more compilers or faster agents)

Performance Summary (stat panels)

Fleet-wide performance KPIs. These numbers represent your overall SLA for Puppet run completion.

What this tells you:

Term	Description
Avg Total Run Time	The mean end-to-end run duration across all selected nodes. Green < 120s, yellow 120–300s, red > 300s.
Max Total Run Time	The slowest node in the fleet — identifies outliers dragging down SLA.
Avg Fact Generation Time	How long Facter is taking on average. This phase runs before catalog compilation so delays here block everything downstream.
Avg Catalog Application Time	How long Puppet spends enforcing resources. A reliable proxy for catalog complexity and system responsiveness.

Run Time Trends (time series)

Long-term trend views to distinguish persistent regressions from one-off anomalies.

What this tells you:

Term	Description
Total Run Time Over Time	The most important single trend. A sudden step-change after a deployment indicates new expensive resources. A gradual increase over weeks suggests catalog bloat or system degradation. A red threshold line at 300s provides a visual SLA boundary.
Fact Generation Time Over Time	Isolates Facter performance from the rest of the run. Upward trends often indicate new custom facts, growing hardware inventories, or external fact sources becoming slow.

Run Time Breakdown – Latest Run (by Host) (bar gauges)

Per-node, per-phase timing from the most recent run. Use this to pinpoint which phase is slow on which node rather than just knowing the total is high.

What this tells you:

Panel	Phase	Optimization Lever
Total Run Time	End-to-end wall clock	—
Fact Generation Time	Running Facter	Audit custom facts; disable unused external facts
Catalog Application Time	Enforcing all resources	Reduce catalog size; identify slow resource types (Package, Exec)
Config Retrieval Time	Fetching compiled catalog from PE server	Scale compilers; check network latency between agent and server
Plugin Sync Time	Downloading Puppet functions/types/providers	Audit and prune modules; check if all plugins are necessary
Convert Catalog Time	Transforming compiled catalog into apply-ready format	Indicates catalog structural complexity

Resource Catalog (bar gauge + time series)

Catalog size is the root cause of many performance problems. These panels correlate resource count with run time.

What this tells you:

Term	Description
Total Managed Resources by Host	Nodes with significantly more resources than peers warrant investigation — are all those resources intentional? `pe.klab.internal` managing 2,419 resources vs 61 for simpler nodes is expected for a PE server; unexpected divergence between similar nodes is not.
Total Managed Resources Over Time	A sudden jump indicates a code change added many new resources. Gradual growth over months indicates catalog bloat — exported resources collecting without cleanup, or defined resource types generating more instances than expected.

Catalog Application Time Trends (time series)

Deeper trend analysis for the two phases most sensitive to infrastructure and code changes.

What this tells you:

Term	Description
Catalog Application Time Over Time	Correlate spikes with git commit timestamps. A spike immediately following a deployment confirms the new code introduced expensive resources. Persistent elevation after the spike stabilizes means the cost is structural, not transient.
Config Retrieval Time Over Time	Sustained increases across all nodes simultaneously point to a PE server bottleneck (JVM heap, database pressure, or compiler overload). Increases on a single node suggest agent-side network issues.

Full Dashboard Snapshot

Download the Puppet Data Connector Forge Module

Want to try it in your environment? Download the premium Forge module now.

Get the Module

Wrap-up

The Puppet Observability Data Connector provides valuable information about the Puppet agent nodes across your environment. Visualizing these metrics gives organizations key insights, allowing team members to identify problems, measure performance, and track changes. The dashboards shown here are just one of the many ways to drive value from your Puppet metrics.

For assistance driving value from your Puppet metrics please ask your account team about how Professional Services could help you with dashboards that match your environment and operational priorities.

Puppetlabs Modules Roundup – June 2026

Jason St-Cyr — Thu, 09 Jul 2026 19:38:46 +0000

In June 2026 we saw the release of a new stdlib 10 that was mentioned in an earlier article along with numerous modules bumped to use the new stdlib 10. In total, 24 Puppetlabs modules were released to the Forge, ranging from a brand-new Windows security policy module to a large batch of third-party CVE fixes in Security Compliance Management. This roundup pulls the most important changes into one place.

Highlighted Updates

New Module: Windows Local Security Policy Management

The new security_policy module manages Windows local security policy using the Puppet Resource API, replacing manual secedit/Local Security Policy editor work.

Provides the security_option and user_right_assignment resource types, covering all 45 Windows Privilege Rights and the System Access settings.
Ships a well-known SID map with a PowerShell fallback for domain and custom accounts.

stdlib 10.x Compatibility Pass

A coordinated maintenance pass loosened the puppetlabs/stdlib dependency constraint across the module set to allow stdlib 10.x, clearing the way for downstream modules to pick up stdlib's latest release.

Affected modules: accounts, apache, apt, chocolatey, concat, docker, firewall, haproxy, inifile, lvm, motd, mysql, ntp, postgresql, wsus_client.

More modules will be released in July as we roll out the support for stdlib 10.x.

Puppet Core Alignment / Puppet 7 Support Dropped

Several modules completed their Puppet Core alignment pass this month, dropping Puppet 7 support in favor of Puppet 8 as Puppet 7 reaches end-of-life.

Affected modules: accounts, chocolatey, haproxy, java, motd, mysql, postgresql, stdlib.

A note that the change to drop Puppet 7 in postgresql was done in a patch release, instead of a major release. This has been corrected in postgresql 10.6.3 and the change will be done again in a major release of that module.

Security Compliance Management Patches ~40 CVEs

Security Compliance Management 3.8.0, shipped as both comply and complyadm, updates a long list of bundled third-party components — Gorm.io, Protobuf, several Netty codec libraries, react-router, and KeyCloak — to close out roughly 40 CVEs.

Also updates the bundled CIS-CAT Pro Assessor to v4.63.0, adding new STIG benchmarks for Amazon Linux 2023, Windows 11, Oracle Linux 9, and RHEL 10.

What Updates Happened to Puppetlabs Modules in June 2026?

The following is an alphabetical listing of modules which received updates in June 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

accounts 9.0.0

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

This release drops Puppet 7 support (BREAKING) as part of the module's Puppet Core alignment work, and allows the stdlib dependency to move to 10.x.

(CAT-2352) Drop Puppet 7 support (BREAKING) — Puppet Core alignment #509 (LukasAud)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #513 (imaqsood)

apache 13.2.0

📅 Latest release: 2026-06-28 (🌐 View on the Forge)

Adds RHEL 10 support, restores the ModSecurity engine on RHEL 10 via EPEL, and allows both stdlib and concat to move to their 10.x releases.

Add missing parameters to mod_md #2621 (smortex)
(MODULES-11851) Restore ModSecurity engine on RHEL 10 via EPEL #2635 (SugatD)
(MODULES-11739) Add RHEL 10 support #2629 (SugatD)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #2632 (imaqsood)
puppetlabs/concat: Allow 10.x #2630 (bastelfreak)

apt 11.3.2

📅 Latest release: 2026-06-26 (🌐 View on the Forge)

A small release that only bumps the stdlib dependency to allow 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #1288 (imaqsood)

aws_inventory 0.8.0

📅 Latest release: 2026-06-17 (🌐 View on the Forge)

This release allows the ruby_task_helper dependency to move to 1.x.

Allow ruby_task_helper 1.x #25 (bastelfreak)

chocolatey 9.0.0

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Completes its Puppet Core alignment pass, improves package prefetch caching with case-insensitive matching, and allows stdlib 10.x.

(CAT-2369) Puppet Core update #378 (LukasAud)
(MODULES-11769) Cache prefetch results and match packages case-insensitively #388 (skyamgarp)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #387 (imaqsood)

comply 3.8.0

📅 Latest release: 2026-06-12 (🌐 View on the Forge)

Security Compliance Management 3.8.0 addresses roughly 40 CVEs across bundled third-party components, alongside operational fixes and licensing improvements.

Increased the CIS-CAT Pro Assessor license expiry time to a full year.
Added a license_path parameter to update the CIS-CAT Pro Assessor license without upgrading SCM.
Added an assessor_scan_timeout option to control the task timeout for Windows 2022 domain controllers.
Added a background scan sweeper to detect and cancel scans stuck in the "running" state.
Fixed a race condition where timed-out PE job status polls could leave scans permanently stuck.
Updated Gorm.io, Protobuf, multiple Netty codec libraries, react-router, and KeyCloak to address roughly 40 CVEs.

Check the official release notes for comply 3.8.0 for the full details.

complyadm 3.8.0

📅 Latest release: 2026-06-12 (🌐 View on the Forge)

Ships the same Security Compliance Management 3.8.0 update as comply, covering the same ~40 CVE remediations and operational fixes.

Increased the CIS-CAT Pro Assessor license expiry time to a full year.
Added a license_path parameter to update the CIS-CAT Pro Assessor license without upgrading SCM.
Added an assessor_scan_timeout option to control the task timeout for Windows 2022 domain controllers.
Added a background scan sweeper to detect and cancel scans stuck in the "running" state.
Fixed a race condition where timed-out PE job status polls could leave scans permanently stuck.
Updated Gorm.io, Protobuf, multiple Netty codec libraries, react-router, and KeyCloak to address roughly 40 CVEs.

Check the official release notes for complyadm 3.8.0 for the full details.

concat 10.0.1

📅 Latest release: 2026-06-25 (🌐 View on the Forge)

This targeted release was part of the wave of bumps for the stdlib dependency to allow 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #837 (imaqsood)

docker 10.4.1

📅 Latest release: 2026-06-28 (🌐 View on the Forge)

Removes the upper version limit on the puppetlabs/apt dependency, fixes compose up argument ordering, and allows stdlib 10.x.

Do not limit puppetlabs/apt requirement < v12 #1056 (mpdude)
Fix argument order on compose up #1037 (deligatedgeek)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #1057 (imaqsood)

edgeops 1.1.0

📅 Latest release: 2026-06-25 (🌐 View on the Forge)

Adds host key fingerprint verification for Bolt 5.1.0+ targets, along with a batch of NETCONF/SSH hardening fixes.

(PE-43703) Verify host key fingerprints supplied as host-key-fingerprint in the target hash; takes precedence over host-key-check and requires Bolt 5.1.0+. #38 (owenbeckles)
(PE-42584) Correctly handle host key verification parameter #23 (Ziaunys)
(PE-43619) Clean up SSH on timeout and always raise instead of returning partial data #33 (Ziaunys)
(PE-43614) Add mutex synchronization for RPC message ID allocation #29 (Ziaunys)
(PE-43652) Rename netconf_lock task to netconf_check_lock #35 (Ziaunys)

firewall 8.5.0

📅 Latest release: 2026-06-25 (🌐 View on the Forge)

Two releases this month: 8.4.0 added CONNMARK-based policy routing support and several bugfixes, while 8.5.0 allows stdlib 10.x, drops iptables-services from EL9+ package defaults, and fixes several ipset and chain-detection edge cases.

Includes monthly releases: 8.5.0 (2026-06-25), 8.4.0 (2026-06-10).

(MODULES-11840) Allow puppetlabs/stdlib 10.x #1288 (imaqsood)
(#1254) Remove iptables-services from EL9+ package defaults #1296 (david22swan)
(feat) Add restore_mark, nfmask, ctmask support for CONNMARK-based policy routing #1291 (david22swan)
(bugfix) Fix ipset idempotency: single-element array not in sync with String equivalent #1286 (david22swan)
(bugfix) Fix log_level idempotency when explicitly setting the iptables default value #1284 (david22swan)

haproxy 8.2.1

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Completes the module's Puppet 8 upgrade work, drops Puppet 7 support, and allows stdlib 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #642 (imaqsood)
(CAT-2373) Remove puppet 7 #631 (gavindidrichsen)
(CAT-2373)(02) Upgrade module to puppet 8 #629 (gavindidrichsen)

inifile 6.4.1

📅 Latest release: 2026-06-25 (🌐 View on the Forge)

A small release to allow stdlib 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #570 (imaqsood)

java 12.0.0

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Adds CentOS 9 and Debian 13 support, allows stdlib 10.x, and adds support for downloading from a login/password-protected URL.

(CAT-2376) Puppet Core update #614 (LukasAud)
(CAT-2152) Add support for CentOS 9 #606 (skyamgarp)
Add support for Debian 13 (trixie) #613 (mika)
Feat: Allow downloading from a login/password protected URL #588 (JGodin-C2C)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #626 (imaqsood)

lvm 4.0.2

📅 Latest release: 2026-06-28 (🌐 View on the Forge)

This lvm release bumps the stdlib dependency to allow 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #384 (imaqsood)

motd 8.0.0

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Adds Bolt 5.0 support, and allows stdlib 10.x.

(CAT-2352) Puppet Core update #531 (LukasAud)
(CAT-2463) Add bolt 5.0 support #535 (gavindidrichsen)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #558 (imaqsood)

mysql 17.0.0

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Fixes the RHEL/CentOS Stream 10 version check, and allows stdlib 10.x.

(CAT-2381) Puppet Core update #1688 (LukasAud)
Fix version check for RHEL/CentOS Stream 10 #1686 (kajinamit)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #1707 (imaqsood)

ntp 11.1.1

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

A small release that only bumps the stdlib dependency to allow 10.x.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #742 (imaqsood)

peadm 3.38.0

📅 Latest release: 2026-06-30 (🌐 View on the Forge)

Adds support for installing and upgrading to Puppet Enterprise 2023.8.10 and 2025.11.0, along with a cloud_database_host parameter for cloud-DB-backed installs.

Adding support for PE 2023.8.10 and 2025.11.0 #673 (CharithaDunuwille)
(PE-44022) Add cloud_database_host parameter for cloud-DB-backed installs #665 (mcdonaldseanp)
(PE-44247) Add peadm-path PG-major HA upgrade coverage for replica pe-puppetdb #666 (steveax)
(PE-44595) Don't emit empty dns_alt_names flag in subplans::install #672 (steveax)

postgresql 10.6.2

📅 Latest release: 2026-06-29 (🌐 View on the Forge)

Adds basic EL10 support, allows both stdlib and concat to move to their 10.x releases, and fixes a bug where postgresql_conf resources set to absent were handled incorrectly.

NOTE: This release also incorrectly removed Puppet 7 support as a breaking change in a patch release. This has since been rolled back in 10.6.3. Removing Puppet 7 support will happen in a future major release.

add EL10 basic support - align EL10 PGSQL 16 default package version #1650 (ikonia)
fix: ignore postgresql_conf resource value when set to absent #1657 (davidassigbi)
grant creation via hiera through server::grant.pp #1668 (ikonia)
(MODULES-11840) Allow puppetlabs/stdlib 10.x #1681 (imaqsood)
puppetlabs/concat: Allow 10.x #1669 (bastelfreak)

sce_linux 2.7.0

📅 Latest release: 2026-06-16 (🌐 View on the Forge)

Adds CIS Benchmark support for the RHEL 10 family, fixes an rsyslog configuration file that was unconditionally overwritten, and drops RHEL 7 now that it's end of life.

Support for RHEL 10, AlmaLinux 10, Oracle Linux 10, and Rocky Linux 10. Enforces the CIS Benchmark for RHEL 10 (v1.0.1, Server Levels 1 and 2) and CIS Benchmark v1.0.0 for AlmaLinux 10, Oracle Linux 10, and Rocky Linux 10.
rsyslog.conf file unconditionally overwritten. Previously overwritten on every Puppet run even when logging configuration was set to ignore, affecting RHEL 7/8/9 and derivatives. No action required from users.
Advanced Intrusion Detection Environment (AIDE) utility class. Fixed incorrect configuration options generated for AIDE 0.19.x on RHEL 9 that caused aide --init to fail.
RHEL 7. RHEL 7 is end of life and no longer supported.

Check the official release notes for sce_linux 2.7.0 for the full details.

security_policy 1.0.0

🌟 New Module: 2026-06-25 (🌐 View on the Forge)

Brand-new module for managing Windows local security policy. Provides the security_option and user_right_assignment resource types (Puppet Resource API), covering all 45 Windows Privilege Rights and System Access settings. Initial release contains:

security_option and user_right_assignment resource types for managing Windows local security policy settings via secedit.
security_policy class exposing 45 Optional[Array[String]] parameters (one per privilege right), matching the layout of the legacy dsc/securitypolicydsc module.
PuppetX::Sid module: a static well-known SID map covering the 19 standard SIDs, with a PowerShell fallback via Pwsh::Manager for domain and custom accounts.
YAML-driven setting metadata loader (PuppetX::SecurityPolicy.all_settings) instead of a hardcoded settings hash.
Puppet requirement pinned to >= 8.0.0 < 9.0.0.

stdlib 10.0.1

📅 Latest release: 2026-06-30 (🌐 View on the Forge)

Drops Puppet 7 support, adds CentOS 9 support, extends Sensitive value support to more functions, and fixes has_ip_address/has_ip_network.

(CAT-2395) Puppet Core upgrade - drop support for Puppet 7 #1457 (LukasAud)
(CAT-2152) Add support for CentOS 9 #1442 (skyamgarp)
Support Sensitive values in more functions #1463 (alexjfisher)
Support sensitive values in to_json_pretty #1418 (alexjfisher)
Fix has_ip_address and has_ip_network functions #1448 (alexjfisher)

wsus_client 6.3.1

📅 Latest release: 2026-06-25 (🌐 View on the Forge)

stdlib 10.x now allowed as part of the dependency range bump.

(MODULES-11840) Allow puppetlabs/stdlib 10.x #238 (imaqsood)

Until Next Time!

That wraps up the June 2026 roundup. If any of these modules intersect with your environment — especially the Security Compliance Management CVE fixes — the linked Forge pages and release notes are worth a closer look.

Feedback on the series is always useful, especially if there are module families or release-note patterns that deserve more attention in future editions.

More updates coming next month when the July 2026 releases land.

🤖 AI Disclosure

This roundup is produced by a mostly-automated pipeline, with some AI sprinkled in for orchestration and enrichment (or 'Combobulating' and 'Finagling'), followed by a human review (that would be me) before publishing.

The automation is an open-source project with deterministic python scripts to crawl the Forge and determine which puppetlabs modules were released during a specific month (and catching when a module gets more than one release in a month). By combining a template, automation scripts, and some AI orchestration the content all gets pulled together for a structured markdown document. I then jump in to double-check the content and update any wording that seems repetitive or irrelevant (and sometimes I need to add some extra context that isn't in the changelog notes).

Puppet Core 8.20 adds Ubuntu 26.04 and Security Fixes

Jason St-Cyr — Mon, 06 Jul 2026 12:15:19 +0000

The latest release of Puppet Core was targeted at addressing reported CVEs and adding agent support for Ubuntu 26.04, along with some other items that might be of interest to you! Here's a quick rundown on the highlights:

Ubuntu 26.04 (x86_64 and ARM) support added for Puppet agents
Updated components for OpenSSL, net-imap, and concurrent-Ruby to address 13 CVEs
Sensitive values are now handled correctly in transactionstore.yaml
On macOS, plist files are now written atomically to prevent partial or zero-length reads.
PXP agent metadata now uses uniquely named temporary files to resolve file-rename race conditions that were happening for Windows tasks.

This was just my quick summary of the notes, so make sure to read the full release notes for Puppet Core 8.20 to get all the details before you upgrade!

Puppet Enterprise Introduces Database-Backed CA Storage in 2025.11 release

Jason St-Cyr — Thu, 02 Jul 2026 15:32:28 +0000

The latest Puppet Enterprise releases are out and this one has a huge load of improvements, fixes, and security patches included!

Puppet Enterprise (PE) 2025.11 released!

The full PE 2025.11 release notes are always the best way to get a full detail on what has changed, but here are some highlights of PE 2025.11!

Certificate Authority (CA): Database-backed Storage

This new optional feature adds support for storing CA data in a PostgreSQL database instead of the file system. This improves performance and reliability and introduces API-driven capabilities and enhanced backup and recovery handling.

PostgreSQL 17 Supported

PE-managed installations will automatically upgrade from verson 14 to 17 as part of the upgrade process, or you can update yourself before upgrading to PE 2025.11

Infra Assistant Goes GPT-5

GPT-5 series models are now running under the hood of Infra Assistant, improving the quality of responses and the consistency for queries.

Advanced Patching Enhancements

The advanced patching feature now has improvements across a variety of areas

New puppet_run_concurrency setting allows you to get better performance out of patch group enrollment
Improved validation of scheduled and immediate jobs to reduce risk of unintended or skipped executions.
Cron scheduling has better user experience and improved validation across features.
New configurable option to enable Puppet to run after patch jobs to refresh pe_patch facts

New Endpoints for Classifier and Activity Service APIs

The Classifier API introduced new tags, add-tags and remove-tags endpoints to manage node group tags. The Activity service API now has subscriptions endpoints to create subscriptions, list subscriptions, or fetch/delete a specific subscription.

Agent Platform Updates, Resolved Issues, and Security Fixes

The macOS 26 platform is now supported for both ARM and x86_64, while support has been removed for Ubuntu 18.04 and Ubuntu 20.04.

Nearly 60 CVEs were addressed in this release, along with many resolved issues. You should definitely check out the release notes for the full list of fixes!

PE 2023.8.10 Released

Along with the new 2025.11 release, the latest patches for the LTS version PE 2023.8 has also been put out.

Agent platforms were a big change, as macOS 26 was added, along with removing support for Ubuntu 18 and Ubuntu 20.
Nearly 60 CVEs resolved in this release, many by component updates.
Some additional fixes made in 2025.11 have also been inherited for the Activity service API and LDAP group attributes handling.

Official Release Notes

Read more in the full release notes on help.puppet.com ⬇️

Download Puppet Enterprise

RHEL 10 support now available in Puppet SCE for Linux

Jason St-Cyr — Thu, 18 Jun 2026 16:16:41 +0000

Version 2.7.0 of Security Compliance Enforcement (SCE) for Linux is now available for download from the Forge!

Support for the RHEL 10 family

This release adds Red Hat Enterprise Linux (RHEL) 10 CIS benchmarks (v1.0.1, Server Levels 1 and 2). Teams adopting RHEL 10 or a compatible platform can bring those systems into compliance using the same trusted standards already in place across earlier RHEL versions.

Other improvements

Some other issues were also addressed, including logging issues with the rsyslog configuration file and intrusion detection on RHEL 9.

For all the details, make sure to read the full release notes

SCE Module on Puppet Forge

Security Compliance Management 3.8.0 Is Now Available

Jason St-Cyr — Tue, 16 Jun 2026 13:31:38 +0000

Security Compliance Management (SCM) 3.8.0 is here, with updates focused on keeping compliance scans running reliably with less manual intervention and an important license update.

This release introduces automatic cleanup for stuck scans, improved control over scan behavior with configurable timeouts, extended CIS-CAT® Pro Assessor license support, and updated benchmark content. It also includes important security fixes across core components.

⚠️ We recommend upgrading to SCM 3.8.0 before June 21, 2026 to avoid disruption, as the CIS-CAT Pro Assessor license included in SCM 3.7.1 expires on that date.

What’s changing in SCM 3.8.0

CIS-CAT Pro Assessor licensing and version

SCM 3.8.0 now contains CIS-CAT Pro Assessor v4.63.0
The bundled CIS-CAT® Pro Assessor license is now valid for one year
- The license shipped with SCM 3.8.0 is valid until June 2027
- The license included in SCM 3.7.1 expires on June 21, 2026

You can now also update the license without upgrading SCM:

New license_path parameter
- Allows updating the CIS-CAT Pro Assessor license independently
- Documentation: https://help.puppet.com/scm/current/Content/UserGuide/SCM/update_assessor_license.htm

Scan management, configuration, and reliability

Added a background scan sweeper to detect and cancel scans stuck in a "running" state
Fixed a race condition where timed-out Puppet Enterprise job status polls could leave scans permanently stuck
New assessor_scan_timeout option controls task timeout for Windows Server 2022 domain controllers (Note: this isn't set by default)
Increased default Max GraphQL requests limit to 300 requests

Benchmark coverage updates

New benchmarks added for Amazon Linux 2023 STIG, Microsoft Windows 11 STIG, Oracle Linux 9 STIG, RHEL 10 STIG, and SUSE 16
Updated benchmarks for: Amazon Linux 2, macOS, Debian, Windows, and Ubuntu (see the release notes for specific benchmark updates)
Removed benchmarks for:
- Azure Compute Windows Server 2019 v1.0.1
- Azure Compute Windows Server 2022 v1.0.0

Security fixes

This release includes updates to address 40 vulnerabilities across several components. The following components were updated to address the vulnerabilities:

Gorm.io
Keycloak
netty-codec
netty-codec-http
netty-codec-http2
netty-codec-haproxy
netty-handler
Protobuf
react-router

Refer to the full release notes for the complete list of CVEs.

Upgrade guidance

To avoid scan interruptions, upgrade to SCM 3.8.0 before June 21, 2026. This ensures continued use of the CIS-CAT Pro Assessor, access to updated benchmark content, improved security posture, and improvements in scan processing.

Learn more

Full release notes: https://help.puppet.com/scm/current/Content/UserGuide/SCM/Release_notes/release_notes.htm#SecurityComplianceManagement380

If you have questions or need assistance upgrading, reach out to Puppet Support.

🤖 AI Disclosure

This article was written and reviewed by the author, with the help of AI to assist in pulling together the details from multiple sources and general brand voice alignment.

How did I do that? For this particular article, I provided Microsoft 365 Copilot with the original release notes, my previous release announcement for 3.7.0, our company brand voice guidelines, and the official product release announcement that went out to customers. The LLM can then pull together the list of things that were updated and create a skeleton of an article. I then rewrite the content as needed to meet with my own tone of voice and get rid of the over-list-based approach that LLMs often take. It's also important to actually check back against the original release notes because sometimes the LLM will change certain words or remove words that change the meaning of what was in the release. I hope this helps if you are also writing with LLMs!

Remediating 18 OpenSSL CVEs at Scale with Puppet

Jason St-Cyr — Mon, 15 Jun 2026 14:10:21 +0000

Written by Paul Reed.

The June 2026 OpenSSL advisory is a big one. 18 vulnerabilities, one rated high severity with remote code execution potential, and a disclosure credited in part to Anthropic's Mythos model working alongside researcher Alex Gaynor. Six of those CVEs trace back to that collaboration.

When an advisory like the OpenSSL one lands, the first question is always the same: where are we exposed? If you run Puppet, you can answer that question across the entire fleet right now, patch it through one mechanism that handles every platform for you, and have it stay patched without anyone watching afterwards. The rest of this article is how.

The Vulnerability: What CVE-2026-45447 Actually Does

CVE-2026-45447 is a heap use-after-free in PKCS7_verify(). The bug fires when OpenSSL processes a PKCS#7 or S/MIME signed message where the SignedData.digestAlgorithms field is an empty ASN.1 SET.

When OpenSSL encounters this condition, OpenSSL frees a BIO object that was passed in by the calling application and is still expected to be valid. The calling application then uses the freed pointer. Depending on heap layout, that results in heap corruption, a process crash, or with a controlled heap grooming primitive, code execution.

Affected ranges:

OpenSSL 3.0.x through 3.3.x (patch to 3.5.1)
OpenSSL 1.1.1x (patch to corresponding 1.1.1 update)

The other 17 CVEs in the advisory cover authentication bypass via forged certificates (moderate, roughly a 1-in-256 success rate), ciphertext forgery, private key recovery, root CA replacement, and several DoS vectors. None are trivial in regulated environments.

Step 1: Query Your Actual Exposure

Knowing where you're exposed is where Puppet earns its keep on day zero. There's no scanner to stand up and no spreadsheet to chase round the teams. The data is already sitting in PuppetDB.

Package inventory is fed by Puppet's resource abstraction layer, the same machinery behind puppet resource package. It enumerates every package provider Puppet Enterprise supports. This means package inventory sees well beyond the system package manager: OS packages across apt, dnf/yum and zypper, and language managers like gem and pip alongside them. One query, every node:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

Run the query against a live environment to review the results. On one fleet:

system libraries across multiple providers (libopenssl3/libopenssl1_1 via zypper, openssl and openssl-libs via dnf/yum, openssl via apt)
the Ruby openssl gem at several versions
openssl via puppet_gem on every agent node, because Puppet's own Ruby ships it
pyOpenSSL and python3-openssl via pip and the OS package manager

Most tools miss the bulk of that, because they only ever look at the system package manager. Here, anything a package manager put on the box is in scope, system libraries and language bindings together.

Scope the query to an environment by filtering against the inventory endpoint:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and
  version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
  and
  certname in inventory[certname] { environment = "production" }
}'

Step 2: Patch It (recommended for the actual remediation)

You don't hand-write a package resource per platform, and you shouldn't. The package name varies (openssl-libs on RHEL, libssl3 on Debian, libopenssl3 on SUSE), the versions differ again, and the openssl CLI isn't even the vulnerable piece, the runtime library is. Let the tooling that already models your estate carry that.

Use the patching framework: pe_patch on Puppet Enterprise, os_patching for open source and Bolt. Classify the class and each node reports its pending updates, including which are security updates. You patch through the PE console or a task, scoped to security updates only if you want the change tight.

The OS package manager applies the vendor's security update, so the correct library package and version are chosen per platform without you encoding any of it. Reboots, update ordering, and patch and blackout windows are the framework's job. A box that can't be touched in business hours is a blackout window in config, not a workaround.

The exposure query doubles as your target list. The orchestrator takes PQL directly with -q, so there's no glue script to write. You hand the orchestrator the query and let it resolve the nodes:

puppet task run pe_patch::patch_server -q 'package_inventory[certname]{
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
  and version ~ "^(3\\.[0-3]\\.|1\\.[0-1]\\.)"
}'

That's pe_patch::patch_server on Puppet Enterprise, os_patching::patch_server for open source and Bolt. The orchestration runs the task against exactly the nodes the query returned and nothing else. Add security_only=true to keep the run tight, so a node that's already current is a no-op. If you'd rather not touch the command line, wire the same query into a node group in the PE console and drive it from there.

Step 3: Enforce It In Code

If you'd rather declare the state and have Puppet hold the state on every run, use the openssl module's class. The module knows the package names per platform:

class { 'openssl':
  package_ensure         => latest,
  ca_certificates_ensure => latest,
}

Using latest keeps the library current; set package_ensure to a specific version from Hiera if you want a pinned, auditable rollout.

This enforcement step is something a one-off script and a scanner both miss. A patch run fixes the issue once; declaring the state is what makes it stay fixed. The agent runs on a schedule, every 30 minutes by default, and enforces desired state each time. So when a node drifts back to a vulnerable version, a VM reprovisioned off a stale image, say, or a change someone made by hand and forgot, the next run quietly puts the desired state back. A scanner would notice that regression on its next sweep and open you a ticket. Enforcement just doesn't let the gap stay open that long.

The two paths aren't either/or. The patching framework is the quicker way to clear the initial backlog; enforcement is what keeps the backlog cleared. Run both and the framework does the first sweep while the module holds the line from then on.

Step 4: Restart Processes That Link the Library

Patching the package is only half the job. A running process keeps the old .so mapped until the process restarts, and a library swap under a live OpenSSL is exactly the case where that bites.

If you patched with the framework, it already tracks this for you. pe_patch reports the processes that require a restart in the node's fact, so you don't go hunting:

"reboots" : {
    "app_restart_required" : true,
    "apps_needing_restart" : {
        "1" : "/usr/lib/systemd/systemd --switched-root --system --deserialize 31",
        "586" : "/usr/lib/systemd/systemd-journald",
        "601" : "/usr/lib/systemd/systemd-udevd",
        "657" : "/sbin/auditd",
        "691" : "/usr/bin/python3 -s /usr/sbin/firewalld --nofork --nopid",
        "694" : "/usr/sbin/rngd -f --fill-watermark=0 -x pkcs11 -x nist -x qrypt -x namedpipe -x jitter -D daemon:daemon",
        "696" : "/usr/lib/systemd/systemd-logind",
        "766" : "/usr/sbin/NetworkManager --no-daemon",
        "863" : "sshd: /usr/sbin/sshd -D [listener] 0 of 10-60 startups"
    },
    "reboot_required" : true
},

apps_needing_restart is the list of processes still mapping a file that's been replaced underneath them, and reboot_required flags when a restart of individual services won't cut it. The patch run acts on these according to its reboot policy, so the same job that applies the update also clears the stale library, or tells you precisely which nodes still need a bounce. That's the manual lsof check in the next section, done for the whole fleet as a fact.

If you went the module route instead, chain the dependent services onto the class so they refresh when it changes the library:

Class['openssl'] ~> Service['nginx']

Chaining on the class rather than a Package['...'] title means you don't have to know the package name the module picks per platform. The refresh fires only when something actually changes, so steady-state runs leave your services alone.

A note on the language-level copies inventory turned up. Where a gem or pyOpenSSL links the system library, patching libssl/libcrypto fixes the underlying crypto and these processes will pick up the patch on restart. The few that statically bundle their own copy get updated through their own toolchain (gem update, pip). The OS-packaged bindings ride along with the patch run either way.

Step 5: Verify the Process Has Reloaded the Library

The reboots fact above is your fleet-wide answer. When you want to confirm a single box by hand, or you're working somewhere the fact isn't available, lsof against the actual PID tells you what that process has mapped:

sudo lsof -p $(pgrep nginx | head -1) | grep libssl

If the lsof query still shows the old path after the run, the restart didn't fire. Check the agent log or the patch run's reboot status. The openssl CLI version won't help here, the version says nothing about what a long-running daemon has mapped.

Step 6: Confirm Convergence

Re-run the inventory query to verify closure. This query doubles as audit evidence:

puppet query 'package_inventory[certname, package_name, version, provider] {
  package_name ~ "(?i)openssl$|libssl$|libcrypto$"
}'

Anything still on an affected version, across any provider, is your remaining work. Puppet Enterprise users can pull the same data from the compliance dashboard for audit review.

The Point Isn't OpenSSL

OpenSSL is this month's fire drill. Next month it's something else, and the one after that hasn't been disclosed yet. None of the steps above were really about OpenSSL. They were about having a tool already in place that answers the questions every advisory asks, before the advisory lands.

Look back at what each step actually was:

The exposure query was inventory: what have I got, and where, as of the last check-in.
The patch task, scoped from that same query, was remediation. The reboots fact was reporting, telling you what's still exposed and what needs a bounce.
Enforcement was the bit that holds the line afterwards, so a reprovisioned box can't slip back in unnoticed.

That's the whole vulnerability-response loop, and the worst time to start building it is the morning a CVE lands with the clock already running.

That's the case for putting the capability in now, while nothing's on fire. The next disclosure becomes a query and a patch run instead of a fortnight of spreadsheets and change tickets. The same loop applies well beyond library upgrades, too. We recently showed how to deal with dirty frag and copy-fail with Puppet, which walks the same detect-mitigate-remediate pattern on a different class of problem.

Using Puppet provides a consistent way to address OpenSSL vulnerabilities across environments. It'll still be set up and ready when the next vulnerability lands.

🤖 AI Disclosure

This article has been reviewed by a human expert in the subject matter and all code samples have been reviewed by Puppet technical experts. Initial structural content has been generated by Claude AI tools to assist with editing for clarity, structure, grammar, and maintaining brand voice, and then passed through human review.

What You Need to Know About the New puppetlabs-stdlib 10 in June 2026

Jason St-Cyr — Thu, 11 Jun 2026 14:31:40 +0000

The TL;DR

We are releasing puppetlabs-stdlib 10.0.1 with a target date of June 30, 2026.
This is a major version bump because we are dropping support for Puppet 7 (which reached its end-of-life in February 2025) and requiring Ruby 3.1+.
If your modules pin stdlib to < 10.0.0, they will continue to work as-is on stdlib 9.x.
You do not need to take any immediate action, but we wanted to give the community advance notice so module owners have time to plan.

Why a Major Release?

The puppetlabs-stdlib module is one of the most widely depended-upon open source modules in the Puppet ecosystem. Because of that, we take major version bumps seriously and want to be transparent about what is changing and why.

The last release of stdlib (9.7.0) was published in December 2024. Since then, maintenance work has accumulated in the main branch, updates to Puppet Core tooling, CentOS 9 support, Rubocop alignment, CI and testing infrastructure updates, and various bug fixes and enhancements contributed by both Puppet engineers and community members.

Among those accumulated changes is the removal of Puppet 7 from the supported platforms in the module metadata. Since Puppet 7 reached end-of-life over a year ago, this is a natural and expected housekeeping step. However, because removing a previously supported Puppet version is a backwards-incompatible change under semver, it requires a major version bump. By making a major version release along with the removal of Puppet 7 support, this will make a clean delineation for any users still running Puppet 7.

Additionally, the Rubocop and tooling updates in the branch enforce Ruby 3.1+ syntax standards (such as the shorthand hash syntax). While these are primarily code-style changes, they mean the module codebase is no longer guaranteed to run on Ruby versions older than 3.1, which further supports the decision to move to a new major version.

What’s Included in stdlib 10

This release rolls up approximately 18 months of changes. The highlights include:

Puppet 7 support removed: The module metadata now requires Puppet 8.0.0 or later. Puppet 7 has been end-of-life since early 2025.
Ruby 3.1+ required: Rubocop and code style enforcement now targets Ruby 3.1 standards. Syntax that is incompatible with older Ruby versions has been adopted throughout the codebase.
CentOS 9 support: The module metadata now states support for CentOS 9.
Bug fixes and enhancements: Multiple community-contributed fixes and improvements that have been pending release.
CI and testing updates: Updated testing infrastructure using Puppet Core tooling, updated nightly test matrices, and improved CI workflows.

A full changelog will accompany the release on the Puppet Forge and on GitHub.

What This Means for Module Authors

If you maintain a Puppet module that depends on puppetlabs-stdlib, here is what you need to know.

If You Do Nothing

Your module will continue to work. Most modules pin their stdlib dependency with an upper bound like "puppetlabs/stdlib": ">= 4.0.0 < 10.0.0". The Puppet module resolver will keep you on the latest 9.x release. Nothing breaks, nothing changes.

If your module did not specify an upper bound, your module will be able to start using version 10 without any changes.

If You Want to Adopt stdlib 10

When you are ready, update the upper bound of your stdlib dependency in your metadata.json:

"puppetlabs/stdlib": ">= 4.0.0 < 11.0.0"

This will allow your module to resolve either stdlib 9.x or 10.x, giving your users flexibility. You should also confirm that your module no longer requires Puppet 7 support and that your testing and CI pipelines use Ruby 3.1 or later.

Timing Is Up to You

There is no urgency to adopt stdlib 10 on day one. The 9.x line will remain available on the Forge. We encourage module owners to update at their own pace, and we are providing this advance notice specifically so you can plan that work into your roadmap rather than being caught off-guard.

What Perforce Puppet Is Doing to Prepare

We recognize that stdlib touches a huge portion of the module ecosystem. There are approximately 34 puppetlabs modules that depend on stdlib. Between now and the release date, we will be updating all of those modules to expand their dependency bounds to accept stdlib 10.x. These updated modules will be released to the Forge ahead of or alongside the stdlib 10 release so that the transition is as smooth as possible.

Our goal is that by the time stdlib 10 lands on the Forge, the puppetlabs module ecosystem will already be ready for it.

Timeline

Date	Milestone
Now	This announcement. Community has advance notice.
June 18–30	Perforce will release updated dependency bounds across puppetlabs modules.
June 30, 2026	Target release date for puppetlabs-stdlib 10 on the Puppet Forge.

A Note on Communication

We want to acknowledge that an earlier attempt to release stdlib 10.0.0 was made without sufficient advance communication to the community. We heard the feedback, rolled that release back, and are now doing this the right way: giving you notice, giving you time, and coordinating the broader module ecosystem before the release lands.

Major stdlib releases have historically been disruptive because of how deeply the module is embedded across the ecosystem. We are committed to making this transition as smooth as possible, and your feedback during this notice period is welcome and appreciated.

How to Prepare

Review your dependency bounds: Check your metadata.json for your stdlib version constraint.
Check your Puppet version support: If your module still claims Puppet 7 support, consider whether that is still necessary given Puppet 7 is end-of-life.
Check your Ruby version: Ensure your testing and CI environments use Ruby 3.1 or later.
Test against the main branch: If you want to verify compatibility ahead of the release, you can test your module against the main branch of puppetlabs-stdlib on GitHub.

Questions and Feedback

We want to hear from you. If you have questions, concerns, or feedback about this upcoming release, please reach out through any of the following channels:

Community Slack: The Puppet community Slack workspace, particularly the #forge-modules channel where we have already had some discussion on this upcoming change.
Comments on this post: We will be monitoring and responding to comments here on dev.to.
Perforce Forums: Join the discussion on the Perforce Puppet forums, part of the official Perforce Portal.

Thank you for being part of the Puppet community! We appreciate your collaboration and your contributions, and we are looking forward to getting this release into your hands.

stdlib Forge Module

Puppetlabs Modules Roundup – May 2026

Jason St-Cyr — Wed, 03 Jun 2026 21:48:48 +0000

This time around we look back at May 2026 and the 11 Puppetlabs module releases on the Forge, with an emphasis on the changes most likely to matter in active environments.

Highlighted Updates

New Windows audit policy module released!

The new audit_policy module has been released by Perforce as a Ruby replacement for the generated DSC community auditpolicydsc module.

This module uses Puppet Resources API for managing Windows audit policy using auditpol.exe

ruby_task_helper Dependency Bound Update

Five Bolt-adjacent modules all bumped the ruby_task_helper upper bound to < 2.0.0 in a coordinated maintenance pass, helping with dependency resolution failures when using Bolt 5.x.

Affected modules: vault, terraform, http_request, gcloud_inventory, azure_inventory.

CentOS 9 Support

Multiple modules added explicit CentOS 9 compatibility, expanding the Linux platform coverage in line with the broader Puppet ecosystem push.

Affected modules: concat, inifile.

What Updates Happened to Puppetlabs Modules in May 2026?

The following is an alphabetical listing of modules which received updates in May 2026. If a module had multiple versions released, the updates are collected together, numbered with the "latest" version available.

apt 11.3.1

📅 Latest release: 2026-05-19 (🌐 View on the Forge)

This release introduced an explicit hash value syntax while also adding a param to support purging keyrings and other community contributions.

Includes monthly releases: 11.3.1 (2026-05-19), 11.3.0 (2026-05-18).

Use explicit hash value syntax instead of shorthand #1285 (SugatD)
Add param for purging keyrings #1266 (bwitt)
Include components when suite does not end with slash #1259 (bwitt)
Bugfix - sources format and ensure => absent fails #1243 (traylenator)
fix: allow plus signs in ppa #1222 (moritz-makandra)
Fix and improve DEB822-style template #1212 (smortex)

audit_policy 1.0.0

🌟 New Module: 2026-05-29 (🌐 View on the Forge)

This new module allows you to manage Windows audit policy with auditpol.exe as a replacement for the generated DSC community module. Initial release contains:

audit_policy_subcategory: manage Windows audit policy subcategories by display name using auditpol.exe
audit_policy_guid: manage Windows audit policy subcategories by GUID using auditpol.exe
audit_policy_option: manage global Windows audit policy options (CrashOnAuditFail, FullPrivilegeAuditing, AuditBaseObjects, AuditBaseDirectories)
audit_policy_csv: manage Windows audit policy by importing settings from an auditpol /backup CSV file
Support for Windows Server 2016, 2019, 2022, and 2025
Pure Ruby implementation — no PowerShell dependency; replaces the dsc-auditpolicydsc community module
Puppet requirement pinned to >= 8.0.0 < 9.0.0

azure_inventory 0.5.1

📅 Latest release: 2026-05-14 (🌐 View on the Forge)

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#16)

cd4peadm 5.15.1

📅 Latest release: 2026-05-07 (🌐 View on the Forge)

A few highlights from this release:

Fixed an issue where SAML logins were failing.
Fixed an issue where CD would not use the configured HTTP timeouts when making calls to the Azure DevOps API, resulting in unexpected timeout failures.
Fixed an issue where GitLab merge request updates that do not involve code changes would trigger CD pipelines.
CVE-2026-42198. Updated to address this vulnerability.

Check the official release notes for cd4peadm 5.15.1 for the full details.

concat 10.0.0

📅 Latest release: 2026-05-19 (🌐 View on the Forge)

This release added support for CentOS 9 while also addressing runner images for Ubuntu 24.04.

Redact sensitive content #828 (smortex)
(CAT-2296) Update github runner image to ubuntu-24.04 #823 (shubhamshinde360)
(CAT-2152) Add support for CentOS 9 #818 (skyamgarp)
Allow user defined tag or list of tags #790 (Lightning-)
Use explicit hash value syntax instead of shorthand #835 (SugatD)

gcloud_inventory 0.3.1

📅 Latest release: 2026-05-14 (🌐 View on the Forge)

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#14)

http_request 0.3.2

📅 Latest release: 2026-05-14 (🌐 View on the Forge)

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#18)

inifile 6.4.0

📅 Latest release: 2026-05-19 (🌐 View on the Forge)

The inifile module now supports multiple values per key while also adding support for CentOS 9.

Add support for multiple values per key #555 (bwitt)
(CAT-2152) Add support for CentOS 9 #549 (skyamgarp)

puppet_agent 4.28.0

📅 Latest release: 2026-05-07 (🌐 View on the Forge)

Updates to new tooling (Bolt, PDK Templates) as well as support for MacOS 26 and some pre-work for the upcoming Puppet Core 9.

(PA-7824) Use newest Bolt #829 (mhashizume)
(PA-7897) Update to pdk-templates 3.6.1.1 #825 (joshcooper)
(PA-8250) Allow installation of puppetcore9-nightly packages #822 (joshcooper)
(PA-8238) Add support for MacOS 26 in install_shell.sh #821 (shubhamshinde360)
(PA-8250) Restore windows command to check puppet service #826 (joshcooper)
(PA-8041) Fix puppetcore8-nightly installs on rpm and mac #824 (joshcooper)
(PA-8247) Add guard against other ruby process when installing #823 (AriaXLi)

terraform 0.7.2

📅 Latest release: 2026-05-14 (🌐 View on the Forge)

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#37)

vault 0.4.1

📅 Latest release: 2026-05-14 (🌐 View on the Forge)

This release bumped the ruby_task_helper upper bound to < 2.0.0.

Bump ruby_task_helper upper bound to < 2.0.0 (#19)

Until Next Time!

That closes out the May 2026 update set. For deeper implementation detail, the linked module pages and release notes remain the best source of truth.

If you have feedback on the roundup format or want a deeper look at a specific module area, the Perforce Community Slack is still the best place to continue the conversation.

See you next month with a roundup for June releases!

Puppet Core 8.19 and PDK 3.7: Security Updates, Dependency Changes, and Windows Fixes

Jason St-Cyr — Thu, 21 May 2026 16:17:55 +0000

Puppet Core 8.19.0 focuses largely on security hardening, with some dependency cleanup and a small but important fix for Windows user management.

If you already run Puppet Core 8, this release is primarily about keeping your runtime secure and predictable, rather than introducing new workflows or configuration changes.

➡️ Full details: Puppet Core 8.19.0 release notes

PDK 3.7.0 was also released to improve performance on Windows, update dependencies, and provide other updates for security and known issues.

➡️ Full details: PDK 3.7.0 release notes

CSV gem dependency removed

Puppet Core no longer depends on the CSV Ruby gem.

Removes an external dependency from the Puppet runtime
Reduces overall dependency surface area
Simplifies installation and long-term maintenance

This change does not alter Puppet DSL behavior or require configuration changes.

Security updates

Puppet Core 8.19.0 updates several bundled runtime components to address recently disclosed security vulnerabilities. These updates apply automatically when you upgrade.

Ruby updated to 3.2.11 (CVE-2026-27820)
OpenSSL updated to 3.0.20 (CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790)
libxml2 updated to 2.15.3 (CVE-2026-6732)
curl updated to 8.20.0 (CVE-2026-6253, CVE-2026-6276, CVE-2026-6429, CVE-2026-7009, CVE-2026-7168)
net-imap updated to 0.4.24 (CVE-2026-42245, CVE-2026-42246, CVE-2026-42256, CVE-2026-42257, CVE-2026-42258)
erb updated to 6.0.4 (CVE-2026-41316)

ℹ️ Important note for net-imap users

If you use net-imap directly in custom Ruby code, the updated version enforces stricter argument validation. Check the release notes for some details on how to manage this gem if you cannot use the upgraded version of net-imap.

Windows user passwords now allow colons

When managing user resources on Windows, Puppet Core no longer rejects passwords containing colons (:).

Affects Windows platforms only
Behavior on other platforms is unchanged

This prevents unnecessary failures when managing Windows accounts with valid password formats.

Installation safeguards for Ruby versions

Puppet Core now prevents installation on unsupported Ruby versions.

Puppet Core 8 enforces a maximum supported Ruby version of 3.x
Prevents installation attempts using unsupported versions (such as Ruby 4)
Protects against installation failures like can't modify frozen Hash

This applies when installing Puppet Core via bundler or gem commands.

PDK 3.7.0 changes

This version of PDK was updated to help prevent security issues and reduce test failures, and made macOS 15 downloads available.

Rexml updated to version 3.4.4 to address CVE-2025-58767
macOS 15 downloads now available
Windows performance has been improved
YAML file validation issues should be resolved
Several puppet_forge gems and dependencies were updated

Should you upgrade?

Upgrading to Puppet Core 8.19.0 is recommended for Puppet Core 8.x users if:

You want current security fixes for bundled runtime dependencies
You manage Windows users with complex passwords
You want to avoid accidental installation on unsupported Ruby versions

Want to get started? Here are the install/upgrade guides:

For full details and CVE listings, see the release notes:

➡️ Puppet Core 8.19.0 release notes
➡️ PDK 3.7.0 release notes

Creating Successful Migration Workflows with Puppet

Tony Green — Mon, 18 May 2026 10:11:59 +0000

The goal isn't to move things. It's to only move them once.

I've been doing this for over thirty years.

Sysadmin, ops lead, global teams, and more data centre migrations than I'd like to admit. Site to site, P2V, V2V, cloud, hybrid, all of it.

Every migration gets sold as a clean, well-planned transition. None of them are.

They go wrong in very predictable ways. Not because moving infrastructure is especially difficult, but because nobody ever has a clear, current view of what's actually running, what's changed, and what still matters. So people fall back to spreadsheets, SSH sessions, scripts written at 2am, and a lot of "we think this is right".

That's where migrations fail. Not in the move itself, but in the loss of control around it.

Why migrations go wrong

After you've done a few of these, the pattern is obvious. Three things show up every time.

The first is drift. Most environments look well understood on paper. In reality, versions don't match, configurations have wandered off in their own directions, "identical" servers aren't, and there are systems no one owns but everyone is afraid to touch. I once worked on an estate where three "identical" app servers were running three different JVM versions, and nobody could tell me which one production traffic was actually landing on. You start the migration with an incomplete picture and everything after that is guesswork. It gets worse once the migration is underway, because people make manual fixes to keep things moving, and nothing lasts as long as a temporary solution.

The second is manual execution. No matter how good the plan looks in the slide deck, at some point it turns into a human running commands on a list of hosts they pasted out of a spreadsheet. Sequencing becomes tribal knowledge. Parallelisation becomes guesswork. The rollback plan, if anyone wrote one down, is usually a single line that says "restore from backup".

The third is lost accountability. During a migration more people have access, more changes are happening, and less of it gets tracked properly. So when something breaks at 3am, nobody is quite sure what changed, or who changed it, or how to undo it. By the time you've worked it out, the on-call engineer has lost an evening and the project has lost a week of trust.

None of this is new. What's interesting is that all three problems have the same root cause. There's no consistent way to know what your estate looks like and operate it predictably while it's moving.

The four things you need to stay in control

Fixing this comes down to four things. You need to know what's actually out there. You need a way to say what it should look like. You need to be able to operate it safely at scale. And you need to know who's allowed to do what. Most teams have bits of all four scattered across different tools, which is why nothing quite lines up when it matters. Puppet Enterprise gives you all four in one place. One model, one set of controls, one audit trail. Not four tools you have to glue together yourself and pray they agree with each other.

Visibility

Most migrations start with a discovery phase that's stale before the spreadsheet is finished.

What you actually want is continuous visibility, and that's what facter does. facter runs on every node, collects system information, and reports it back centrally dozens of times a day. Out of the box you get the obvious things (OS, kernel, memory, network) but the part that matters during a migration is custom facts. You can teach facter to collect anything you care about.

Here's a small one that reports the version of an in-house payments app by reading a file the deploy pipeline drops on disk:

Facter.add(:payments_version) do
  setcode do
    if File.exist?('/opt/payments/VERSION')
      File.read('/opt/payments/VERSION').strip
    end
  end
end

Once that fact exists, every node running the app reports its version on every Puppet run. Five minutes later you can ask Puppet Enterprise "show me every node where payments_version is older than 4.2" and get a real answer, not a guess. Multiply that across the dozen things you actually care about (JVM version, storage layout, mount points, whether a vendor agent is running, whether a system is genuinely in use) and you've replaced your discovery spreadsheet with something that updates itself.

That's the bit most teams never quite get to. Half the battle in a migration is just knowing what you've got.

State

Once you know what you've got, the next problem is making sure it behaves the way you expect.

This is the part Puppet has been doing for years. You define the desired state in code, and that code gets applied consistently across the old data centre, the new one, and any cloud environment you're bringing into the mix. No golden images quietly drifting. No "we rebuilt it by hand and it's nearly the same".

The reason this matters during a migration is that it lets you stand up the new environment alongside the old one and keep them honest. Same roles, same profiles, same definitions. The question stops being "did we build this correctly?" and becomes "does it match the defined state?". The second question has an answer. The first one rarely does.

Execution

At some point you actually have to do things. Stop services, drain load balancers, run pre-flight checks, kick off data sync, validate the result, move on. This is the bit that usually collapses into SSH and good intentions.

Puppet Tasks and Plans give you a way to do it properly. Tasks run actions across large numbers of nodes. Plans sequence those actions and react to what they return. You target nodes by what Puppet already knows about them, not by a hand-built host list, which means the targeting stays correct as the estate changes underneath you.

Here's roughly what a cutover step looks like as a Plan:

plan migration::drain_web (
  TargetSpec $nodes,
) {
  $targets = get_targets($nodes)
  run_command('systemctl stop nginx', $targets)
  run_task('healthcheck::wait_for_drain', $targets, timeout => 300)
  return "drained ${targets.size} nodes"
}

Nothing clever. The point is that it's the same plan whether you're draining four nodes or four hundred, it runs through the orchestrator with the same RBAC and the same logging as everything else, and you can call it from another plan that drains the web tier, then the app tier, then flips DNS. The chaos of cutover night turns into something you can rehearse.

Control

The last piece is the one most people only think about after something has already broken.

During a migration more people have access, more changes are happening, and the blast radius of a mistake is bigger. You need to know who can define behaviour, who can execute it, and who can see what's going on. Puppet Enterprise handles that through RBAC and its reporting layer. You can let a team run specific tasks against specific systems without handing them the keys to the kingdom, and you can give read-only visibility to the people who need to know what's happening without putting them in the room.

The same controls apply no matter how the work is triggered. A change ticket in ServiceNow, a step in a CI/CD pipeline, an approval workflow, or someone clicking a button in the console all run the same plans against the same nodes. Same RBAC checks, same audit trail. That matters during a migration because cutover work doesn't all come from one place. Some of it is planned change, some is automated, some is "the network team needs us to drain that rack in the next ten minutes", and you don't want each route to have its own access model and its own log.

If you're running PE Advanced, the same model extends into compliance. Continuous reporting, CIS benchmarks running on every node, and the ability to show an auditor that the new environment was in the expected state on the day you cut over. During a migration that evidence is the difference between "we think it went well" and "here's the report".

A few things that come along for the ride

If part of your migration is moving workloads into the cloud, PE Advanced ships with CloudOps and FinOps capabilities that are genuinely useful in flight, not just once you've landed.

Once your cloud accounts are connected, you get visibility of what's actually running, what it's costing, and what's been left switched on by mistake. Migrations are very good at producing all three: orphaned instances, oversized VMs that someone picked "to be safe", and test environments that nobody remembered to turn off.

The bit that makes this useful rather than just another dashboard is that it's tied to the same node inventory you're already managing with Puppet. So the cost story doesn't end up as a separate project six months after cutover, run by people who don't know which servers were meant to be there in the first place.

A couple of other things in PE Advanced are worth knowing about for the same reason. The data connector pushes Puppet's facts, reports, and events into whatever SIEM or observability platform you already run, so the migration shows up in the same dashboards your SOC and SREs are already watching, instead of being a parallel universe nobody looks at. And the ServiceNow integration syncs bi-directionally with your CMDB, which means the live view Puppet has of the estate stops drifting away from the system of record the rest of the business is using. Both of those matter more during a migration than at any other point in the life of an environment, because both are usually where the wheels come off after cutover.

You don't have to throw away what you've got

One thing worth saying clearly, because it comes up in every conversation I have about this. You don't need to rip out your existing tooling to do any of it.

Most environments I see are a mix of on-prem and cloud, multiple operating systems, and whatever automation has grown over the years. Usually that includes Ansible, a pile of homegrown scripts, and a fair bit of "don't touch that, it works". Trying to standardise all of that during a migration is a mistake. It adds risk at exactly the moment you want less of it.

A more practical approach is to orchestrate what you already have. Puppet Tasks can call existing scripts and Ansible playbooks, sequence them alongside Puppet-managed actions, and target the right systems based on facts and roles. Instead of maintaining multiple inventories and disconnected workflows, you get one control layer driving everything you already run.

Puppet isn't replacing those tools. It's coordinating them. That lets you keep what works, cut the duplication, and converge on a more consistent model over time, which is a much safer place to be in the middle of a migration than mid-rewrite.

Final thought

A data centre migration isn't really a logistics problem. It's a control problem.

If you know what's out there, what state it's in, and who's changing it, you can move systems safely, validate them properly, and recover when things don't go to plan. If you can't, it doesn't matter how good the plan looked at kickoff. You'll be discovering the gaps the hard way, one outage at a time.

The goal of a migration isn't to move things. It's to only have to move them once.