Pulumi’s headline metric is not that it is alive. That would be boring for a 25,164-star infrastructure-as-code project. The sharper signal is that Pulumi logged 16 release events in 30 days while its recent release notes and blog posts keep circling the same bet: infrastructure controlled by APIs, agents, and governed automation.
Pulumi still describes itself as infrastructure as code for humans and agents, with cloud infrastructure managed through programming languages rather than a single declarative DSL. The GitHub repository backs the maintenance story: ToolVitals records 19 GitHub releases in 90 days, a 100 health score, a 100 shipping score, and a 94 ToolVitals score.
The interesting part is the product direction hiding inside the release notes.
The agent work is no longer a side quest
The v3.237.0 release added User-Agent metadata that includes the running command name and detected AI agent, when present, on Pulumi Cloud API requests. That is a small line item, but it says something. Pulumi wants Cloud-side systems to understand when an agent is driving the CLI.
The same release includes multiple pulumi neo fixes: TUI rendering, cancellation behavior, clarifying-question display, and cleaner tool results for preview and update operations. That is not launch-post fluff. It is product hardening around an agent workflow.
v3.235.0 points in the same direction. It added pulumi logs decrypt, bundled HCL language-host support, improved HCL conversion, added PCL read blocks, and expanded pulumi cloud api into a more capable CLI surface. The release also fixed Neo shell timeouts and TUI failure modes.
v3.234.0 was even more explicit on the Cloud API side, adding pulumi cloud api list and pulumi cloud api describe for browsing and inspecting Pulumi Cloud OpenAPI operations from the CLI.
That cluster matters. Agents need inspectable APIs, stable command surfaces, predictable tool outputs, and failure modes that do not wedge the session. Pulumi appears to be tightening those bolts.
The blog stream matches the code stream
Pulumi’s recent first-party posts are not generic AI positioning. They are about operational control planes.
The Neo Integration Catalog post says Neo launched with six MCP-backed integrations: Atlassian, Datadog, Honeycomb, Linear, PagerDuty, and Supabase. The framing is direct: infrastructure teams do not work inside Pulumi alone, so Neo needs access to incident systems, observability tools, issue trackers, and databases.
The Custom VCS post is less flashy, but it fits the same pattern. It connects Git or Mercurial servers to Pulumi Deployments through webhooks and centrally managed credentials, including support for self-hosted or third-party VCS setups. That is deployment automation plumbing, not a mascot feature.
The dark factory post is the most revealing. Pulumi argues that autonomous infrastructure work needs a wall between generators and validators, deterministic policy checks, governed runners, credential controls, audit trails, and preview artifacts. The post does not prove Pulumi can make lights-out infrastructure safe. It does show the problem Pulumi wants to own.
What ToolVitals can and cannot infer
ToolVitals can say Pulumi is shipping. It can say the project has 25,164 GitHub stars, 19 GitHub releases in 90 days, 16 release events in 30 days, and top scores for health and shipping. It can say the recent public material emphasizes Neo, Pulumi Cloud APIs, deployments, MCP integrations, and agent-oriented infrastructure workflows.
ToolVitals cannot say Pulumi’s agent experience is good. It cannot measure customer adoption, enterprise retention, revenue, deployment success rates, or whether Neo handles real production incidents well. It also cannot inspect private Pulumi Cloud usage.
So the conservative read is this: Pulumi is not merely maintaining an IaC engine. It is actively wiring that engine into an agent-aware platform story.
Comparisons worth making
Jenkins is the closest DevOps comparison in the supplied data. It has 25,258 GitHub stars, almost identical to Pulumi’s 25,164, and it also has a 100 shipping score. But Jenkins shows 11 release events in 30 days, while Pulumi shows 16.
ProxmoxVE Scripts is another DevOps peer with a 100 shipping score and 18 release events in 30 days. That is slightly higher than Pulumi’s 16, but Pulumi’s 94 ToolVitals score and 100 health score put it in the same high-maintenance band.
The broader related tools are noisier comparisons. n8n has 187,370 stars and 48 release events in 30 days. LangChain has 136,337 stars and 32 release events. Those are different categories, but they show what extreme public shipping velocity looks like in automation and developer tooling. Pulumi is not in that hype band. It is a mature DevOps tool shipping steadily while changing its center of gravity.
Recommendation
If your team already uses Pulumi, evaluate the new Cloud API and Neo-adjacent work before you build custom orchestration around it. The release notes suggest Pulumi is exposing more of the platform through inspectable CLI and API surfaces, which is exactly where internal platform teams usually end up writing glue.
If your team is comparing IaC platforms for agent-driven operations, put Pulumi on the shortlist because its recent public work lines up with that use case: preview artifacts, policy gates, deployments, centrally managed credentials, integrations, and agent-aware command flows.
Do not adopt it because agents are trendy. Adopt it if you want infrastructure automation where code, policy, deployment, audit, and agent workflows live close together.
Sources
- https://pulumi.com
- https://github.com/pulumi/pulumi
- https://github.com/pulumi/pulumi/releases/tag/v3.237.0
- https://github.com/pulumi/pulumi/releases/tag/v3.235.0
- https://github.com/pulumi/pulumi/releases/tag/v3.234.0
- https://www.pulumi.com/blog/dark-factory-pattern-pulumi-autonomous-iac/
- https://www.pulumi.com/blog/connect-any-git-server-to-pulumi-deployments-with-custom-vcs/
- https://www.pulumi.com/blog/neo-integration-catalog/