DEV Community: puppet

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

SaaS Globalization Strategy: Technical Preparation for Chinese, European, and US Markets

sweet — Wed, 24 Jun 2026 00:45:00 +0000

Expanding a SaaS product into global markets requires more than translation — it demands infrastructure changes (edge deployment for low latency), compliance adaptation (GDPR, PIPL, CCPA), payment localization (Alipay, SEPA, Stripe), and cultural UX adjustments. This guide breaks down the technical and business preparation needed for the three largest SaaS markets: the US, Europe, and China. Each section includes actionable code examples, configuration snippets, and deployment patterns you can implement immediately. See the architecture in action at tanstackship.com, a production SaaS shipping globally on Cloudflare Workers.

Why Globalization Must Be Built, Not Bolted On

The biggest mistake SaaS founders make with globalization is treating it as a phase-two feature. Retrofitting i18n, multi-currency pricing, and regional compliance onto a monolithic codebase typically costs 3-5x more than building it in from the start — and often requires a full rewrite of the database schema, routing layer, and deployment pipeline.

The three largest SaaS markets have fundamentally different requirements:

Requirement	US Market	European Market	Chinese Market
Language	English	Multi (DE, FR, ES, etc.)	Chinese (Simplified)
Data regulation	CCPA/State laws	GDPR (strictest)	PIPL + CSL
Payment methods	Credit cards, Stripe	SEPA, PayPal, credit cards	Alipay, WeChat Pay, UnionPay
Infrastructure	AWS/US-East	GDPR-compliant hosting	ICP license, China-hosted
Authentication	Google, GitHub	EU-specific (eIDAS)	WeChat, Alipay, phone SMS
Pricing display	$ (tax excl.)	€ (VAT incl.)	¥ (tax incl.)
Content delivery	Global CDN	Edge (300ms latency target)	China CDN (ICP + DDoS shield)
Social login	Google, Apple, GitHub	Google, Apple, LinkedIn	WeChat, Alipay, phone OTP
Email deliverability	SendGrid, AWS SES	SendGrid (DPA signed)	QQ Mail, Alibaba Direct Mail

Market 1: European Market Preparation

GDPR Compliance Checklist

GDPR applies to any SaaS processing data of EU residents — regardless of where your company is incorporated. Here is the technical implementation:

// src/lib/gdpr.ts
// GDPR-compliant data handling utilities

// 1. Explicit consent tracking
interface ConsentRecord {
  userId: string
  consentType: "analytics" | "marketing" | "functional" | "third_party"
  granted: boolean
  timestamp: number
  ipAddress: string // Anonymized
}

export async function recordConsent(
  userId: string,
  consentType: ConsentRecord["consentType"],
  granted: boolean
) {
  await env.DB.prepare(
    `INSERT INTO consent_records (user_id, consent_type, granted, timestamp, ip_address)
     VALUES (?, ?, ?, unixepoch(), ?)`
  ).bind(
    userId,
    consentType,
    granted ? 1 : 0,
    anonymizeIp(getClientIp())
  ).run()
}

// 2. Data portability export
export const exportUserData = createServerFn({ method: "GET" }).handler(
  async (_, { request }) => {
    const userId = await getUserId(request)

    const [profile, subscriptions, invoices, events] = await Promise.all([
      env.DB.prepare("SELECT * FROM users WHERE id = ?").bind(userId).first(),
      env.DB.prepare("SELECT * FROM subscriptions WHERE user_id = ?").bind(userId).all(),
      env.DB.prepare("SELECT * FROM invoices WHERE user_id = ?").bind(userId).all(),
      env.DB.prepare("SELECT * FROM analytics_events WHERE user_id = ?").bind(userId).all(),
    ])

    return Response.json({
      exportedAt: new Date().toISOString(),
      data: { profile, subscriptions, invoices, events },
    })
  }
)

// 3. Right to erasure (GDPR Article 17)
export const deleteUserData = createServerFn({ method: "POST" }).handler(
  async (_, { request }) => {
    const userId = await getUserId(request)

    // Anonymize personal data (keep transactional records for legal retention)
    await env.DB.batch([
      env.DB.prepare(`UPDATE users SET
        email = 'deleted-' || id || '@redacted.com',
        name = 'Deleted User',
        avatar_url = NULL,
        deleted_at = unixepoch()
        WHERE id = ?`).bind(userId),
      env.DB.prepare("DELETE FROM analytics_events WHERE user_id = ?").bind(userId),
      env.DB.prepare("DELETE FROM session_tokens WHERE user_id = ?").bind(userId),
    ])

    return { success: true }
  }
)

EU Data Residency

GDPR requires that EU user data stays within the EU or in countries with adequate protection. With Cloudflare Workers, use data localization:

# wrangler.jsonc
{
  "name": "tanstack-ship",
  "compatibility_date": "2026-06-01",
  "workers_dev": false,
  "routes": [
    { "pattern": "tanstackship.com", "zone_id": "YOUR_ZONE_ID" },
    { "pattern": "eu.tanstackship.com", "zone_id": "YOUR_ZONE_ID", "custom_domain": true }
  ],
  "d1_databases": [
    { "binding": "DB", "database_id": "GLOBAL_DB", "database_name": "tanstack-ship" },
    { "binding": "EU_DB", "database_id": "EU_DB", "database_name": "tanstack-ship-eu" }
  ]
}

// Route EU users to EU D1 instance
async function getDb(request: Request) {
  const country = request.cf?.country
  if (country && EU_COUNTRIES.has(country)) {
    return env.EU_DB // GDPR-compliant D1 instance
  }
  return env.DB
}

EU Payment: SEPA Direct Debit

// With Stripe, SEPA is handled via Payment Methods
const paymentIntent = await stripe.paymentIntents.create({
  amount: 2999, // €29.99
  currency: "eur",
  payment_method_types: ["sepa_debit", "card"],
  customer: customerId,
})

Key EU-specific pricing considerations:

Display prices including VAT (unlike the US)
Register for VAT MOSS to handle cross-border EU sales
Issue VAT-compliant invoices (required by law for B2B)
SEPA transfers can take 1-3 business days — do not grant access until payment clears

Market 2: Chinese Market Preparation

Entering China is the most technically demanding market expansion. Here is what you need:

ICP License (Required for Any Hosted Service)

Any website or app hosted on servers in mainland China or using a Chinese CDN must have an ICP (Internet Content Provider) license. The process takes 4-8 weeks and requires:

Registered Chinese company (WFOE or joint venture) or partnership with a Chinese ICP-licensed entity
ICP filing submission through your cloud provider (Alibaba Cloud, Tencent Cloud, AWS China)
Domain name already ICP-filed

Without an ICP license, your site will be blocked by the Great Firewall of China (GFW).

Infrastructure: Bypassing the Great Firewall

// src/lib/geo-routing.ts
// Route Chinese users to China-hosted instances

const CHINA_REGIONS = new Set(["CN", "HK", "MO"])

export async function getRegionalEndpoint(request: Request): Promise<string> {
  const country = request.cf?.country

  if (CHINA_REGIONS.has(country ?? "")) {
    // Route to China-hosted instance via Cloudflare China Network
    return "https://tanstack-ship.cn"
  }

  // Global instance
  return "https://tanstackship.com"
}

Cloudflare China Network provides a GFW-compliant CDN layer without requiring your own Chinese servers. All major Chinese cloud providers also offer GPU/CPU instances:

Alibaba Cloud (aliyun.com) — largest market share
Tencent Cloud — second largest, WeChat integration
AWS China (Beijing/Ningxia) — requires separate account

Chinese Payment Integration

// src/lib/payment/china.ts
// Alipay integration via Stripe or direct API

// Option 1: Stripe (simplest, higher fees)
const paymentIntent = await stripe.paymentIntents.create({
  amount: 19900, // ¥199.00
  currency: "cny",
  payment_method_types: ["alipay", "card"],
  payment_method_options: {
    alipay: {},
  },
})

// Option 2: Direct Alipay API (lower fees, more setup)
import AlipaySdk from "alipay-sdk"

const alipaySdk = new AlipaySdk({
  appId: process.env.ALIPAY_APP_ID,
  privateKey: process.env.ALIPAY_PRIVATE_KEY,
})

const result = await alipaySdk.exec("alipay.trade.create", {
  bizContent: {
    out_trade_no: orderId,
    total_amount: "199.00",
    subject: "TanStack Ship - Pro Plan",
    product_code: "FAST_INSTANT_TRADE_PAY",
  },
})

Chinese Social Login

// src/lib/auth/china.ts
// WeChat OAuth

// Step 1: Redirect user to WeChat authorization
export function getWeChatAuthUrl(redirectUri: string): string {
  const params = new URLSearchParams({
    appid: process.env.WECHAT_APP_ID,
    redirect_uri: redirectUri,
    response_type: "code",
    scope: "snsapi_login",
    state: crypto.randomUUID(),
  })
  return `https://open.weixin.qq.com/connect/qrconnect?${params}`
}

// Step 2: Exchange code for access token
export async function getWeChatToken(code: string) {
  const response = await fetch(
    `https://api.weixin.qq.com/sns/oauth2/access_token?` +
    new URLSearchParams({
      appid: process.env.WECHAT_APP_ID,
      secret: process.env.WECHAT_APP_SECRET,
      code,
      grant_type: "authorization_code",
    })
  )
  return response.json() as Promise<{
    access_token: string
    openid: string
    unionid: string
  }>
}

Chinese Content Delivery Considerations

Censored keywords: Your content will be scanned. Common SaaS-blocked terms include sensitive political topics, VPN references, and cryptocurrency mentions
WeChat ecosystem: WeChat Mini Programs, WeChat Pay, and WeChat Official Accounts are essential for B2C SaaS
Email deliverability: QQ Mail and 163.com are the dominant email providers — ensure your SPF, DKIM, and DMARC are configured for Chinese domains
Domain blocking: Some domains are blocked without clear reason. Register a .cn domain as backup

Market 3: US Market Preparation

The US market is the most straightforward but still requires specific attention:

Tax Compliance: Sales Tax by State

// src/lib/tax/us-sales-tax.ts
// Simplified sales tax calculation (use a service like TaxJar for production)

const STATE_TAX_RATES: Record<string, number> = {
  "CA": 0.0725,  // California base rate
  "NY": 0.04,    // New York state (county/city adds more)
  "TX": 0.0625,  // Texas
  "WA": 0.065,   // Washington
  // ... 45+ more states
}

export function calculateSalesTax(
  amount: number,
  state: string
): { taxRate: number; taxAmount: number; total: number } {
  const taxRate = STATE_TAX_RATES[state.toUpperCase()] ?? 0
  const taxAmount = Math.round(amount * taxRate * 100) / 100
  return { taxRate, taxAmount, total: amount + taxAmount }
}

Key considerations:

Economic nexus: If you sell >$100K or 200+ transactions in a state, you must collect sales tax
Use a service like TaxJar, Stripe Tax, or Anrok for automated calculation
Display prices excluding tax (unlike Europe)

US Privacy Compliance (CCPA)

// src/lib/ccpa.ts
// CCPA opt-out mechanism
export async function handleCcpOptOut(userId: string) {
  await env.DB.prepare(
    `INSERT INTO privacy_opt_outs (user_id, regulation, opted_out_at)
     VALUES (?, 'CCPA', unixepoch())`
  ).bind(userId).run()
}

// Do not sell my personal information endpoint
export const optOutOfSale = createServerFn({ method: "POST" }).handler(
  async (_, { request }) => {
    const userId = await getUserId(request)
    await handleCcpOptOut(userId)
    return { success: true }
  }
)

Architectural Pattern: Regional Deployment with Edge Workers

For SaaS products targeting all three markets simultaneously, use a regional deployment architecture:

┌─────────────────────────────────────────────────┐
│                  Cloudflare                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────┐ │
│  │  US Worker   │  │  EU Worker   │  │ CN Edge  │ │
│  │  us-east     │  │  eu-west     │  │ (CF CN)  │ │
│  └──────┬───────┘  └──────┬───────┘  └────┬─────┘ │
│         │                 │               │        │
│  ┌──────▼───────┐  ┌──────▼───────┐  ┌────▼─────┐ │
│  │  US D1 DB    │  │  EU D1 DB    │  │ CN D1 DB │ │
│  │  (Virginia)  │  │ (Frankfurt)  │  │ (Beijing) │ │
│  └──────────────┘  └──────────────┘  └──────────┘ │
│         │                 │               │        │
│  ┌──────▼───────┐  ┌──────▼───────┐              │
│  │  US R2       │  │  EU R2       │              │
│  └──────────────┘  └──────────────┘              │
└─────────────────────────────────────────────────┘

// src/middleware/geo-router.ts
// Edge middleware that routes to the correct regional deployment

export const geoRouter = createServerFn({ method: "GET" }).handler(
  async (_, { request }) => {
    const country = request.cf?.country ?? "US"

    if (["CN", "HK", "MO"].includes(country)) {
      return env.CN_DB
    }

    if (EU_COUNTRIES.has(country)) {
      return env.EU_DB
    }

    return env.US_DB
  }
)

Multi-Currency Pricing Database Schema

CREATE TABLE price_tiers (
  id TEXT PRIMARY KEY,
  product_id TEXT NOT NULL REFERENCES products(id),
  region TEXT NOT NULL CHECK (region IN ('US', 'EU', 'CN', 'ROW', 'GLOBAL')),
  currency TEXT NOT NULL,
  unit_amount INTEGER NOT NULL,  -- In smallest currency unit (cents, fen, etc.)
  interval TEXT NOT NULL CHECK (interval IN ('month', 'year')),
  tax_behavior TEXT NOT NULL DEFAULT 'exclusive' CHECK (tax_behavior IN ('inclusive', 'exclusive')),
  is_active INTEGER NOT NULL DEFAULT 1,
  created_at INTEGER NOT NULL DEFAULT (unixepoch()),
  updated_at INTEGER NOT NULL DEFAULT (unixepoch()),
  UNIQUE(product_id, region, interval)
);

CREATE INDEX idx_price_tiers_region ON price_tiers(region);

// src/lib/pricing/regional.ts
export async function getRegionalPrice(
  productId: string,
  region: "US" | "EU" | "CN" | "ROW",
  interval: "month" | "year"
) {
  const price = await env.DB.prepare(
    `SELECT unit_amount, currency, tax_behavior
     FROM price_tiers
     WHERE product_id = ? AND region = ? AND interval = ? AND is_active = 1
     ORDER BY created_at DESC
     LIMIT 1`
  )
    .bind(productId, region, interval)
    .first()
  return price
}

Globalization Readiness Checklist

Before launching in a new market, verify each item:

[ ] Content is fully translated (not just UI, but transactional emails, docs, error pages)
[ ] Date/time/number formatting uses Intl.* APIs (never hardcoded)
[ ] Currency symbols and formats match local expectations (€29,99 vs ¥199 vs $29.99)
[ ] Regional payment methods are integrated and tested with sandbox credentials
[ ] Tax calculation is automated per region (VAT, sales tax, consumption tax)
[ ] Data residency requirements are met (GDPR EU, PIPL China, CCPA California)
[ ] Privacy policy covers all applicable regulations (separate versions per region)
[ ] CDN/edge routing directs users to the nearest regional deployment
[ ] Email deliverability is configured for regional providers (QQ, 163, GMX, Gmail)
[ ] Social login options include region-specific providers (WeChat, LINE, LinkedIn)
[ ] Terms of Service are localized and legally reviewed per jurisdiction
[ ] Customer support channels cover regional time zones (email, chat, phone)
[ ] Pricing is localized to market expectations (not just currency conversion)
[ ] ICP license is obtained for China (allow 4-8 weeks processing time)
[ ] Cookie consent mechanism is GDPR-compliant (granular, documented)

Conclusion

Globalizing a SaaS product is a multi-dimensional challenge that touches every part of your stack — from database sharding and edge deployment to payment processing and legal compliance. The key takeaways:

Build globalization into your architecture from day one — retrofitting regional routing, multi-currency pricing, and data residency onto a monolithic system is prohibitively expensive
Each market has a dominant constraint: GDPR (data privacy) in Europe, ICP/GFW (infrastructure) in China, and sales tax nexus (tax complexity) in the US
Payments are the hardest part — you need at least 3 payment providers (Stripe, Alipay/WeChat, SEPA) to cover all three markets
Edge deployment is your friend — Cloudflare Workers' regional routing makes data residency compliance much simpler than traditional VPS-based architectures
Test with real users in each market — localization bugs (wrong date formats, truncated text in Chinese characters, missing RTL support) only surface with native users

The companies that win at globalization are not the ones with the most features — they are the ones that make every user feel like the product was built for their market.

Related Resources

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!

Selenium vs Puppeteer vs Playwright: Complete Guide for Web Scraping, Testing & AI Automation

IPFoxy — Tue, 16 Jun 2026 12:23:25 +0000

In 2026, browser automation has evolved far beyond traditional QA testing and web scraping. With the rise of LLM-powered AI Agents, automation frameworks have become the foundation for autonomous web browsing, task execution, and large-scale AI workflows.

This guide compares Selenium, Puppeteer, and Playwright across architecture, performance, scalability, AI automation compatibility, and proxy integration.

I. Introduction to the Three Automation Frameworks

**
1. Selenium: The Most Established Browser Automation Framework

Selenium was introduced in 2004 and remains the industry standard for browser automation. With Selenium 5.0, the framework has undergone a major architectural upgrade.

Key Features:
• Supports Chrome, Firefox, Edge, Safari, and other major browsers.
• Supports Java, Python, C#, JavaScript, and more.
• Large ecosystem and strong enterprise adoption.

Best For:
Automated testing, enterprise workflows, and projects requiring broad browser compatibility.

2. Playwright

Playwright was open-sourced by Microsoft in 2020 and has become the fastest-growing browser automation framework.

Key Features:
• Native support for Chromium, Firefox, and WebKit.
• Built-in Auto-Wait mechanism.
• Browser Context support for large-scale concurrency.

Best For:
Web scraping, AI Agent automation, eCommerce data collection, social media automation, and large-scale browser operations.

3. Puppeteer: Google's Native Chrome Automation Tool

Released by the Chrome team in 2017, Puppeteer popularized the Chrome DevTools Protocol (CDP).

Key Features:
• Simple and intuitive API.
• Fast execution speed.
• Popular in web scraping and browser automation.

Best For:
Chrome/Chromium automation, web scraping, screenshots, and PDF generation.

II. Real-World Performance Comparison

1. Startup Speed
In raw tests launching a headless browser, Puppeteer and Playwright achieve cold startup speeds of 100-300 milliseconds because they connect directly to the underlying binary protocols via WebSockets. Selenium, however, typically takes 1-2 seconds due to the need to initialize the corresponding Driver process and handle layered HTTP handshakes.

2. Concurrency

Selenium launches a new browser process for each isolated environment, resulting in significant memory usage.

Playwright uses BrowserContext, allowing dozens of fully isolated environments to run within a single browser process while reducing resource consumption by over 70%.

3. Stability

Modern React and Vue applications render content asynchronously. Selenium often requires manual waits, while Playwright automatically performs Actionability Checks before interacting with elements, improving reliability significantly.
**

Compatibility** If your enterprise requires testing specific rendering issues on Safari within a physical Mac environment, or if your development team relies strictly on Java/C#, Selenium’s multi-language support and deep-rooted history make it irreplaceable.

5. AI Agent Compatibility

In 2026, AI Agent + Browser Automation has become one of the hottest directions. Projects like Claude Code, OpenAI Agent, and OpenManus all prioritize Playwright by default for three key reasons:

Native MCP Protocol Support: Playwright can output the page’s Accessibility Tree directly to the LLM, eliminating the need to parse raw DOM text.
Highly Efficient Token Usage: Compared to traditional DOM serialization, Playwright's optimized approach reduces token consumption for long sessions by 3 to 4 times.
Execution Stability: Playwright’s auto-wait and auto-retry mechanisms drastically lower the failure rates of complex agent actions.

III. Proxy Integration and Anti-Detection Capabilities

For modern web scraping, accessing a page is only the beginning. Websites commonly evaluate:

• IP Reputation
• Request Frequency
• Browser Fingerprints
• Geographic Consistency

Residential Proxies provide a more authentic browsing environment than datacenter IPs and help reduce blocking risks.
IPFoxy offers residential proxies covering 200+ countries, static ISP proxies, mobile 4G/5G proxies, and supports both HTTP(S) and SOCKS5 protocols. It integrates seamlessly with Selenium, Puppeteer, and Playwright to significantly lower blocking risks for long-running scraper projects.

Here is how to configure an IPFoxy proxy across the three frameworks:
Selenium Proxy Configuration (Python)

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
# Configure IPFoxy proxy address (with user/pass authentication)
# Static ISP or rotating residential proxies are recommended for the lowest fraud scores
proxy_server = "http://username:password@proxy.ipfoxy.com:port"
chrome_options.add_argument(f'--proxy-server={proxy_server}')

# Launch driver
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://ipinfo.io")  # Verify the IP has switched to a clean residential IP from IPFoxy
print(driver.title)
driver.quit()

Puppeteer Proxy Configuration (JavaScript)

const puppeteer = require('puppeteer');
const proxy = 'http://user:pass@ipfoxy-proxy:port';

const browser = await puppeteer.launch({
  args: [`--proxy-server=${proxy}`]
});
const page = await browser.newPage();
await page.goto('https://example.com');

Playwright Proxy Configuration (Python)

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": "http://ipfoxy-proxy:port",
            "username": "user",
            "password": "pass"
        }
    )
    page = browser.new_page()
page.goto("https://example.com")

IV. Which Framework Should You Choose in 2026?

Your technical choice should align directly with your business pain points and engineering stack:
Choose Playwright if:
• You are building a new web scraping, data collection, or AI Agent project.
• You need high concurrency and efficient resource usage.
• You work primarily with Python or TypeScript.

Choose Puppeteer if:
• You are a Node.js-focused developer.
• Your project only targets Chrome/Chromium.
• You require direct access to advanced CDP capabilities.

Choose Selenium if:
• Your organization relies heavily on Java or C#.
• You already have large-scale Selenium Grid infrastructure.
• Cross-browser testing is a top priority.

V. Conclusion

Selenium, Puppeteer, and Playwright are all excellent browser automation frameworks, but they serve different needs.

For web scraping, AI Agents, multi-account automation, and large-scale data collection, Playwright is often the most future-proof choice. Combined with high-quality residential proxies, it can significantly improve scraping success rates and long-term stability.

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.