Pulumi’s recent signal is not just that it ships often. The sharper story is what it is shipping toward: infrastructure as code for humans, platform teams, and AI agents at the same time. ToolVitals counts 18 release events in 30 days and 19 GitHub releases in 90 days, with a 100 shipping score and a 100 health score. The first-party material around those releases points in one direction: Pulumi wants to make cloud infrastructure programmable, governed, and agent-readable, not merely easier to template.

What Pulumi says it is

Pulumi’s official site describes the product as an open-source infrastructure as code platform that helps humans and agents build and manage cloud infrastructure with real programming languages. That phrase matters. Pulumi is still making the old argument against YAML-heavy IaC, but the homepage now frames that argument around AI-assisted infrastructure work too.

The GitHub repository is more concrete. It says Pulumi Infrastructure as Code lets teams build and deploy infrastructure on AWS, Azure, Google Cloud, Kubernetes, and more than 300 providers, using languages developers already know. The repo also states that it contains the Pulumi CLI, language SDKs, and core engine, while individual provider libraries live in their own repositories.

That split helps explain why the repository is a useful health signal but not the whole product. The pulumi/pulumi repo is the engine room. Pulumi Cloud, Pulumi ESC, Neo, policy packs, providers, and docs live partly outside that single repository. A buyer should read ToolVitals’ GitHub metrics as a signal for the core project, not a full audit of every Pulumi commercial feature.

The license signal is clean. ToolVitals classifies Pulumi as OSI-approved OSS under Apache-2.0. So it is fair to call the core tool open source. That does not mean every Pulumi Cloud capability is free or self-hosted, and the recent announcements make that boundary visible. ESC secret rotation webhooks, Neo code reviews, and the ISO 27001 policy pack are Pulumi Cloud shaped features, even when they sit on top of the open-source IaC base.

The recent product story is governance plus agents

The most useful way to read Pulumi’s June announcements is not as a random blog feed. They form a stack.

On June 22, Pulumi introduced Neo code reviews in public preview. The announcement says Neo reviews pull request changes using what Pulumi Cloud knows about running infrastructure, including preview output, current state, stack relationships, and dependencies. That is a specific claim. Pulumi is not positioning Neo as a generic code review bot. It is positioning Neo as a reviewer with infrastructure context.

On June 26, Pulumi announced ESC secret rotation webhooks. The local excerpt says ESC can rotate secrets on a schedule, and webhooks now notify systems when environment rotation succeeds or fails. The same post shows three control surfaces: the Pulumi Cloud Console, the Pulumi Service Provider, and the Pulumi CLI. That is a good sign for platform teams because the feature is not trapped behind click-only setup.

On June 30, Pulumi shipped a pre-built ISO/IEC 27001:2022 policy pack for AWS. The post says the pack contains 238 ready-to-run policies and can be used in audit mode against existing AWS estates, including resources Pulumi does not manage, or in preventive mode during pulumi up. That is the strongest governance signal in the payload because it turns compliance from a custom policy authoring project into a maintained pack.

The AI infrastructure post from the same day adds a second thread. Pulumi shows a zero-touch Ollama GPU inference server across AWS, Azure, and Google Cloud, using Pulumi ESC for OIDC credentials and avoiding static keys. The post argues that a GPU model server is still a VM, disk, firewall, and boot script. That is classic Pulumi territory, but the AI framing explains why the homepage now says “humans and agents.” Pulumi wants infrastructure definitions to become the substrate that both developers and agents can reason over.

What ToolVitals measured

ToolVitals gives Pulumi a hot score of 226.7, a health score of 100, a shipping score of 100, and a ToolVitals score of 100. The GitHub repository has 25,378 stars in the payload. ToolVitals also records 18 release events in 30 days and 19 GitHub releases in 90 days, with data confidence at 100.

Those numbers support a simple conclusion: Pulumi is active and highly maintained. The 18 release events in 30 days are not just patch noise, because the events include product updates, GitHub releases, governance content, ESC improvements, AI infrastructure examples, Databricks guidance, and Cloudflare networking material. The release stream spans the core CLI and engine, cloud service features, and practical platform patterns.

The GitHub release for v3.248.0 is a good example of why release count alone can mislead. The notes list a CLI panic fix, new flags for command output, stack command parity, engine support for PCL snippets kept in state, provider handshake changes for schema loader and package resolver services, program generation fixes, and Node.js Output.recover. That is not a flashy release. It is plumbing.

Plumbing is exactly what you want from an IaC engine.

The 100 shipping score means Pulumi is moving. It does not prove every release is safe, nor does it prove customers are happy. It says the public release machinery is alive. For infrastructure tools, that matters because cloud APIs change constantly, provider schemas evolve, and small CLI papercuts compound across every deployment pipeline.

Where the repo signal is strongest

The pulumi/pulumi repository tells a cleaner story than many DevOps projects because the README aligns with the product claims. It describes real-language IaC, Automation API, multiple clouds, many providers, language SDKs, and the Apache 2.0 license. The official site uses the same positioning, then adds the broader platform pitch around Neo and ESC.

That alignment reduces one common buyer risk: the marketing site is not describing a different product than the repository. Pulumi the company is selling a platform, but the public repo still anchors the core claim. You can inspect the CLI and engine, use the SDKs, and build programs without treating the hosted service as the only artifact.

Still, the repository does not answer every practical question. It will not tell you whether Neo catches the kind of unsafe networking changes your team actually makes. It will not tell you whether the ISO 27001 pack maps cleanly to your auditor’s expectations. It will not tell you whether ESC fits your existing vault model. Those require hands-on evaluation.

For maintainers, the signal is also clear. The engine work in v3.248.0 and the product launches around Neo, ESC, and policy packs need tight documentation bridges. If users can see how PCL snippets, provider schema loading, preview output, and Neo reviews connect, Pulumi’s agent story becomes credible. If those pieces feel disconnected, the phrase “AI platform engineer” will sound bigger than the workflow.

Direction: from declaring resources to operating controls

Pulumi has always sold code over static configuration. The recent material shifts the center of gravity from declaring resources to operating controls around those resources.

The Cloudflare-first networking post is a good example. It frames edge configuration drift as the problem, then defines DNS, WAF rules, Workers, and Zero Trust Access policies in Pulumi. The Databricks post does the same for cluster policies, notebooks, jobs, secret scopes, and permissions. These are not just examples of provisioning. They are examples of turning operational baselines into code.

The ISO 27001 policy pack goes further because it wraps governance into reusable rules. The ESC webhook announcement closes an operational loop by notifying downstream systems when secrets rotate. Neo code reviews move another loop into pull requests, where reviewers need context before infrastructure changes land.

Put together, Pulumi is trying to own the path from design to deployment to governance. The technical bet is that infrastructure written in real languages gives both humans and agents more context than raw templates. The business bet is that teams will pay for the control plane around that context.

What the data does not tell you

ToolVitals sees public signals: releases, stars, site availability, SSL, event feeds, and related activity. It does not see code quality in the deep sense. It does not run Pulumi against your cloud accounts. It does not measure failed deployments, provider lag, support quality, customer retention, revenue, or whether Neo’s comments are useful instead of noisy.

It also does not prove Pulumi is the right abstraction for every team. Some teams want declarative plans that are easy for non-developers to review. Some want the Terraform provider model and state conventions because their organization already standardized on them. Some prefer narrower tools for Kubernetes, secrets, policy, or CI. ToolVitals can say Pulumi is active and well maintained. It cannot say your engineers will like the programming model.

A skeptical engineering lead should treat the 100 scores as permission to evaluate, not permission to skip evaluation. The right trial is concrete: pick one existing module, one secrets workflow, and one policy requirement. Rebuild them in Pulumi, run previews in CI, test rollback behavior, and see whether reviewers understand the diffs. If Neo is part of the pitch, test it on realistic pull requests with messy dependencies, not a demo stack.

Pulumi’s 18 release events in 30 days are strong for a DevOps infrastructure tool, but they are not the loudest number in the related set. PostHog shows 236 release events in 30 days with a 100 shipping score, but ToolVitals classifies PostHog as open core, not OSI-approved OSS across every feature boundary. That comparison is useful because raw release volume is not the same as openness or fit. PostHog is shipping at a different tempo in a different category.

Jenkins is the more relevant DevOps comparison. ToolVitals shows Jenkins at 25,524 GitHub stars, close to Pulumi’s 25,378, with a 100 shipping score but only 9 release events in 30 days. Jenkins is older CI infrastructure with a huge installed base. Pulumi has similar star gravity in this snapshot, but a more active recent event stream and a product direction tied to IaC, cloud governance, and AI-assisted platform work.

werf is another DevOps neighbor. ToolVitals shows werf at 4,701 stars, a 92 shipping score, and 34 release events in 30 days. That is more 30-day release activity than Pulumi, but much smaller star reach and a narrower deployment focus. The comparison makes Pulumi’s position clearer: not the noisiest releaser, not the largest GitHub celebrity, but a broad infrastructure platform with strong maintenance signals.

Recommendation

If your team manages cloud infrastructure across multiple providers, has real compliance pressure, or is already experimenting with AI-assisted platform work, evaluate Pulumi seriously. The evidence supports that recommendation: Apache-2.0 open-source core, 25,378 GitHub stars, 19 GitHub releases in 90 days, 18 release events in 30 days, active CLI and engine work, and recent first-party investment in Neo, ESC, policy packs, Databricks, Cloudflare, and AI inference patterns.

Do not adopt it because the homepage says agents. Adopt it if the programming-language model makes your infrastructure easier to test, review, and govern.

The best Pulumi pilot is not a toy VPC. Pick a piece of infrastructure that currently hurts: a secrets rotation path, a compliance control, an edge networking baseline, or a multi-cloud service with drift. Pulumi’s recent releases are aimed exactly at those pain points. If the pilot makes the review loop clearer and the operational controls easier to encode, Pulumi is not just healthy. It is pointed at a problem your platform team actually has.

Sources