Developer-facing AI speeds up code delivery and unintentionally creates a new bottleneck: platform engineering. Pulumi Neo is a purpose-built infrastructure automation agent that understands IaC, cloud context, policies, secrets, and multi-repo impact. Neo runs inside Pulumi’s governance model, produces change proposals (and PRs, if authorized), respects RBAC, and is designed to amplify, not replace, platform engineers so infrastructure can keep pace with developer velocity.

Why we need Neo: the velocity problem platform teams face

AI coding assistants delivered a huge win for developer productivity. Pull requests and feature delivery have accelerated massively — great for shipping. But every faster ship adds platform work: monitoring, secrets management, deployment pipelines, policy checks, audits, and cross-repo dependency updates. Generic code assistants can write code fast, but they lack the organizational, security, and infrastructure context that platform teams depend on. The result is:

• More PRs that need platform review and remediation.
• Increased risk of insecure or non-compliant changes reaching production.
• Platform teams are stuck firefighting instead of building strategic platforms.

Platform engineers don’t just need more speed — they need contextualized automation that understands infrastructure, policies, state, and organizational impact. That’s the idea behind Neo.

What is Pulumi Neo?

Pulumi Neo is an AI automation agent built specifically for platform and infrastructure engineering. It’s not a generic code assistant bolted onto infrastructure — Neo is built on Pulumi’s platform capabilities and uses your infrastructure-as-code, policies, and environment configuration as its operational context.

Key claims about Neo:

• Deep knowledge of cloud context, IaC, secrets, and configuration, and internal developer platforms.
• Respects your security and policy guardrails; works with human-in-the-loop approvals.
• Operates within the RBAC entitlements of the conversing user (no privilege escalation).
• Can analyze your infrastructure, propose code changes, and (with GitHub integration) create PRs.
• Built on Pulumi governance (policies, infrastructure graph, audit trails) — not a separate AI layer.

Core features at a glance

• Infrastructure-aware analysis: Neo inspects your Pulumi graph and stacks to find version drift, configuration issues, and cross-repo dependency risks.
• Policy-aware suggestions: Neo evaluates changes against your Pulumi policies (ESC/policies) before proposing modifications.
• Automated change proposals: Neo can generate code changes and, with appropriate permissions and a GitHub App installed, open PRs with change notes and rationale.
• Human-in-the-loop approvals: Neo asks for confirmations and respects your approval flows before making changes.
• Audit trails & governance: All actions are governed by the Pulumi platform features you already rely on, preserving auditability and compliance.
• Permission model: Neo only acts within the user’s existing RBAC; conversations and tasks are private to the user who created them.

Why Neo matters to platform engineers — the value proposition

1. Scale platform work without hiring proportionally more people. Neo automates routine dependency updates, runtime patches, and multi-repo changes that would otherwise require hours of manual coordination.
2. Reduce infrastructure debt and risk. By surfacing version drift and policy violations across all stacks, Neo helps you remediate problems before they become incidents.
3. Preserve safety & compliance. Because it runs within your policies and RBAC, Neo reduces risky blind changes that generic AIs might suggest.
4. Free up platform teams for strategic work. With routine tasks automated, engineers can focus on building internal platforms, security posture, and long-term architecture.
5. Reinforcement cycle — Neo improves with your IaC. The more Pulumi components, policies, and environment configs you have, the better Neo’s context and suggestions become.

Limitations to be aware of (important)

• GitHub only for repo automation. Neo works with GitHub repositories; GitLab/Bitbucket are not supported yet.
• Tasks are private. Neo tasks cannot be shared or transferred between users.
• Code-only changes. Neo modifies infrastructure by changing code (Pulumi projects) — it does not make API/UI changes in Pulumi Cloud or create new repos/projects.
• No project/repo creation. Neo cannot initialize new Pulumi projects or create GitHub repos.

Step-by-step: implementing Neo in the Pulumi UI

Below is a practical, actionable walkthrough to get started with Neo in Pulumi Cloud. (This guide follows the UX terms referenced by Pulumi: Access Management, Copilot settings, and Agent Tasks.)

Before you begin: ensure you have Pulumi Cloud access and an account with the right admin or RBAC entitlements to enable/verify AI features and integrations.

1) Enable Neo for your organization

1. Log in to Pulumi Cloud with an account that has organization-level settings access.
2. Open Access Management (usually found under Organization or Settings).
3. Under Settings, find the Pulumi Copilot / AI features section.
4. Ensure AI features are enabled. Neo is enabled by default for eligible orgs, but confirm this setting.
   • If AI features are disabled, toggle them on for your organization.

2) (Optional but recommended) Install the Pulumi GitHub App

Neo can suggest changes without GitHub integration — but to let Neo create PRs automatically and read repository content for richer context, install the Pulumi GitHub App.

1. In Pulumi Cloud, navigate to Integrations (or the GitHub integration page).
2. Install the Pulumi GitHub App to the relevant GitHub organization(s) and repositories.
   • Grant it the minimum scopes required: read repository content and open pull requests on the repositories you want Neo to operate on.
3. Verify installation in Pulumi Cloud (you should see connected repositories/stacks listed).

3) Confirm RBAC & permission model

1. Neo acts with the privileges of the user who starts a task. Review your RBAC setup:
   • Ensure users who will run Neo have the appropriate entitlements (read access for analysis tasks, write/PR permissions if you want them to allow Neo to open PRs).
2. Decide whether you want users to have PR-creation rights or prefer them to run Neo only in a review/propose mode.

4) Create your first Neo task (read-only analysis)

1. In the Pulumi Cloud left navigation, click Agent Tasks (under the Neo section).
2. Click New Task.
3. Start with a read-only analysis prompt. Example prompt:
   • Which of my resources are not using their latest major version?
4. Neo will:
   • Acknowledge the request and scan your stacks/repositories it can access.
   • Present findings grouped by severity and impact.

5) Ask follow-up and prioritization questions

1. After the initial analysis, ask Neo:
   • Which version issue should I address first?
   • Neo will return a prioritized plan based on blast radius, dependencies, and policy impact.
2. If you want Neo to propose changes, follow with:
   • Can you propose the necessary code change to address the highest priority item?

6) Generate, review, approve, and create PRs

1. Neo will generate code modifications or a plan depending on the scope.
2. It will ask for your confirmation before applying changes that result in PR creation.
3. If GitHub App is installed and you’ve authorized PR creation, Neo can:
   • Create a branch, commit the changes, and open a PR with a detailed description and rationale.
4. Review the PR as you normally would (CI, policy checks, reviewers), then merge.

7) Monitor workflow minutes and audit trails

• Running pulumi preview via Neo consumes workflow minutes. Monitor your usage per Pulumi Cloud’s billing/pricing pages and plan accordingly.
• All actions and approvals are recorded in Pulumi’s audit trail — use these for compliance and post-change reviews.

8) Disable Neo (if needed)

• To disable Neo for your organization or a user, return to Access Management → Settings → Pulumi Copilot and toggle the AI feature off. If Copilot is disabled, Neo will be unavailable.

Example: a real-world quick scenario (Lambda Node.js runtime upgrade)

1. Prompt Neo: Find all AWS Lambda functions in my org running Node.js 12.x or 14.x and propose runtime upgrades to 18.x where compatible.
2. Neo runs an analysis and lists affected functions and stacks, showing:
   • The runtime, dependencies, and potential compatibility flags.
3. Ask: Which functions are highest risk to upgrade automatically?
4. Neo prioritizes by traffic, dependencies, and policy impact.
5. Ask Neo to propose code changes for low-risk functions.
6. Neo generates change diffs, asks for confirmation, then opens PRs to update the Lambda runtime and includes a PR description with testing steps and rollback instructions.

Best practices for teams adopting Neo

• Invest in IaC & policies first. Neo gets better the more you codify: components, policy-as-code, and environment configs are its context.
• Start read-only. Run analyses to build trust before enabling automatic PR creation.
• Define approval gates. Keep human-in-the-loop approvals for high-risk or high-impact changes.
• Use GitHub scopes minimally. Grant Neo the least privilege required to operate on the repos/stacks you choose.
• Track workflow minutes. Be aware that pulumi preview runs consume workflow minutes; plan usage and budgets.
• Document Neo runs. Keep PR templates and documentation that Neo can include in PRs (testing, rollbacks, owners).

Conclusion

Pulumi Neo is a practical shift from “generic AI + infrastructure plugins” to an agent that understands infrastructure context natively and operates inside the governance you already use. For platform engineers, that means fewer manual cross-repo edits, faster, policy-aware remediation, and more time to build the strategic platforms teams need.

If you manage platform engineering, try a conservative rollout: enable Neo in read-only mode, run discovery tasks to see what it finds, codify missing policies, then broaden Neo’s permissions and GitHub reach as confidence grows. The goal is not to replace platform engineers, but to amplify them — turning platform teams from bottlenecks into enablers of sustainable velocity.