Pulumi Blog: Governance

Enforce ISO 27001 Across Your AWS Infrastructure

Dan Biwer — Tue, 30 Jun 2026 00:00:00 +0000

ISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We’re changing that.

Today we’re shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as iso-27001-aws. It encodes the standard’s security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months.

Why ISO 27001 matters

For many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it.

How the pack maps to ISO 27001

The hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance.

The pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the pack reference.

Audit and prevent

The same pack works two ways, so you can both reach compliance and stay there:

Audit. Scan your existing AWS estate against the pack, including resources that Pulumi doesn’t manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects.
Prevent. Run the same pack as a preventative policy during pulumi up to block non-compliant resources before they’re ever created. New infrastructure is born aligned to the standard.

Audit gets you clean. Preventative policies keep you clean.

A growing library of pre-built packs

ISO 27001 joins a growing library of pre-built packs for AWS, each authored and maintained by Pulumi and kept current with its source standard:

ISO/IEC 27001:2022
CIS Controls v8.1
NIST SP 800-53 Rev. 5
PCI DSS v4.0
HITRUST CSF v11.5
Pulumi Best Practices

Adopting any pack means you skip the authoring work entirely, inherit framework mappings maintained by Pulumi, and apply a consistent baseline across every stack and account.

Get started today

The ISO 27001 pack is available now to every Pulumi Cloud user:

Browse the pack reference to see all 238 policies and how they map to the standard’s controls.
Explore the full pre-built packs index.
Follow the get-started guide to run your first audit.

Try Pulumi policies

Ready to align your AWS infrastructure to ISO 27001? Sign up for Pulumi Cloud and run the pack against your estate, or read the policy get-started guide to dig in.

Need a compliance pack for a framework that isn’t listed here? Open a request in pulumi/pulumi-cloud-requests or come tell us in the community Slack. We’re listening.

Enforce AWS Organizations Tag Policies with Pulumi

Alejandro Cotroneo — Thu, 20 Nov 2025 10:00:00 -0800

Tags are the foundation of cloud governance, enabling cost allocation, ownership tracking, compliance reporting, and automation across your AWS infrastructure. Yet missing or inconsistent tags remain one of the most common governance challenges. Manual tag enforcement is error-prone, and discovering missing tags after deployment means your cost reports and compliance audits are already operating with incomplete data.

Today, we’re excited to announce a new pre-built policy pack created in partnership with AWS: AWS Organizations Tag Policies. This pack validates your infrastructure as code against tag policies configured in AWS Organizations, blocking deployments when required tags are missing and shifting tag governance left into your development workflow. Define your tag requirements once in AWS Organizations and enforce them consistently across all your Pulumi deployments.

How it works

The new policy pack integrates directly with your AWS Organizations Tag Policies as the single source of truth. No separate policy configuration or custom code required. When you run pulumi up, the pack retrieves your tag requirements from your AWS organization and validates that every resource has the required tags.

Start by enabling the pack in advisory mode to surface tagging violations in Pulumi Cloud’s Policy Findings hub without blocking deployments. This collaborative workspace allows your team to triage, prioritize, and systematically remediate missing tags. Once your infrastructure is compliant, switch to mandatory mode to prevent future non-compliant deployments.

Getting started

The pack works with both AWS Classic and AWS Native Pulumi providers, covering the full range of taggable AWS resources. To get started:

Configure tag policies in AWS Organizations following the AWS documentation.
Grant required permissions by adding the resourcegroupstaggingapi:ListRequiredTags permission to the IAM role or user that runs your Pulumi deployments.
Enable the pack in Pulumi Cloud:
1. From within your organization, navigate to the Policies tab
2. Under Policy Packs, select the Available tab
3. Select AWS Organizations Tag Policies and select Add to organization
4. From the Organizations tab, apply the policy to a Policy Group
Configure enforcement level: Set to advisory for warnings or mandatory to block non-compliant deployments.

Within minutes, every Pulumi deployment in your organization will validate tag compliance, ensuring that no resources are created without required tags.

Try it today

The AWS Organizations Tag Policies policy pack is now available to all Pulumi Team and Enterprise customers.

Get started with the integration
Learn about enforcing tag policies with AWS Organizations Tag Policies
Sign up for Pulumi Cloud if you’re new to Pulumi
Join the Community Slack to share feedback

We’re excited to partner with AWS on this capability and help organizations proactively enforce tag governance. Give it a try and let us know what you think!

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Craig Symonds — Wed, 05 Nov 2025 00:05:00 +0000

The era of AI-accelerated development has created a paradox: the faster developers move, the bigger the governance challenge becomes. For years, security and platform teams have worked to “shift left,” but the tools available have been incomplete. Most focus on detection, which is necessary but not sufficient. They identify thousands of policy violations across an organization’s infrastructure but leave teams with an overwhelming backlog and no scalable way to remediate it. This creates a persistent gap between finding a problem and fixing it. The result is an impossible choice between development velocity and organizational control, forcing leadership to slow down innovation to manage risk.

Today, we end that compromise.

We are thrilled to announce the next generation of Pulumi Policies, a comprehensive governance solution that moves beyond detection to deliver AI-powered remediation at scale. We’re introducing a new lifecycle to secure your cloud: first, Get Clean by using AI to fix your existing policy violations. Second, Stay Clean by using policy as a universal guardrail that makes AI-driven development not just fast, but fundamentally safe. These are not strictly sequential steps; you can begin enforcing “Stay Clean” policies for all new infrastructure while you simultaneously work on the “Get Clean” process for your existing footprint.

Watch our Launch Video:

Part 1: Get Clean - From Thousands of Issues to a Compliant State

The first step to a secure cloud is tackling the mountain of existing misconfigurations spread across your environments.

First, Gain Complete Visibility with the New Policy Findings Hub

To fix your issues, you first need to see them clearly. We have introduced a powerful Policy Findings Hub designed to give every stakeholder the exact view they need.

The Overview Tab: A high-level dashboard with compliance scores for leadership to track trends and measure your organization’s posture.
The Compliance Tab: A control-centric view for auditors and infosec teams, grouping findings by policy (e.g., CIS, NIST) to simplify evidence gathering and prove compliance.
The Issues Tab: A collaborative workspace for platform and development teams to triage, assign, prioritize, and track the remediation of every policy issue.

This hub is powered by our flexible audit capabilities. With Audit Scans for IaC Stacks, you can get an instant compliance baseline on all your existing Pulumi-managed infrastructure without blocking developers or re-deploying thousands of stacks. This is combined with discovery scans of your cloud accounts to give you a single, unified view of every resource, whether managed by Pulumi or not.

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Visibility creates a new problem: an overwhelming backlog. Manually fixing thousands of issues is an impossible task.

This is where Pulumi Neo provides a powerful solution.

Pulumi Neo, our AI platform engineer, is now integrated directly into the Policy Findings hub to automate the most difficult part of the process: the fix itself. From the Issues tab, your teams can now select a group of policy issues, assign them to Neo, and trigger a remediation flow.

Neo is smart. It will:

Analyze the non-compliant resources and the policies they are violating.
Understand the required configuration to make them compliant.
Generate a pull request with the exact code changes needed to fix the issues.

Most powerfully, for an unmanaged resource discovered via a cloud scan, Neo will generate the code to import the resource into a Pulumi stack and apply the fix. This “Import and Fix” workflow transforms unmanaged infrastructure into governed, compliant code, turning a task that could take a developer hours into a simple review-and-merge process. Your teams can finally burn down their issue backlog and achieve a state of continuous compliance.

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

Once you begin cleaning your environment, the next challenge is to stay clean. As AI accelerates infrastructure creation, you need robust guardrails to ensure it doesn’t also accelerate the creation of security risks.

The answer is Policy as Real Code. Pulumi Policies uses general-purpose languages like TypeScript and Python to create sophisticated guardrails that govern every change. To help you establish these controls immediately, we are launching a new suite of pre-built compliance packs authored and maintained by Pulumi experts.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

These policies act as a universal guardrail for your entire organization by blocking non-compliant changes during pulumi up, before they are ever created. Learn more about our compliance packs.

And now, you can even use Neo to author new policies. You can ask Neo in plain English to “create a policy that prevents overly permissive IAM roles,” and it will generate the code for you. This creates a powerful, dynamic governance system where AI can help you build the very rules that then govern its own actions. If you then ask Neo to create an admin role, the deployment will be blocked by the policy it just helped write. This is how we make AI safe to go fast.

A New Era of Collaboration

This “Get Clean, Stay Clean” lifecycle transforms how teams work together:

Platform Teams lead prevention by building real-code guardrails, proving their value with measurable compliance scores.
Security Teams drive the “Get Clean” process with continuous, non-blocking audit scans and use the Findings hub to manage compliance without slowing development.

Governance That Accelerates You

The age of AI-driven development demands AI-powered governance. With this new generation of Pulumi Policies, we are providing the essential infrastructure for platform engineering teams to not just survive, but thrive. You can finally build preventative guardrails that developers love, secure your cloud at scale, and transform governance from a blocker into a business accelerator. Learn more about Pulumi Insights & Governance capabilities.

This powerful new experience is available today. Navigate to the Policies and Policy Findings tab in Pulumi Cloud to explore your new governance capabilities and meet the future of platform engineering.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to set up and apply a policy group to stacks and clouds.
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

New Audit Policy Scans for Pulumi Stacks

Levi Blackstone — Wed, 05 Nov 2025 00:04:00 +0000

Audit Policy Scans for Pulumi Stacks is part of the next generation of Pulumi Policies. This capability uses policies to run compliance checks against the last successful deployment state of your stacks, providing continuous compliance monitoring without impacting your existing CI/CD workflows.

Until now, Pulumi’s preventative policies have served as a critical “shift-left” gate, blocking non-compliant changes during pulumi up. While essential, this created challenges for organizations wanting to roll out new governance across thousands of existing stacks. This new evaluation mode solves that problem, giving you a complete and continuous view of your IaC compliance posture without the friction.

A Complete Audit Story: Cloud Accounts and IaC Stacks

Pulumi’s audit philosophy is to provide complete visibility across your entire cloud footprint. We achieve this through two complementary audit modes:

Audit Scans for Cloud Accounts (Existing): This capability scans your live cloud environments (like an AWS account or Azure subscription). Its primary purpose is to give you a holistic view of your security posture by discovering all resources, including those not managed by Pulumi, and detecting configuration drift. This is how you find unmanaged, legacy, or manually-created resources that violate your policies.
Audit Scans for Pulumi Stacks (New): The feature extends this audit power to the source of truth for your managed infrastructure: your Pulumi stacks. It evaluates the last successfully deployed state of your IaC. This allows you to get an instant compliance baseline of all your managed infrastructure without having to redeploy anything, making it perfect for frictionless policy rollouts at scale.

Together, these two audit modes give you a comprehensive picture of your entire cloud estate, all feeding into one unified Policy Findings hub.

Key Scenarios for Audit Scans for Stacks

This new evaluation mode for IaC stacks is designed to unlock policy adoption at scale and accelerate developer velocity. Key use cases include:

Gain an instant compliance overview across all existing stacks: Apply policies centrally and get immediate visibility into your compliance posture without requiring redeployment of every stack.
Accelerate policy rollouts: By decoupling policy evaluation from the critical deployment path, deployments become faster and developers are unblocked. Teams still get immediate feedback on the compliance of the deployed infrastructure.
Ensure continuous compliance: Evaluation is automatically triggered whenever policy configurations change. This ensures the latest policies are always evaluated against the latest deployed infrastructure.

How It Works

This new mechanism runs against the last known successfully deployed state of your IaC Stacks as recorded by Pulumi Cloud.

Evaluation is triggered automatically after a successful pulumi up or when a policy pack attached to the stack is updated.
Results are unified into the same Policy Findings hub you use today, giving you a single pane of glass for all preventative and audit policy findings.

How to Get Started

You can enable audit scans for your IaC stacks by adding them to an Audit Policy Group.

Navigate to the Policies tab in the left navigation bar of the Pulumi Cloud console.
Create a new Audit Policy Group or select an existing one.
Select Pulumi Stacks and add the specific stacks you want to monitor.
Add Policy Packs to the group.
Save the policy group. That’s it!

The next time any of the selected stacks completes a pulumi up, a post-deployment evaluation will be automatically triggered, and the results will populate in the Policy Findings hub.

Audit policy scans consume workflow minutes from your Pulumi Cloud plan. Each scan counts toward your monthly quota based on the complexity and number of resources evaluated. See pricing documentation for details.

A Complete Governance Picture

With the addition of post-deployment evaluation for IaC stacks, you now have a complete, 360-degree view of your cloud environment. You can use audit scans for cloud accounts to get a handle on your entire live footprint, and use audit scans for stacks to easily assess your IaC-managed footprint without adding friction to your development process.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to continuously scan resources and identify violations
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Policy Findings Hub: Move From Alert Fatigue to Action

Alejandro Cotroneo — Wed, 05 Nov 2025 00:03:00 +0000

For platform and security teams, enabling robust cloud scanning often creates a new problem: an unmanageable firehose of policy alerts. Identifying a violation is only the first step. Without a system to manage the lifecycle of these findings, teams are quickly overwhelmed, leading to prioritization paralysis and a perpetually growing backlog.

The Policy Findings hub in Pulumi Cloud is the solution to this alert fatigue. It’s a purpose-built, collaborative workspace that turns a noisy list of violations into organized, actionable tasks. The hub brings clarity and structure to the compliance process, guiding teams from initial discovery to a verified fix.

From Raw Data to Actionable Insights

The Policy Findings hub is designed with distinct views for every stakeholder involved in the governance lifecycle.

1. The Overview Tab: A Dashboard for Leaders

For a platform lead or security manager, the goal is to understand the big picture. The Overview tab provides a high-level dashboard of your organization’s compliance health, answering key questions at a glance:

What is our overall resource compliance score?
Are we trending in the right direction?
Which parts of our cloud infrastructure (stacks, accounts, etc.) carry the most risk?

This view helps leadership track progress and make data-driven decisions about where to focus engineering efforts.

2. The Compliance Tab: The Auditor and Infosec Workspace

For the infosec members and auditors, context is everything. Simply listing thousands of violations is not helpful. The Compliance tab provides a policy-centric view, grouping all findings by the specific control they violated (e.g., a specific rule within CIS or NIST).

This is crucial when preparing for an audit or assessing adherence to a specific security framework, as it allows you to see exactly where you are compliant and where you have gaps, control by control.

3. The Issues Tab: The Team’s Daily Workspace

This is the space where insight is turned into action. The Issues tab is a collaborative triage board designed for the day-to-day workflow of platform and development teams. It provides the full toolset needed to manage the lifecycle of an issue from start to finish:

Triage and Prioritize: Filter issues by severity, resource type, or policy to focus on what matters most. Set a priority level from P0 (critical) to P4 (low).
Assign Ownership: Assign issues to specific team members to ensure clear ownership and accountability.
Manage Lifecycle: Mark an issue as “Ignored” with a justification. This is a critical workflow for acknowledging intentional exceptions, which cleans up your dashboard and allows the team to focus on legitimate issues.

And for the most critical part of the workflow — the fix itself — we’ve integrated our AI agent, Pulumi Neo, directly into this view.

After selecting one or more issues, your team can assign the task to Neo. It will analyze the violations and automatically generate a pull request with the necessary code changes. For unmanaged resources, Neo will even generate the code to import them into Pulumi and apply the fix. This turns a complex manual task into a simple review-and-merge process, allowing your team to finally burn down the backlog.

Turning Alerts into Action

Effective governance goes beyond identifying violations. It requires a structured system that turns every finding into a clear and trackable path to resolution. The new Policy Findings hub provides that end-to-end workflow, from visibility to accountability to automated remediation.

By organizing policy data into meaningful views and integrating Pulumi Neo directly into the issue management process, teams can move past alert fatigue and focus on what matters most: fixing problems quickly and maintaining continuous compliance.

This new experience is now available. Navigate to the Policies > Findings tab in the Pulumi Cloud to explore your new compliance dashboard and start turning alerts into action.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to manage compliance across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

New Compliance Packs for CIS, NIST, and PCI DSS

Luke Ward — Wed, 05 Nov 2025 00:02:00 +0000

Achieving compliance with industry standards such as CIS, NIST, or PCI DSS is a foundational step for every organization. Yet for many teams, it’s often a manual, months-long process that involves interpreting controls, authoring custom policies, and validating configurations across multiple clouds. These challenges often slow progress toward a known and secure cloud state.

We’re changing that. To simplify this journey, Pulumi launched a new suite of pre-built compliance policy packs for CIS Controls v8.1, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.

These packs are your accelerator for the “Get Clean” journey, allowing you to enforce critical security and compliance baselines across your cloud infrastructure in minutes, not months.

More Than Just Detection: The Complete Governance Lifecycle

Traditional security tools are reactive, scanning for problems after resources have been deployed. With Pulumi, these new compliance packs are the engine for an end-to-end governance lifecycle that integrates directly into your cloud operations.

Audit for Full Coverage: Run these packs in audit mode to scan your entire cloud estate, including resources managed by Pulumi and those created through other means. This gives you an instant, comprehensive view of your current compliance posture.
Triage and Remediate: When a pack finds a violation, the finding appears in the new Policy Findings hub. From there, your team can triage, assign, and track the issue through its entire lifecycle. And with our new AI-powered capabilities, you can assign the issue to Pulumi Neo to automatically generate a pull request with the fix.
Prevent Non-Compliance: Once your environment is clean, you use these same packs as preventative guardrails. By running them during pulumi up, you block non-compliant resources before they are ever created, ensuring you “Stay Clean.”

This tri-modal capability—Audit, Remediate, and Prevent—is uniquely powerful, allowing you to fix existing issues while stopping new ones from being introduced.

New and Expanded Compliance Packs

Our new policy packs provide extensive, out-of-the-box coverage for some of the most widely adopted security frameworks. They are authored and maintained by Pulumi experts and join our existing library to provide a comprehensive toolkit for cloud governance.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

Benefits of Pre-Built Packs

Accelerate Compliance: Implement comprehensive governance controls in minutes without authoring hundreds of policies from scratch.
Leverage Expert Knowledge: Packs are authored and maintained by Pulumi, incorporating deep expertise in cloud and the nuances of each framework.
Codify Controls for Audits: Demonstrate to auditors that specific compliance controls are consistently enforced through code, providing a clear evidence trail.
Reduce Risk Proactively: Catch common security risks and compliance violations before deployment, drastically reducing your organization’s exposure.

Get Started Today

These policy packs are available now and are the perfect way to begin your governance journey with Pulumi.

To get started, head to the Policies page in your Pulumi Cloud organization and click on the All tab to find these new packs. Add them to an Audit Policy Group and run a scan. Within minutes, you’ll see a complete picture of your compliance posture in the Policy Findings hub, ready for triage and remediation.

Need a compliance pack for a standard that isn’t listed here? Please let us know by raising a request on our GitHub repository.

Try Pulumi Policies

New to Pulumi? Start your governance journey today.

Sign up for Pulumi Cloud and start a compliance task with Neo
Read the Get Started guide to apply and manage policies across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

How to Build an Internal Developer Platform: Strategy, Best Practices, and Self-Service Infrastructure

Mitch Gerdisch — Thu, 14 Aug 2025 05:13:02 +0200

Welcome to the first post in our IDP Best Practices series. In this guide, we’ll walk through the strategic foundations for designing an Internal Developer Platform that empowers developers without sacrificing governance, security, or operational control.

At Pulumi, we’ve worked with hundreds of teams facing the same core challenge: How do you give developers the infrastructure access they need, while maintaining the governance and security your organization requires?

That tension is at the heart of every IDP conversation. Teams want to move faster and innovate, but also need to stay compliant, control costs, and maintain operational stability.

The good news? You can do both, with a clear strategy and the right approach. This series shares proven best practices for designing, building, and scaling IDPs using Pulumi.

These lessons come from real-world implementations across industries and company sizes—and are built to grow with you.

Understanding the Platform Engineering Layers in Your Internal Developer Platform

When we work with customers on their platform strategy, we often start by referring to the “platform engineering layer cake.” Here is a quick walkthrough of each layer and how Pulumi IDP constructs fit this layer cake approach:

Layer 1: Infrastructure Layer - This is your raw cloud resources: VMs, databases, networks, storage. These are the fundamental building blocks that exist in AWS, Azure, GCP, and other cloud providers.

Layer 2: Platform Layer - This is where Pulumi Components live. Components take those raw infrastructure resources and package them into higher-level abstractions that encapsulate best practices, security policies, and organizational standards. For example, instead of manually configuring 15 different AWS resources to create a secure web application, you create a component that handles all that complexity and exposes just the configuration options that matter to your developers.

Layer 3: Developer Experience Layer - This is where Pulumi Templates and the Private Registry come into play. Templates provide ready-to-deploy patterns that developers can customize, while the private registry makes everything discoverable and manageable at scale.

In our workshop, we focused specifically on those top two layers because that’s where the transformation happens. This is where you turn raw infrastructure into something developers can actually use productively without becoming infrastructure experts themselves.

Here’s how this maps to what you’re actually building:

Infrastructure Layer → Raw Cloud Resources

Your foundation is still the same: AWS EC2 instances, Azure Virtual Networks, GCP Cloud Functions. Pulumi’s providers give you access to these resources using real programming languages instead of YAML or proprietary DSLs.

Platform Layer → Pulumi Components

This is where you create your reusable building blocks. A component might encapsulate:

A complete microservice infrastructure pattern (load balancer, auto-scaling group, database, monitoring)
A secure data pipeline (storage, processing, access controls, encryption)
A standardized Kubernetes application deployment (ingress, service, deployment, secrets management)

Components are written once in any supported language (TypeScript, Python, Go, .NET, Java) but can be consumed by teams using any of these languages. This is crucial. Your platform team might write components in Go, but your application teams can consume them in Python or TypeScript.

Developer Experience Layer → Templates + Private Registry

Templates are complete, deployable projects that use your components. They provide:

Getting started patterns: “Deploy a new microservice”
Reference architectures: “Deploy a three-tier web application”
Environment patterns: “Set up a complete dev/staging/prod pipeline”

The Private Registry is your distribution mechanism. It’s where components and templates become discoverable, versioned, and manageable. Developers don’t need to hunt through Git repositories or Slack channels to find the right building blocks. Everything is catalogued, documented, and accessible through familiar package management workflows.

IDP Example: Building a Web Application Platform Step-by-Step

Let’s make this concrete with an example from our workshops. Say you want to enable teams to deploy secure web applications:

Infrastructure Layer: You need an Application Load Balancer, EC2 Auto Scaling Group, RDS database, VPC with proper subnets, Security Groups, IAM roles, CloudWatch monitoring, and S3 bucket for static assets. That’s about 20+ individual AWS resources that need to be configured correctly and securely.

Platform Layer (Components): You create a WebApplication component that encapsulates all this complexity. Your component exposes simple configuration options like:

const app = new WebApplication("my-app", {
 instanceType: "t3.medium",
 minSize: 2,
 maxSize: 10,
 databaseSize: "small",
 environment: "production"
});

Behind the scenes, your component handles all the security configurations, networking setup, monitoring, and best practices. You publish this component to your private registry.

Developer Experience Layer (Templates): You create templates like:

web-app-starter: A simple web application using your WebApplication component
microservice-template: API service with database and monitoring
full-stack-template: Frontend, backend, and database in a complete environment

Developers can now run pulumi new web-app-starter and get a production-ready, secure web application in minutes instead of weeks. The template uses your component, which handles all the underlying infrastructure complexity.

This layered approach solves the core challenge we see every platform team struggling with: how do you provide developers with the infrastructure they need without creating operational bottlenecks or compromising security standards.

Why Internal Developer Platforms Matter in 2025 and Beyond

While DevOps brought us incredible advances in how we ship and maintain software, we’ve watched many organizations struggle with the unintended consequences: tool sprawl, Day 2 operational pain, and developers who are drowning in infrastructure complexity.

That’s why platform teams have emerged. You exist to solve these challenges by building tools and workflows that enable your internal customers (the developers) to provision infrastructure and deploy software without getting blocked. But here’s the thing I’ve learned from working with hundreds of platform teams: success isn’t just about the tools you choose. It’s about the strategy behind how you implement them.

5 Core Components of a Successful Internal Developer Platform

Through years of working with platform teams and analyzing what separates successful IDPs from those that struggle to gain adoption, we’ve identified five essential components that every platform strategy needs. These aren’t theoretical concepts. They’re battle-tested patterns that work across organizations of all sizes and industries.

1. Abstractions

Let me be clear about something: abstractions aren’t about dumbing down infrastructure for developers. The abstraction is really where you’re hiding the complexity of the underlying infrastructure from your end users, but you’re doing it intentionally to provide appropriate interfaces for different personas in your organization.

We’ve seen too many platform teams get this wrong by either over-abstracting (creating black boxes that developers can’t customize) or under-abstracting (exposing too much complexity). The sweet spot is creating component resources that encapsulate your infrastructure patterns and best practices into reusable building blocks that can be consumed across different programming languages and deployment scenarios, while still providing escape hatches when needed.

2. Blueprints

Blueprints are your templatized, well-architected patterns that developers can use to bootstrap their infrastructure. But here’s what I want you to understand about blueprints: they’re not just starting points that you throw over the wall to developers. They’re carefully designed patterns that embody your organizational best practices and architectural decisions.

When we see successful platform teams, their templates serve as both accelerators and guardrails. They give developers a fast path to production-ready infrastructure while ensuring that everything they deploy follows your organization’s standards. That’s the power of good blueprint design: speed and compliance working together, not against each other.

3. Workflows

Here’s where many platform teams get trapped: they try to build one workflow to rule them all. But in our experience working with organizations across every industry, you need to support multiple consumption patterns because you have multiple types of users. You need:

No-code workflows for users who want point-and-click deployment (think product managers or junior developers who just need to spin up a database)
Low-code workflows using tools like Pulumi YAML for configuration-driven infrastructure (perfect for developers who understand infrastructure but don’t want to write Go or TypeScript)
Full-code workflows for developers who need maximum flexibility and want to leverage the full power of general-purpose programming languages

The key insight? These aren’t three different platforms. They’re three different interfaces to the same underlying components and templates.

4. Security guardrails

This is probably the most important distinction we can share with you: you want to have guardrails, not gates. Too many platform teams create approval processes and manual checkpoints that completely undermine the self-service promise they’re trying to deliver.

Guardrails are different. They start with the best practices and security built into the reusable abstractions. But even the most secure solutions need a safety net. This safety net is policy-as-code that runs automatically, preventing violations before deployment happens. When we work with customers on implementing Pulumi CrossGuard, we’re not creating new friction. We’re embedding security, compliance, and cost controls directly into the deployment process. The developer gets immediate feedback, and you get the assurance that nothing goes to production without meeting your standards.

5. Self-service

Everything we’ve talked about so far builds toward this moment: enabling developers to provision and manage infrastructure independently. But self-service isn’t just about providing a UI. It’s about carefully orchestrating all the other components to create experiences that are both powerful and intuitive.

When we walked through the demo in our workshop, what you saw was the culmination of thoughtful platform design. Developers can discover available services, deploy infrastructure through whatever interface makes sense for them, and manage their resources over time, all without requiring tickets or manual intervention from platform teams. That’s the promise of a well-designed IDP: developer autonomy without operational chaos.

Put your IDP strategy into practice

Build reusable components, golden paths, and self-service workflows on Pulumi, and give developers autonomy while you keep governance and costs in check.

Get started

How to Implement Your IDP Strategy

Supporting Different Personas in Your Internal Developer Platform Design

One of the biggest mistakes we see platform teams make: they try to build for their most sophisticated users first. But here’s what I’ve learned from working with hundreds of organizations: you need to think about all your personas from day one.

In most organizations, you’re serving:

Infrastructure engineers who want full control and flexibility (they’ll use the full-code workflows)
Application developers who need infrastructure but prefer higher-level abstractions (perfect for low-code approaches)
Non-technical users who want simple, point-and-click deployment (your no-code users)

The breakthrough insight that separates successful platform teams from struggling ones is this: all these personas can be served by the same underlying components and templates, just consumed through different interfaces. You don’t need to build three different platforms—you need to build one platform with three different consumption models.

Why a Private Registry Is Key to IDP Adoption

Here’s something we always tell platform teams: if you don’t solve the discoverability problem, your beautiful components and templates will sit unused in Git repositories where no one can find them. That’s why the private registry isn’t just a nice-to-have. It’s the foundation that makes everything else work.

When you establish a private registry as your source of truth for components, templates, providers, and policies, you’re solving two critical problems at once. First, discoverability: developers can actually find and explore what’s available. Second, lifecycle management: you can see where each package is being used, track version drift, and understand the impact of changes before you make them.

The workflow is beautifully simple: you publish standardized building blocks with a single pulumi publish command, and developers discover and consume these assets through familiar package management workflows they already know.

Aligning Your IDP to Organizational Context and Services

One pattern we see in every successful IDP implementation is that the platform reflects how the organization actually works. Your developers don’t think in terms of individual stacks or resources. They think in terms of services, applications, and business functionality.

That’s why we built Pulumi Services - to let teams logically group stacks and ESC environments in ways that make sense to your organization. Pulumi Services improve organization by helping your team model infrastructure in a way that’s familiar - simplifying Day 2 operations by providing additional context like links to relevant dashboards, Slack channels and more. When something breaks at 2 AM, your on-call engineer needs to understand dependencies, track usage, and manage infrastructure in the context of the business services that are actually impacted.

How to Measure the Success of Your Internal Developer Platform

Here’s something that might surprise you: the most successful platform teams we work with don’t measure their success by how many cool features they’ve built. They measure success by the business outcomes they’re driving:

Reduced time-to-market through faster infrastructure provisioning (because at the end of the day, your platform exists to help the business move faster)
Improved developer productivity by eliminating infrastructure bottlenecks (happy developers ship more features)
Enhanced security posture through consistent policy enforcement (security that doesn’t slow people down is security that actually gets used)
Lower operational overhead through standardization and automation (because your platform team’s time is better spent on innovation than toil)

The numbers speak for themselves. We’ve worked with customers like Snowflake who reduced deployment times from one and a half weeks to less than a day. Starburst Data cut their infrastructure deployments from two weeks to just three hours. These aren’t vanity metrics. They’re business transformations.

IDP Strategy: 5 Key Steps to Build a Strong Foundation

If you’re just starting your IDP journey, here’s the roadmap we give to every platform team we work with:

Start with user research: Before you write a single line of code, go talk to your developers. Understand your different personas and their actual needs, not what you think they need. Do your users like to work from the command line? Do they prefer interacting with a UI?
Identify common patterns: Look for infrastructure patterns that get repeated across teams. These are your goldmine—the patterns that, once abstracted and templatized, will provide immediate value.
Begin with components: Build reusable infrastructure building blocks before you worry about fancy UIs or workflow orchestration. You need solid foundations before you can build the house.
Implement progressive disclosure: Give people simple interfaces for common use cases, but always provide escape hatches for complex scenarios. The moment your abstraction becomes a prison, developers will route around it.
Measure and iterate: Track adoption and gather feedback religiously. Your platform is only as good as its adoption rate, and adoption only happens when you’re solving real problems for real people.

The Future of IDPs and Platform Engineering

Trends come and go, but platform engineering is here to stay. It’s not just another tool or methodology. This is how modern organizations scale infrastructure to match the speed of innovation. The companies that win are the ones that treat their Internal Developer Platform (IDP) as a strategic foundation, not just a tool.

Your job isn’t just to manage infrastructure and choose the right tools - it’s to enable developers to move faster while keeping governance, security, and costs under control. Get that balance right, and your platform becomes a force multiplier across your entire engineering department.

The fastest way to get there? Focus on these five essential components:

Abstractions
Blueprints
Workflows
Security guardrails
Self-service

Together, they turn your IDP into more than just infrastructure automation, they create a platform that developers trust and your business relies on.

Ready to Build a Successful IDP that Scales?

Pulumi makes it easy to go from static IaC to dynamic, self-service infrastructure with real programming languages and built-in guardrails.

Explore Pulumi IDP or sign up for free to get started today.

Backstage vs Pulumi IDP: Why Infrastructure-First Wins!

Engin Diri — Wed, 13 Aug 2025 00:00:00 +0000

Developers are losing days every month to infrastructure bottlenecks, compliance hurdles, and inconsistent environments. Platform engineering promised to fix that, yet too many platforms fail before they deliver real impact.

In this comparison of Backstage vs Pulumi IDP, we’ll explore why choosing the right architectural approach matters more than the tool itself.

Quick comparison: Backstage vs Pulumi IDP

Backstage is an open-source developer portal framework from Spotify that focuses on service catalogs and documentation. It requires significant setup time (12-18 months) and ongoing maintenance (3-5 FTEs).

Pulumi IDP is an infrastructure-first internal developer platform that embeds governance, cost control, and security from day one. It can be deployed in hours with minimal ongoing maintenance.

The problem isn’t whether you choose Backstage or Pulumi IDP. The real question is: Will your platform treat infrastructure as a first-class concern, or as an afterthought?

According to Gartner, 80% of large enterprises will deploy internal developer platforms within the next two years. But without a strong infrastructure foundation, those platforms risk becoming expensive, hard-to-maintain bottlenecks instead of accelerators.

Why platform engineering efforts fail: Common mistakes

Platform teams consistently make four critical mistakes:

Neglecting Infrastructure Foundations
Over-focusing on the developer portal experience while letting infrastructure governance and scalability lag behind.
Ignoring Cost Efficiency
Prioritizing productivity at the expense of cloud cost management.
Example: One company considered giving every developer their own cluster, a scaling nightmare both technically and financially.
Treating Security & Governance as Add-Ons
Bolting on compliance after launch leads to constant firefighting and security debt.
Building for Yesterday’s Architecture
Designing general-purpose platforms that can’t keep up with Kubernetes-native workloads.

Portal-first vs infrastructure-first platform engineering

There are two dominant approaches:

Portal-First typified by Backstage, which starts with developer experience and service catalogs.
Infrastructure-First exemplified by Pulumi IDP, which builds the platform foundation around scalable, policy-driven infrastructure.

Platform Engineering Feature	Backstage (Portal-First)	Pulumi IDP (Infrastructure-First)
Primary Focus	Developer portal & catalog	Scalable, policy-driven infrastructure
Setup Time	12-18 months	Hours
Maintenance	3-5 FTE ongoing	Minimal ongoing overhead
Infra Provisioning	Requires separate tooling	Built-in
Cost Awareness	Depends on infra layer	Native
Security & Governance	Add-on	Built-in from day one

Backstage: The portal-first platform engineering approach

Backstage is an open-source framework for building developer portals. Originally built by Spotify, it excels at unifying tools, services, and documentation.

Strengths

Mature Ecosystem with over 1,200 integrations and a large community.
Excellent Service Catalog providing centralized metadata, ownership, and discovery.
Docs-as-Code that keeps documentation close to the codebase.
Self-Service Templates that standardize scaffolding for new projects.

Challenges

High Maintenance Overhead requiring 3-5 FTEs just to keep it running in large orgs.
Complex Setup with Yarn version headaches, TypeScript complexity, plugin upkeep.
Infra as an Afterthought that lacks built-in provisioning, often pushing infra concerns down the road.
Hidden Costs resulting in multi-million dollar TCO over three years for a 300-dev team when factoring in staffing and infra complexity.

Pulumi IDP: the infrastructure-first platform engineering approach

Pulumi IDP brings Infrastructure Platform Engineering (IPE) to the forefront by embedding scalable, secure, cost-aware infrastructure into the platform from day one.

Strengths

Infrastructure as a First-Class Concern with built-in multitenancy, isolation, and governance.
Efficiency & Cost Awareness through golden paths and reusable components optimized from the start.
Policy-Driven by Design that enforces security, compliance, and cost policies automatically.
Cloud-Native Ready ideal for ephemeral workloads, Kubernetes, and multi-cloud.

Considerations

Newer Platform with a smaller plugin ecosystem than Backstage’s.
Infra-Heavy Focus that’s best fit for infra-intensive orgs; overpowered if you only need a catalog and docs.

Real-world platform engineering outcomes: Backstage vs Pulumi IDP

Pulumi IDP Adoption: CLEAR leveraged Pulumi IDP’s prebuilt capabilities instead of building infra automation from scratch, speeding up delivery while keeping governance tight.

Backstage vs Pulumi IDP decision guide

When to choose Backstage

Choose Backstage for platform engineering if you:

Have a dedicated platform team with strong React/TypeScript skills
Primarily need service cataloging and documentation
Already have robust infrastructure provisioning and governance tools
Have 18+ months and budget for ongoing maintenance (3-5 FTEs)

When to choose Pulumi IDP

Choose Pulumi IDP for platform engineering if you:

Need infrastructure governance from day one
Want cost management and policy automation built in
Must scale efficiently across Kubernetes and multi-cloud
Prefer to avoid building everything from scratch
Need to deploy quickly (hours vs months)

Build your platform on infrastructure

Pulumi IDP embeds governance, cost control, and security into your platform from day one, giving your teams self-service golden paths with policy enforced automatically.

Get started

The shift to infrastructure platform engineering (IPE)

Platform engineering isn’t failing because the idea is flawed. It’s failing because too many efforts start with the portal and leave infrastructure for later.

Infrastructure Platform Engineering flips that model, ensuring the platform’s foundation is:

Hybrid approaches are also possible. Pulumi offers a Backstage plugin so teams can pair Backstage’s portal features with Pulumi IDP’s infrastructure power.

Bottom line: infrastructure-first wins for platform engineering

If your platform is slow, costly, or hard to govern, it’s not a developer problem. It’s an infrastructure problem. Treating infrastructure as a first-class concern from day one isn’t optional. It’s the difference between a platform that scales and one that stalls.

Frequently asked questions

What is the main difference between Backstage and Pulumi IDP?

Backstage is a portal-first developer platform that focuses on service catalogs and documentation, requiring separate tools for infrastructure provisioning. Pulumi IDP is an infrastructure-first platform that embeds governance, cost control, and infrastructure automation from the start.

How long does it take to implement Backstage vs Pulumi IDP?

Backstage typically requires 12-18 months for full implementation with ongoing maintenance by 3-5 FTEs. Pulumi IDP can be deployed in hours with minimal ongoing maintenance overhead.

Can I use Backstage and Pulumi IDP together?

Yes, Pulumi offers a Backstage plugin that allows teams to combine Backstage’s portal features with Pulumi IDP’s infrastructure capabilities for a hybrid approach.

What are the costs of running Backstage vs Pulumi IDP?

Backstage’s TCO for a 300-developer team can reach multiple millions over three years when factoring in staffing and infrastructure complexity. Pulumi IDP has lower operational costs due to built-in automation and minimal maintenance requirements.

Which platform is better for Kubernetes environments?

Pulumi IDP is purpose-built for cloud-native and Kubernetes environments with built-in support for ephemeral workloads and multi-cloud deployments. Backstage requires additional tooling for Kubernetes infrastructure management.

Learn more about Pulumi IDP and how infrastructure-first platform engineering avoids common failure patterns.