Pulumi Blog: Templates

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.

Build The Best Developer Portal with Pulumi Templates

Meagan Cojocar — Thu, 12 Oct 2023 00:00:00 +0000

At Pulumi, we work with organizations that range from a few platform team members to entire departments for managing infrastructure. Many organizations, like Mercedes-Benz, have built internal developer platforms on top of Pulumi to enable developers to self-serve infrastructure templates, and partners like AWS Proton and Port have built integrations with Pulumi to enable self-service scenarios. We are thrilled to have announced yesterday the launch of our new suite of tools to build internal developer portals with Pulumi, a result of working directly with our customers to understand their problems and how Pulumi can solve it.

Pulumi launched Pulumi Templates last year, out of the box templates based for common architectures, such as serverless templates, container service templates and Kubernetes cluster templates. The introduction of these templates allows Pulumi customers to go from 0 to 1 much quicker, but as they scale their IaC complexity a need for custom templates arises. To address this, we are expending into managing custom templates as a self-service provisioning experience.

Introduction to Developer Portals with Pulumi

Many of our customers are building their own developer portals on top of Pulumi Automation API and Pulumi Deployments, but we also wanted to offer options for teams that cannot (or do not want to) build a custom solution. The suite of tools for building internal developer portals include:

New Project Wizard: Showcased in the GIF above, Pulumi Cloud now enables developers to provision infrastructure entirely via point-and-click in Pulumi Cloud with the new New Project Wizard experience. This offers a great out-of-the box developer portal experience for any team using Pulumi Cloud.
Organization Templates: Pulumi Cloud now supports registering your own custom templates for your organization which will be made available in the New Project Wizard. This enables platform teams to standardize infrastructure creation and distribute those best practices where developers are already spending their time.
Pulumi Backstage Plugin: For teams using Backstage, they can now integrate Pulumi directly within their Backstage instance, via support for a new Pulumi plugin as well as new Pulumi scaffolder actions.
pulumi new support for private templates: By default, pulumi new provides a number of templates provided by Pulumi, but now your organization can also use private templates.

Key Benefits

Ease of Deployment: With this new functionality, you can quickly find and deploy the services you need, reducing the time and complexity of managing your cloud infrastructure. As a developer, if you are looking for a platform team sanctioned way to deploy a Kubernetes cluster, instead of chasing it down you can head to Pulumi Cloud, find the golden template and deploy it.

Enhanced Distribution: As a platform team member, share templates and configurations with your developers to ensure consistency and collaboration across your organization. It’s as simple as adding the template to a repo and selecting that repo in Pulumi Cloud. Now all of your developers have access to it when they go to create new infrastructure.

Combination with Other Features: The new template experience seamlessly integrates with your existing Pulumi workflows, providing a unified experience across your infrastructure management. Increase your developer productivity by using this suite of features in combination with Pulumi ESC. Attach an Environment to your template to have it come with configuration and secret values. Once the templates are deployed they will show in the Pulumi Cloud console use Policies over it, set up Review Stacks on the new stack to get ephemeral environments tied to PRs, find the resources that were deployed with Resource Search, and all the other Pulumi Cloud features.

Extensibility: You can leverage the out of the box New Project Wizard Experience or build developer portals with Pulumi yourself using any combination of: the Pulumi Backstage Plugin, pulumi new public and private templates, Automation API, Pulumi Deployments, or the Pulumi Cloud REST API.

Getting Started

New Project Wizard

The New Project Wizard allows anyone in your organization to pick a template they want to install, create the repo or directory for it, and walk through configuring the deployment of that template. We’ve added support for configuring Pulumi Deployments, meaning any template can be deployed without needing the Pulumi CLI locally, or any other CI/CD configuration. Follow these steps to be up and running with your infrastructure in a few clicks:

You can either 1/ use the UI or 2/ use Deploy with Pulumi buttons. If using the UI, navigate to the “New Project” tab. Select “Use a template” if you’d like to create a fully featured project, or select “Use a starter” if you want to create a bare-bones project with only the minimal necessary boilerplate file structure and Pulumi code. If you are using Deploy with Pulumi buttons, you can embed a button on your templates inside GitHub to enable point-and-click deployment of those templates.
In order to use templates you will need to authorize Pulumi with GitHub so that it can clone private repositories as template sources and commit new code for your projects. Click the “Authorize GitHub” button and accept the required permissions if you would like to use templates.
On the next screen select your deployment method. You may need to install the Pulumi GitHub app if you haven’t already to use Pulumi Deployments.
You’ll now be prompted to enter some information about the project you’re about to create: the project and stack name, the configuration details specific to that template, the repo to use when committing your new project code, and optionally the Environment you want to use. Environments enable you to use a bundle of pre-configured secrets and configuration values without needing to re-specify all of them during project creation.
After you’ve configured your project settings, you will be able to configure the behavior of Deployments, including when to trigger new Deployments and environment variables to include with your updates.

And just like that you have created a new project from a template that is deployed, without the use of the Pulumi CLI.

Organization Templates

Pulumi now allows customers on the Pulumi Cloud Enterprise and Business Critical editions to define Organization Templates to help get projects off the ground faster. A Pulumi organization admin can specify an Organization Template Source (or Sources) which will then be populated in the New Project Wizard experience described above.

Navigate to the “Integrations” tab to define your Organization Templates Source. Enter sources as github.com/<owner>/<repo>/<optional subdirectory>. A source can be a directory containing either a Pulumi.yaml, or other subdirectories with their own Pulumi.yaml files. A single repository can provide multiple templates from various subdirectories. For example, these are both valid sources: github.com/pulumi/templates (all public Pulumi templates) and github.com/pulumi/templates/aws-typescript (a specific public template).

The Pulumi.yaml file can optionally contain a template section, which typically includes a config section for specifying required config values for the project. Each config value can have a description and a default value which can be overridden. Config values can be marked as secret, which ensures values in templated projects will be stored with secure encryption.

name: my-aws-project
runtime: nodejs
description: My AWS project description
template:
 config:
 aws:region:
 description: The AWS region to deploy into
 default: us-west-2
 myAccessToken:
 description: My access token
 secret: true

The above snippet includes an aws:region configuration value with a default value of us-west-2, as well as a myAccessToken secret without a default value.

Pulumi & Backstage

We’ve seen many developer portal technologies rapidly growing in popularity over the last few years. In particular, we’ve seen Pulumi users adopting Backstage and as a result we built the Pulumi Backstage Plugin to address the needs of organizations using Backstage and Pulumi together. There are now two ways to use Pulumi from within Backstage, you can leverage both or just one or the other:

Pulumi Scaffolder Backend Module
Pulumi Backstage Plugin

Pulumi Scaffolder Backend Module: The Pulumi Scaffolder Backend Module extends the scaffolding with two new actions: Pulumi New and Pulumi Up. The Pulumi New action is a custom action that allows you to create a new Pulumi project from a template using the pulumi new Pulumi CLI command. The Pulumi Up Action is a custom action that allows you to run the pulumi up command, which creates or updates resources in a stack.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: kubernetes-template
 title: Kubernetes Cluster
 description: |
 A template for creating a new Kubernetes Cluster.
 tags:
 - pulumi
 - kubernetes
spec:
 steps:
 - id: pulumi-new-component
 name: Cookie cut the component Pulumi project
 action: pulumi:new
 input:
 name: "${{ parameters.component_id }}-infrastructure"
 description: ${{ parameters.description | dump }}
 organization: ediri
 stack: ${{ parameters.stack }}
 template: "https://github.com/my-silly-organisation/microservice-civo/tree/main/infrastructure-${{ parameters.cloud }}-${{ parameters.language }}"
 config:
 "node:node_count": "${{ parameters.nodeCount }}"
 folder: .

With a few clicks, developers can create new software projects provisioned with best practices, with code managed in the right repositories, and with the right configurations, all from a self-service UI.

Pulumi Backstage Plugin: Backstage Plugins are extensions or add-ons to the core Backstage application that allow you to integrate additional tools, services, and functionalities into the platform, enhancing its capabilities and customizing it to meet the specific needs of your development environment.

The Pulumi Backstage Plugin extends Backstage by displaying essential details like the Pulumi stack, organization, project name, and description, as well as providing an activity view with aggregated information from the Pulumi Cloud. See a screenshot of the new Pulumi tab within Backstage below:

Check out the Pulumi Backstage Plugin in the Backstage Plugin directory or the Roadie Pulumi Backstage Plugin guide to get started today.

Wrapping it up

The launch of this new functionality for internal developer portals marks a significant step forward in our commitment to providing powerful, turn-key tools for platform teams. We believe these features will enhance your experience with Pulumi, whether you’re a seasoned cloud expert leading a team of platform engineers or just getting started on your IaC journey.

As always, we welcome your feedback in the Pulumi Cloud Requests repository and are here to support you every step of the way on your platform engineering journey.

Pulumi for Platform Teams: New Features for Developer Portals, Policy and Deployments

Luke Hoban — Wed, 11 Oct 2023 04:00:00 -0700

Over the last two years, we’ve seen a huge surge in adoption of Pulumi by Platform Teams – centralized teams within a business responsible for building out core cloud infrastructure and providing tools to the rest of the organization to maximize the productivity, cost efficacy, compliance and velocity of application and service delivery throughout the organization. These teams use Pulumi to manage their own cloud infrastructure complexity, to offer best practices components to their organizations, to enforce organizational policy, and to drive infrastructure delivery automation.

Today, we’re excited to announce a broad range of new features that extend Pulumi Cloud’s support for Platform Teams, across the entire lifecycle of cloud delivery.

Developer Portals: Every platform team we work with is looking to expose reusable cloud infrastructure components and templates via a developer portal of some kind. Many are building their own custom developer portals on top of Pulumi Automation API and Pulumi Deployments, but we also wanted to offer options for teams that cannot (or do not want to) build a custom solution. Today, we are releasing three new options for Platform Teams:

🆕 Organization Templates and New Project Wizard: Pulumi Cloud now supports registering your own custom templates for your organization, and enabling developers in your organization to provision them entirely via point-and-click in Pulumi Cloud with the new New Project Wizard. This offers a great out-of-the box developer portal experience for any team using Pulumi Cloud.
🆕 Pulumi Backstage Plugin: For teams using Backstage, they can now integrate Pulumi directly within their Backstage instance, via support for a new Pulumi plugin as well as new Pulumi scaffolder actions.
🆕 pulumi new support for private templates: By default, pulumi new provides a number of templates provided by Pulumi, but it can also use your own private templates.

Policy and Compliance: Platform teams need robust and flexible solutions for establishing policy and compliance guardrails for their cloud infrastructure. Pulumi’s existing CrossGuard policy-as-code framework provides the richest option for defining and enforcing policy across all infrastructure in an organization, using the full capabilities of your favorite languages. Today, we are extending that support with two important new features for platform teams:

🆕 Compliance Ready Policies: New pre-built policy packs for for enforcing common security and compliance policies (PCI DSS, ISO 27001 and CIS) across a broad range of cloud providers (AWS, Azure, Google Cloud and Kubernetes), and dozens of services within each platform.
🆕 Remediation Policies: Pulumi Policy as Code now supports authoring policies which don’t just warn or error, but actually change the infrastructure directly to remediate compliance gaps. Remediation policies can be configured and applied across any subset of stacks within an organization.

Deployments and Delivery: Managing the delivery of cloud infrastructure changes across a wide variety of environments is an essential component of a cloud platform, and we released Pulumi Deployments in preview last year to provide a rich solution for infrastructure delivery directly within Pulumi Cloud. Today, we are making that support Generally Available (GA) along with a few key enhancements:

🆕 Deployments GA: Pulumi Deployments is now generally available, with pricing and support available across all Pulumi Cloud editions.
🆕 Deployments Support for GitHub Enterprise: Pulumi Deployments now supports integration with GitHub Enterprise as well as GitHub.com.
🆕 Org-Wide Deployments Overview Page: A new page where you can see all deployments across the organization, giving you a single pane of glass to manage company wide deployments.
🔜 Deployments Customer Managed Agents: Customers will soon be able to run deployments inside agents they run within their own infrastructure, for cases where this is required for unique compliance or security reasons.

Together with Pulumi ESC (Environments, Secrets and Configuration) which we announced yesterday, and the core Pulumi IaC infrastructure as code platform, these new features provide a rich collection of building blocks and out of the box experiences for empowering platform teams via Pulumi Cloud. At every layer of the Platform Engineering stack, Pulumi and Pulumi Cloud offer key technologies to accelerate your Platform Engineering projects.

Organization Templates and New Project Wizard

We’ve introduced a new wizard experience to create Pulumi projects into Pulumi Cloud, making it easier than ever to get started deploying new infrastructure with Pulumi.

The new project wizard allows anyone in your organization to pick a template they want to install, and walk through configuring the deployment of that template. We’ve added support for configuring Pulumi Deployments automatically, so that the template can be deployed without needing the Pulumi CLI locally, or any other CI/CD configuration. Just a few clicks and you have deployed your infrastructure.

We’ve also added integration with the newly released Pulumi ESC so that you can set up environments (and the configuration and credentials needed to deploy to them) that users within your organization can deploy into, determine who can use which environments using RBAC, and then allow those users to deploy templates directly into the environments they can access – no need to copy secrets, credentials or configuration around!

We’ve also added the ability for organizations to provide their own custom set of Organization Templates — templates specific to their organization, which can live in either public or private Git repositories. The Organization Template Source provided will populate the templates that are displayed to members in the New Project wizard experience.

Together, Organization Templates and the new New Project Wizard offer a foundational developer portal experience directly within the Pulumi Cloud console. Users can come to Pulumi Cloud, select one of the pre-defined templates set up by their Platform Team, and then in a few clicks have it deployed into a predefined cloud environment.

The New Project wizard is available now for all Pulumi users, and Organization Templates are available to Pulumi Enterprise and Business Critical users. Check out the documentation to get started.

Backstage Plugin

We’ve seen many developer portal technologies rapidly growing in popularity over the last few years. In particular, we’ve seen many Pulumi users adopting Backstage. Last week we launched a new Pulumi Backstage Plugin to address the needs of organizations using Backstage and Pulumi together.

The new Pulumi tab gives you direct access to all Pulumi stack activity associated with your backstage projects that include Pulumi stacks.

The Pulumi Backstage Plugin also supports two new scaffolding actions, pulumi:new and pulumi:up, which can be used to template out new Pulumi projects and to trigger updates to Pulumi stacks, fully integrated into the Backstage scaffolding system.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: kubernetes-template
 title: Kubernetes Cluster
 description: |
 A template for creating a new Kubernetes Cluster.
 tags:
 - pulumi
 - kubernetes
spec:
 steps:
 - id: pulumi-new-component
 name: Cookie cut the component Pulumi project
 action: pulumi:new
 input:
 name: "${{ parameters.component_id }}-infrastructure"
 description: ${{ parameters.description | dump }}
 organization: ediri
 stack: ${{ parameters.stack }}
 template: "https://github.com/my-silly-organisation/microservice-civo/tree/main/infrastructure-${{ parameters.cloud }}-${{ parameters.language }}"
 config:
 "node:node_count": "${{ parameters.nodeCount }}"
 folder: .

Check out the Pulumi Backstage Plugin in the Backstage Plugin directory or the Roadie Pulumi Backstage Plugin guide to get started today.

Compliance Ready Policies

We first released our CrossGuard policy-as-code framework nearly 4 years ago, and have seen many large organizations leverage its rich expressiveness, flexibility and early prevention features to enforce key compliance criteria for their organization. Support in Pulumi Cloud for automatically enforcing these policies across all Pulumi updates within an organization allows platform teams to put compliance guardrails in place for users within their organization.

However, traditionally each organization has needed to build their own policies, resulting in some activation energy needed to start benefiting from CrossGuard. As we’ve worked with many customers to build out their own internal compliance policies using CrossGuard, we’ve identified some common compliance standards and policies that we can offer directly as part of CrossGuard.

Today, we are making a large collection of new policies available for CrossGuard users. These policies support many common compliance standards (PCI DSS, ISO 27001 and CIS) across a broad range of cloud providers (AWS, Azure, Google Cloud and Kubernetes), and dozens of services within each platform.

These policies are offered as a library, from which Platform Teams can enable the subset they want to apply. For example:

import { PolicyPack } from "@pulumi/policy";
import { policyManager } from "@pulumi/compliance-policy-manager";

new PolicyPack("aws-iso27001-compliance-ready-policies-typescript", {
 policies:[
 ...policyManager.selectPolicies({
 vendors: ["aws"],
 services: ["ec2", "eks"],
 severities: ["critical", "high"],
 frameworks: ["iso27001"]
 }, "advisory"),
 ],
});

The new Policy Pack wizard also makes it easier than ever to create a new policy pack from the compliance-ready policies, and enable it within your organization.

Check out the documentation and open source repository to get started with Compliance-Ready Policies today.

Remediation Policies

Existing CrossGuard policies have always had the ability to be set to Advisory to emit a warning when they fail, or to Mandatory to prevent the Pulumi deployment from completing when they fail. This enables strict prevention of non-compliant infrastructure deployments before they even get into production.

However, in many cases, it’s clear what change needs to be made to the infrastructure to make it compliant. Today, we’ve launched new support in CrossGuard for Remediation Policies, a new kind of policy which actually fixes up the infrastructure to be compliant instead of just warning or erroring!

This is a magical experience for both policy authors and infrastructure engineers.

const s3NoPublicRead: ResourceValidationPolicy = {
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "remediate",
 remediateResource: remediateResourceOfType(aws.s3.Bucket, (bucket, args) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 // Modify the ACL and return the new bucket state to use instead.
 bucket.acl = "private";
 return bucket;
 }
 }),
};

def s3_no_public_read_remediator(args: ResourceValidationArgs):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 # Modify the ACL and return the new bucket state to use instead.
 args.props["acl"] = "private
 return args.props

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcement_level=EnforcementLevel.REMEDIATE,
 remediate=s3_no_public_read_remediator,
)

Check out the documentation to get started adding remediation policies to your policy-as-code configuration today.

Deployments GA

In the last year since we launched Pulumi Deployments in preview, we’ve seen incredible growth in usage and scale of Pulumi Deployments across the Pulumi user base. Customers use Pulumi Deployments for a single built-for-purpose CI/CD solution for their Pulumi infrastructure delivery, but also leverage rich API-driven deployments, Review Stacks, Click-to-Deploy within the Pulumi Cloud Console, and much more.

As part of General Availability, we are announcing pricing for deployments at $0.01 per deployment minute. The new pricing will be effective November 1st. Individual Edition users get 500 minutes free per month, and Team Edition users get 3,000 minutes free per month. Full details of the pricing can be found on the Pricing Page.

In addition to pricing, we’re making available several new features in the Deployments platform.

The new Deployments pane in the Pulumi Cloud console provides a unified view across all deployments in your organization. This includes in progress and queued deployments so that you can easily access any currently in flight deployments, as well as a full history of all deployments performed across all stacks you have access to within your organization.

And finally, we’re extending Pulumi Deployments to support additional key enterprise needs. We recently added support for connecting Pulumi Deployments to GitHub Enterprise, and we will be delivering support for self-hosted Pulumi Deployments agents which can be run within your own infrastructure later this month. You can fill out this form to register for the private preview of self-hosted agents today.

Conclusion

Pulumi Cloud offers a rich and broad platform to support any platform team today. Across the entire lifecycle of cloud infrastructure and application delivery, Pulumi Cloud supports platform teams in building cloud platforms for their organizations which empower developers via rich IaC components and developer portals, enable seamless delivery through Deployments and Automation API, provide robust compliance guardrails through Compliance-Ready Policies and Remediation Policies, and securely manage secrets and configuration across a variety of environments with Pulumi ESC.

It’s never been easier to build your internal developer platform with the help of Pulumi Cloud.

How to Create and Share a Pulumi Template

Christian Nunciato — Mon, 12 Dec 2022 00:00:00 +0000

Last month, we released our first set of architecture templates — configurable Pulumi projects designed to make it easy to bootstrap new stacks for common cloud architectures like static websites, containers, virtual machines, and Kubernetes clusters. Architecture templates are a great way to get a new project up and running quickly, and they’ve already grown quite popular with our users, several of whom have asked if whether it’s possible to create templates of their own.

It’s not only possible, it’s surprisingly easy! So in this post, I’ll show you how. It all starts with a Pulumi project — a template is really just a Pulumi project with a few extra lines of config — so we’ll start with one of those, add a few resources, and turn the project into a template. When it’s ready to go, we’ll test it out locally, and then finally, we’ll publish it so that anyone with Pulumi can use our template to kickstart their own projects.

We’ll do this in five steps:

Create a new project
Design and build the program
Turn the project into a template
Test-drive the template locally
Publish the template to share it with the world

Let’s get to it.

Step 1: Create a new project

If you haven’t already, make sure you’ve installed Pulumi and configured your AWS credentials. For this example, we’ll be using AWS, but the process is the same for any cloud provider, so if you aren’t set up on AWS, you should still be able to follow along anyway.

Create a new project in the usual way using one of our starter templates. The YAML template is a good choice for this walkthrough, as YAML projects are simple and lightweight (no runtime dependencies!), and because they combine both project and program into one file, they’re especially conducive to sharing:

$ mkdir my-template-project && cd my-template-project
$ pulumi new aws-yaml

Step through the prompts, choosing whichever AWS region works best for you. When the new-project wizard finishes, open the generated Pulumi.yaml project file in your editor of choice to start building.

Step 2: Design and build the program

I’m a static-website person, myself — I think pretty much everyone should have one. So in order to realize my grand vision of home page for every human, you and I are going to build a Pulumi project template that lets anyone with the Pulumi CLI deploy a super-simple website of their own on AWS.

As Pulumi template authors, our general goal is twofold:

Make it easy for our users to create deployable projects that address an infrastructural need.
Make it easy to customize and extend those projects after they’ve been created.

A good template, in other words, is one that not only takes you from pulumi new to pulumi up in as few steps as possible, but that also leaves you with an open, extensible program you can use as a foundation to build upon. For us, the goal is to create a template that can be used to provision the minimal set of cloud resources one needs to run a static website on AWS. And done well, our template will also lend itself easily to further development — custom domains, serverless functions, edge caching, and so on.

To that end, let’s start by replacing the contents of Pulumi.yaml with the following program, which defines the core resources we need: an S3 bucket to hold the files of the website and an S3 bucket object (index.html) to serve as its home page. We’ll also export the computed URL of the website as a Pulumi stack output to give us something to navigate to after deployment:

name: my-template-project
description: A simple static website on Amazon S3
runtime: yaml
resources:

 # Create an S3 bucket and configure it as a website.
 bucket:
 type: aws:s3:Bucket
 properties:
 acl: public-read
 website:
 indexDocument: index.html

 # Create a home page for the website.
 index.html:
 type: aws:s3:BucketObject
 properties:
 bucket: ${bucket.id}
 acl: public-read
 contentType: text/html
 content: |
 <html>
 <meta name="content" charset="utf-8">
 <title>My Awesome Website</title>
 <body>
 <h1>My Awesome Website</h1>
 <p>Hello, internet person! 👋</p>
 </body>
 </html>

# Export the URL of the website.
outputs:
 url: http://${bucket.websiteEndpoint}

Try running this program now, just to make sure everything works. In a few seconds, you should see that the new resources were created and be able to browse to the new website at the exported url:

$ pulumi up
...
Updating (dev)
Type Name Status
+ pulumi:pulumi:Stack my-s3-website-template-dev created (3s)
+ ├─ aws:s3:Bucket bucket created (2s)
+ └─ aws:s3:BucketObject index.html created (0.37s)
Outputs:
url: "http://bucket-f1bb181.s3-website-us-west-2.amazonaws.com"
Resources:
+ 3 created
Duration: 5s

Good — we have a working program. And looking back at our design goals, you’ll see that this program already meets them pretty well:

It works out of the box. Deployed now, it produces a running website on AWS.
It’s open and extensible. To build onto it — add more pages, attach a custom domain, etc. — you’d simply add more resources alongside those already defined.

Now let’s turn this program into a template.

Before moving on, though, let’s quickly destroy and remove this stack, as we’ll be making a few changes to the project’s settings in the next step, and it’d be better to begin from a clean slate:

$ pulumi destroy --yes --remove

Step 3: Turn the project into a template

The next thing to do is decide which parts of the program should be configurable. Earlier, when you ran pulumi new aws-yaml, you probably noticed you were prompted for an optional AWS region:

$ pulumi new aws-yaml
...
This command will walk you through creating a new Pulumi project.
...
aws:region: The AWS region to deploy into: (us-west-2)

You got this prompt because the authors of the aws-yaml template knew that not every user would want to deploy into the same hard-coded AWS region, so they defined an aws:region setting to make it both configurable and optional, falling back to us-west-2 by default. Users of this template are free to change this value if they like or leave it alone and accept the default.

This is all made possible by the existence of the template block in Pulumi.yaml:

# The `template` block from the aws-yaml template.
template:
 description: A minimal AWS Pulumi YAML program
 config:
 aws:region:
 description: The AWS region to deploy into
 default: us-west-2

Indeed, this block is all that defines aws-yaml as a template; without it, the aws-yaml project would be a regular ol’ Pulumi YAML program like any other.

The template block defines two properties:

An optional description property to give new projects created from the template
A config block that lists the names, descriptions, and default values of any settings that should be configurable for new projects

The template block is essentially where all the new-project magic happens. Any settings you define in this block will prompt users for their values and apply those settings to the project’s initial stack (for example, the dev stack we created in Step 1). By default, these values are captured and applied as plain-text strings, but you can also capture them as encrypted Pulumi secrets by adding secret: true — an appropriate choice for prompting for sensitive data like passwords, API keys, and the like.

Our super-simple website template doesn’t need much in the way of configurability — but let’s define some anyway just to see how it’s done. While we’re at it, we’ll make a few adjustments to make project names and descriptions configurable as well.

Make the changes below to Pulumi.yaml to use the project name and description supplied by the CLI, add a template section to let users configure a home-page title and greeting, and interpolate those values into the body of the home page itself. Here’s the full content of the program for reference:

# Configure project names and descriptions with values obtained from `pulumi new`.
name: ${PROJECT}
description: ${DESCRIPTION}
runtime: yaml

# Define the template's configuration settings.
template:
 description: A simple static website on Amazon S3
 config:
 aws:region:
 description: The AWS region to deploy into
 default: us-west-2
 title:
 description: A title to use for the home page
 default: My Awesome Website
 greeting:
 description: A greeting to show on the home page
 default: Hello, internet person! 👋

resources:

 # Create an S3 bucket and configure it as a website.
 bucket:
 type: aws:s3:Bucket
 properties:
 acl: public-read
 website:
 indexDocument: index.html

 # Create a home page for the website.
 index.html:
 type: aws:s3:BucketObject
 properties:
 bucket: ${bucket.id}
 acl: public-read
 contentType: text/html
 content: |
 <html>
 <meta name="content" charset="utf-8">
 <title>${title}</title>
 <body>
 <h1>${title}</h1>
 <p>${greeting}</p>
 </body>
 </html>

# Export the URL of the website.
outputs:
 url: http://${bucket.websiteEndpoint}

That’s all there is to it! The template’s complete and ready to be published. However, before we do that, let’s first give it a try locally just to make sure it delivers the new-project experience we’re looking for.

Step 4: Test-drive the template locally

Back in your terminal (and assuming you’re still in the my-template-project folder), create a new folder alongside my-template-project, then run pulumi new to create a new project, pointing Pulumi to the folder containing your template:

$ cd ..
$ mkdir my-test-website && cd my-test-website
$ pulumi new ../my-template-project

Step through the prompts, which should include each of the configurable settings we defined in the template block earlier, along with their default values:

$ pulumi new ./my-template-project
project name: (my-test-website)
project description: (A simple static website on Amazon S3)
...
aws:region: The AWS region to deploy into: (us-west-2)
greeting: A greeting to show on the home page: (Hello, internet person! 👋) Hi, world!
title: A title to use for the home page: (My Awesome Website) Hey look, it's my website!
Your new project is ready to go! ✨
To perform an initial deployment, run `pulumi up`

Go ahead and deploy the new project with pulumi up, then navigate to the newly deployed website in your favorite web browser:

$ pulumi up --yes
$ open $(pulumi stack output url)

Well done! You’ve written your first Pulumi template.

Let’s finish things off by publishing your template so others can use it. As before, tidy up with pulumi destroy before moving on:

$ pulumi destroy --yes --remove

Step 5: Publish the template

A moment ago, when you tested your first template, you did so by pointing Pulumi to the template’s path on your local filesystem. Before that, when you ran pulumi new aws-yaml, you instructed Pulumi (implicitly) to fetch the source of the template over HTTPS from the official pulumi/templates repository on GitHub. So to make your template available to others, all you have to do publish it to a file path or Git URL that’s accessible by the Pulumi CLI.

You could create a new GitHub repository for this project, then pass the fully-qualified URL of the path containing Pulumi.yaml to pulumi new, like so:

$ pulumi new https://github.com/{your-org}/{your-repo}/tree/main

But since our project consists of just one file, you don’t even need to do that much: you can just paste the contents of the file into a new GitHub gist (since a gist is also a Git repository), name the gist Pulumi.yaml, and point Pulumi to the gist’s URL.

Go ahead and create a gist of your own, then use it to create a new project:

$ mkdir ../my-second-test-website && cd ../my-second-test-website
$ pulumi new https://gist.github.com/cnunciato/b331efae6a4740c237a0364d17fe220f
$ pulumi up

Be sure to tidy up as before with pulumi destroy when you’re done.

Bonus step: Add a Deploy with Pulumi button

In addition to the CLI, your users can also create new projects in the Pulumi Service with the Deploy with Pulumi button. This is a great option for making your project installable from GitHub READMEs and other team docs. Here, for example, is a Deploy button that creates a new project using my version of the gist we created above:

Embedding these buttons yourself is easy — just use one of the snippets below, swapping the values of {template-url} for the URL of your template’s gist or Git repository:

<a href="https://app.pulumi.com/new?template={template-url}">
 <img src="/images/deploy-with-pulumi/dark.svg" title="Deploy with Pulumi">
</a>

[![Deploy with Pulumi](/images/deploy-with-pulumi/dark.svg)](https://app.pulumi.com/new?template={template-url})

Project creators who go down this path will be prompted in the browser for the same configuration values as they would with the CLI, and afterward, they’ll be able to deploy the project either with the Pulumi CLI or with Pulumi Deployments.

See it in action

You can watch this Modern Infrastructure video to see another example of creating and sharing a Pulumi template:

Wrapping up

As you can see, creating a template is both simple and powerful, and I hope this post encourages you to experiment with a few of your own. Feel free to peruse the following links for inspiration:

And as always, be sure to stop by Pulumi Community Slack to let us know know how it goes.

Happy templating!

Using Kubernetes Arch Templates with Poetry and Python

Laura Santamaria — Wed, 07 Dec 2022 00:00:00 +0000

When building with Kubernetes for the first time, we often need to stand up a lot of infrastructure just to get to the point of having a base to build an application. Let’s explore how we can wire together two of our architecture templates to generate a base for a web application running on Kubernetes on Google Cloud with Python and Poetry.

A primer on microservices

To work with Kubernetes, you’re generally following a microservices architecture. In short, here’s how to think about a microservices architecture: Each logical component of your application is its own individual process acting as a closed box that defines what data must come in and what data is delivered on the other end—what’s known as a service. Services communicate with one another via APIs or similar small interfaces, and each service addresses one part of your business logic inside your application.

In a typical, very basic web application set up in a generic microservices architecture, you might have a data store, a backend, and a frontend (a user interface, or UI). In practice, you might have multiple backends and data stores to address multiple activities like logging in, running a shopping cart, delivering shipping updates, and more.

To ensure all of these services work together, an orchestrator like Kubernetes ensures each service is running and healthy, is connected to the others, and runs as expected.

A typical Kubernetes architecture

A Kubernetes cluster is a collection of one or more machines (either virtual or bare-metal) called nodes that host groups of containers, with each group containing multiple copies of a microservice. These groups of containers are called pods. And then, to connect and expose those pods to one another and the world, we add in services.

For our system that we’ll build today, we’re going to have a cluster running on Google Kubernetes Engine (GKE). We’ll create a namespace on that Kubernetes instance, which will hold all of our Kubernetes app resources. We’ll have a deployment that takes the configuration we need for NGINX (a ConfigMap) and spins up a pod holding the containers running that NGINX server. Then, we’ll have a service that exposes the ports so we can access our NGINX server from anywhere.

Start with templates

We’re going to build our entire architecture starting with two templates: Our GKE template and our Kubernetes web app template. Learn more about our new architecture templates.

This will be a bit different than our usual workflow. Generally, we here at Pulumi prefer to stand up different stacks for each type of infrastructure (so one project with one or more stacks for the Kubernetes cluster and then one project with one or more stacks for the web application). However, in this case, let’s explore together what happens if we’re want to have it all go up together as one project and stack while keeping the code in different files.

First, create a new directory to hold all of our project files, and add app and infra directories inside this root directory.

$ mkdir k8s-templates && cd k8s-templates
$ mkdir app
$ mkdir infra

In the infra directory, we’ll add the GKE template first. We’re using the --generate-only flag to avoid creating the default virtual environment and the various extra stack information since we’re using Poetry and will be running everything from the root directory later:

$ cd infra
$ pulumi new kubernetes-gcp-python --generate-only

Accept all of the standard default values, except give your Google Cloud project name here instead of the default.

In the app directory, we’ll add the web app template:

$ cd ../app
$ pulumi new webapp-kubernetes-python --generate-only

When it asks you for a project name in the app directory, give it the name app-mi-k8s. Otherwise, accept all of the default values (using your Google Cloud details).

And now, the real fun begins!

Putting it all together

We’re going to use Poetry instead of the default virtual environment as we’re going to be working in a number of different directories that all need the same virtual environment and dependencies. In the root of the project, let’s initialize a Poetry project. We’ll need to define all of the dependencies from the application and infrastructure requirements:

$ cd ../ # if you need to go back to your project root
$ poetry init
# In the dynamic generation of dependencies, add pulumi, pulumi-gcp, and pulumi-kubernetes.
# Otherwise, fill in the other pieces as you would normally.

Then install the dependencies:

$ poetry install

Now, we can pull the metadata file for Pulumi in:

$ touch Pulumi.yaml
$ cat infra/Pulumi.yaml > Pulumi.yaml
$ touch Pulumi.dev.yaml

And do a quick cleanup of the Pulumi.dev.yaml file:

<root>/Pulumi.dev.yaml

config:
 namespace: fake-ns
 replicas: 1
 gcp:project: <your-project>
 gcp:region: <your-region>

Since we’re running on GKE, we need to define a different namespace than default. I used fake-ns.

We’ll need to modify the Pulumi.yaml file to remove the virtual environment:

<root>/Pulumi.yaml

name: k8s-combo-infra
description: A Python program to deploy a Kubernetes cluster and application on Google Cloud
runtime: python

And now we can set up our new __main__.py file! Create a new __main__.py file in the root of the repo, and add this code:

<root>/main.py

from pulumi import export as pulumi_export
from pulumi import Output
import app.__main__ as app
import infra.__main__ as infra_code

infra = infra_code

kubeconf = infra.cluster_kubeconfig
app_infra = kubeconf.apply(
 lambda val: app.create_app(kubeconfig_val=val)
)

pulumi_export("endpoint_url", Output.unsecret(app_infra))

We do need to make a couple small changes to the app/__main__.py file. We need to

wrap the code in a callable function so we can use that apply() call in the root file,
add a custom provider to use the right kubeconfig settings,
pass that provider context to all of the resources, and
get the endpoint from our app:

<root>/app/main.py

import pulumi
import pulumi_kubernetes as kubernetes


def create_app(kubeconfig_val):
 # Get some values from the Pulumi stack configuration, or use defaults
 config = pulumi.Config()
 k8s_namespace = config.get("namespace", "default")
 num_replicas = config.get_float("replicas", 1)
 app_labels = {
 "app": "nginx",
 }

 # NEW: Create a provider that consumes the upstream kubeconfig
 new_provider = kubernetes.Provider(
 "app_provider",
 kubeconfig=kubeconfig_val,
 namespace=k8s_namespace
 )

 # Create a namespace
 webserverns = kubernetes.core.v1.Namespace(
 "webserver",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 name=k8s_namespace,
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Create a ConfigMap for the Nginx configuration
 webserverconfig = kubernetes.core.v1.ConfigMap(
 "webserverconfig",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 data={
 "nginx.conf": """events { }
 http {
 server {
 listen 80;
 root /usr/share/nginx/html;
 index index.html index.htm index.nginx-debian.html
 server_name _;
 location / {
 try_files $uri $uri/ =404;
 }
 }
 }
 """,
 },
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Create a Deployment with a user-defined number of replicas
 webserverdeployment = kubernetes.apps.v1.Deployment(
 "webserverdeployment",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 spec=kubernetes.apps.v1.DeploymentSpecArgs(
 selector=kubernetes.meta.v1.LabelSelectorArgs(
 match_labels=app_labels,
 ),
 replicas=num_replicas,
 template=kubernetes.core.v1.PodTemplateSpecArgs(
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 labels=app_labels,
 ),
 spec=kubernetes.core.v1.PodSpecArgs(
 containers=[kubernetes.core.v1.ContainerArgs(
 image="nginx",
 name="nginx",
 volume_mounts=[kubernetes.core.v1.VolumeMountArgs(
 mount_path="/etc/nginx/nginx.conf",
 name="nginx-conf-volume",
 read_only=True,
 sub_path="nginx.conf",
 )],
 )],
 volumes=[kubernetes.core.v1.VolumeArgs(
 config_map=kubernetes.core.v1.ConfigMapVolumeSourceArgs(
 items=[kubernetes.core.v1.KeyToPathArgs(
 key="nginx.conf",
 path="nginx.conf",
 )],
 name=webserverconfig.metadata.name,
 ),
 name="nginx-conf-volume",
 )],
 ),
 ),
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Expose the Deployment as a Kubernetes Service
 webserverservice = kubernetes.core.v1.Service(
 "webserverservice",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 namespace=webserverns.metadata.name,
 ),
 spec=kubernetes.core.v1.ServiceSpecArgs(
 ports=[kubernetes.core.v1.ServicePortArgs(
 port=80,
 target_port=80,
 protocol="TCP",
 )],
 selector=app_labels,
 type="LoadBalancer"
 ),
 opts=pulumi.ResourceOptions(provider=new_provider)
 )

 # Export some values for use elsewhere
 pulumi.export("deploymentName", webserverdeployment.metadata.name)
 pulumi.export("serviceName", webserverservice.metadata.name)
 return webserverservice.status.apply(lambda val: val.load_balancer.ingress[0].ip)

Now that all our changes have been made, let’s try running it! We’ll need to prepend poetry run to the commands, unless you choose to switch to the Poetry shell ahead of time:

$ poetry run pulumi stack init dev
$ poetry run pulumi stack select dev
$ poetry run pulumi up

And up they all go! Note that this takes a while, so don’t panic!

output

Previewing update (dev)

View Live: https://app.pulumi.com/nimbinatus/k8s-combo-infra/dev/previews/fe73460a-a846-475c-9a69-23626e56b4e4

 Type Name Plan
 + pulumi:pulumi:Stack k8s-combo-infra-dev create
 + ├─ gcp:compute:Network gke-network create
 + ├─ gcp:compute:Subnetwork gke-subnet create
 + ├─ gcp:container:Cluster gke-cluster create
 + ├─ gcp:serviceAccount:Account gke-nodepool-sa create
 + └─ gcp:container:NodePool gke-nodepool create


Outputs:
 clusterId : output<string>
 clusterName : "gke-cluster-dd00d9f"
 endpoint_url: output<string>
 kubeconfig : output<string>
 networkId : output<string>
 networkName : "gke-network-e0ce7fb"

Resources:
 + 6 to create

Do you want to perform this update? yes
Updating (dev)

View Live: https://app.pulumi.com/nimbinatus/k8s-combo-infra/dev/updates/109

 Type Name Status
 + pulumi:pulumi:Stack k8s-combo-infra-dev created (915s)
 + ├─ gcp:compute:Network gke-network created (21s)
 + ├─ gcp:compute:Subnetwork gke-subnet created (11s)
 + ├─ gcp:container:Cluster gke-cluster created (682s)
 + ├─ pulumi:providers:kubernetes app_provider created (0.17s)
 + ├─ gcp:serviceAccount:Account gke-nodepool-sa created (1s)
 + ├─ kubernetes:core/v1:Namespace webserver created (0.52s)
 + ├─ gcp:container:NodePool gke-nodepool created (125s)
 + ├─ kubernetes:core/v1:ConfigMap webserverconfig created (0.32s)
 + ├─ kubernetes:core/v1:Service webserverservice created (193s)
 + └─ kubernetes:apps/v1:Deployment webserverdeployment created (144s)


Outputs:
 clusterId : "projects/pulumi-development/locations/us-central1/clusters/gke-cluster-6cc9507"
 clusterName : "gke-cluster-6cc9507"
 endpoint_url: "35.224.177.197"
 kubeconfig : [secret]
 networkId : "projects/pulumi-development/global/networks/gke-network-68b9493"
 networkName : "gke-network-68b9493"

Resources:
 + 11 created

Duration: 15m17s

If you CURL the endpoint, you get the default NGINX page that tells us the webserver is ready to go:

$ curl $(pulumi stack output endpoint_url)
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Finally, if you’re done with the cluster, don’t forget to pull it down so you don’t get charged!

$ poetry run pulumi destroy -y

If you run into an issue where the cluster gets deleted before the various app resources (the namespace, the service, etc.) get removed, you may get an error that you can’t finish destroying the stack. Because the cluster is already gone, the Kubernetes provider can’t access it to update the status of the various app resources. So you’ll need to remove those resources from your state file as they were removed with the deletion of the cluster:

$ poetry run pulumi state delete urn:pulumi:dev::k8s-combo-infra::kubernetes:core/v1:Namespace::webserver --target-dependents

Then, refresh and destroy the rest of the resources, including the outputs:

$ poetry run pulumi refresh -y
$ poetry run pulumi destroy -y

If you want to try this out, head over to this example repo to explore the code and pull it down to run yourself. Don’t forget to create a Pulumi account first!

If you want to explore the other templates we have available for you, head to our templates page to explore.

Serverless Arch Templates

Kat Cosgrove — Mon, 07 Nov 2022 00:00:00 +0000

Whether you’re building a new application or moving an existing application over from another provider, the basic framework of your infrastructure probably isn’t something you want to worry about if you don’t have to. The cloud is complicated enough as it is. With Architecture Templates, Pulumi takes on some of the work involved in deploying your application to the cloud provider of your choice. Let’s take a tour of the new Serverless Templates for AWS, GCP, and Azure!

Serverless on any Cloud, in any Language

If you need a serverless application, whether that’s AWS Lambda, Google Cloud Functions, or Azure Functions, one of these templates can give you the starting point you need in any language Pulumi supports. Each template deploys a serverless function for you, with all necessary permissions to make it publicly available. While each of them does deploy a small sample function, these are designed to be extensible; we give you all the necessary tools to begin building your own application, without having to fuss around standing up the infrastructure yourself.

Generating the necessary starter code happens with a single CLI command, regardless of which cloud and language you choose:

AWS

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-yaml

GCP

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-yaml

Azure

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-yaml

Pulumi to the Cloud

Each of these commands will generate some boilerplate for you, and includes defaults you can accept or modify (such as the name of the project, or the application directory). Run pulumi up from this directory, ensuring that you’ve connected the Pulumi CLI to your preferred cloud provider, and your starting point is online, ready for you to sub in your own application code. For the purposes of this demonstration, I’ve accepted the defaults. I’ve also left the provided application and function code in place. Let’s examine what Pulumi creates for us here, using Python for AWS, Go for GCP, and Typescript for Azure.

import json
import pulumi
import pulumi_aws as aws
import pulumi_aws_apigateway as apigateway

# An execution role to use for the Lambda function
role = aws.iam.Role("role",
 assume_role_policy=json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com",
 },
 }],
 }),
 managed_policy_arns=[aws.iam.ManagedPolicy.AWS_LAMBDA_BASIC_EXECUTION_ROLE])

# A Lambda function to invoke
fn = aws.lambda_.Function("fn",
 runtime="python3.9",
 handler="handler.handler",
 role=role.arn,
 code=pulumi.FileArchive("./function"))

# A REST API to route requests to HTML content and the Lambda function
api = apigateway.RestAPI("api",
 routes=[
 apigateway.RouteArgs(path="/", local_path="www"),
 apigateway.RouteArgs(path="/date", method=apigateway.Method.GET, event_handler=fn)
 ])

# The URL at which the REST API will be served.
pulumi.export("url", api.url)

Here Pulumi has provided an IAM execution role to use for the Lambda function, the Lambda function itself, and a REST API gateway to handle request routing. The Lambda function is pointed at an included ./function directory, which contains a Python function that returns the latest datetime. This can be replaced with your own code, or you can change the directory the Pulumi code is pointed at to your own. Similarly, the API gateway is pointed at a www directory containing a simple website to display the current datetime, ready to be replaced with your own content.

package main

import (
 "fmt"

 "github.com/pulumi/pulumi-gcp/sdk/v6/go/gcp/cloudfunctions"
 "github.com/pulumi/pulumi-gcp/sdk/v6/go/gcp/storage"
 synced "github.com/pulumi/pulumi-synced-folder/sdk/go/synced-folder"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 // Import the program's configuration settings.
 cfg := config.New(ctx, "")
 sitePath := "./www"
 if param := cfg.Get("sitePath"); param != "" {
 sitePath = param
 }
 appPath := "./app"
 if param := cfg.Get("appPath"); param != "" {
 appPath = param
 }
 indexDocument := "index.html"
 if param := cfg.Get("indexDocument"); param != "" {
 indexDocument = param
 }
 errorDocument := "error.html"
 if param := cfg.Get("errorDocument"); param != "" {
 errorDocument = param
 }

 // Create a storage bucket and configure it as a website.
 siteBucket, err := storage.NewBucket(ctx, "site-bucket", &storage.BucketArgs{
 Location: pulumi.String("US"),
 Website: &storage.BucketWebsiteArgs{
 MainPageSuffix: pulumi.String(indexDocument),
 NotFoundPage: pulumi.String(errorDocument),
 },
 })
 if err != nil {
 return err
 }

 // Create an IAM binding to allow public read access to the bucket.
 _, err = storage.NewBucketIAMBinding(ctx, "site-bucket-iam-binding", &storage.BucketIAMBindingArgs{
 Bucket: siteBucket.Name,
 Role: pulumi.String("roles/storage.objectViewer"),
 Members: pulumi.StringArray{
 pulumi.String("allUsers"),
 },
 })
 if err != nil {
 return err
 }

 // Use a synced folder to manage the files of the website.
 _, err = synced.NewGoogleCloudFolder(ctx, "synced-folder", &synced.GoogleCloudFolderArgs{
 Path: pulumi.String(sitePath),
 BucketName: siteBucket.Name,
 })
 if err != nil {
 return err
 }

 // Create another storage bucket for the serverless app.
 appBucket, err := storage.NewBucket(ctx, "app-bucket", &storage.BucketArgs{
 Location: pulumi.String("US"),
 })
 if err != nil {
 return err
 }

 // Upload the serverless app to the storage bucket.
 appArchive, err := storage.NewBucketObject(ctx, "app-archive", &storage.BucketObjectArgs{
 Bucket: appBucket.Name,
 Source: pulumi.NewFileArchive(appPath),
 })
 if err != nil {
 return err
 }

 // Create a Cloud Function that returns some data.
 dataFunction, err := cloudfunctions.NewFunction(ctx, "data-function", &cloudfunctions.FunctionArgs{
 SourceArchiveBucket: appBucket.Name,
 SourceArchiveObject: appArchive.Name,
 Runtime: pulumi.String("go116"),
 EntryPoint: pulumi.String("Data"),
 TriggerHttp: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }

 // Create an IAM member to invoke the function.
 _, err = cloudfunctions.NewFunctionIamMember(ctx, "data-function-invoker", &cloudfunctions.FunctionIamMemberArgs{
 Project: dataFunction.Project,
 Region: dataFunction.Region,
 CloudFunction: dataFunction.Name,
 Role: pulumi.String("roles/cloudfunctions.invoker"),
 Member: pulumi.String("allUsers"),
 })
 if err != nil {
 return err
 }

 // Create a JSON configuration file for the website.
 _, err = storage.NewBucketObject(ctx, "site-config", &storage.BucketObjectArgs{
 Name: pulumi.String("config.json"),
 Bucket: siteBucket.Name,
 ContentType: pulumi.String("application/json"),
 Source: dataFunction.HttpsTriggerUrl.ApplyT(func(url string) pulumi.AssetOrArchiveOutput {
 config := fmt.Sprintf(`{ "api": "%s" }`, url)
 return pulumi.NewStringAsset(config).ToAssetOrArchiveOutput()
 }).(pulumi.AssetOrArchiveOutput),
 })
 if err != nil {
 return err
 }

 // Export the URLs of the website and serverless endpoint.
 ctx.Export("siteURL", pulumi.Sprintf("https://storage.googleapis.com/%s/index.html", siteBucket.Name))
 ctx.Export("apiURL", dataFunction.HttpsTriggerUrl)

 return nil
 })
}

Here Pulumi is defining your application’s initial configuration values, including the directories it should be checking for your serverless application code and the index and error pages for the website it stands up. It then creates two storage buckets, each with appropriate IAM roles for access, one containing your serverless function and another configured to act like a website. We also have the Cloud Function declaration itself, and all configurations necessary for it, followed by exporting the URL for you.

import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure-native";
import * as synced from "@pulumi/synced-folder";

// Import the program's configuration settings.
const config = new pulumi.Config();
const sitePath = config.get("sitePath") || "./www";
const appPath = config.get("appPath") || "./app";
const indexDocument = config.get("indexDocument") || "index.html";
const errorDocument = config.get("errorDocument") || "error.html";

// Create a resource group for the website.
const resourceGroup = new azure.resources.ResourceGroup("resource-group", {});

// Create a blob storage account.
const account = new azure.storage.StorageAccount("account", {
 resourceGroupName: resourceGroup.name,
 kind: azure.storage.Kind.StorageV2,
 sku: {
 name: azure.storage.SkuName.Standard_LRS,
 },
});

// Create a storage container for the pages of the website.
const website = new azure.storage.StorageAccountStaticWebsite("website", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 indexDocument: indexDocument,
 error404Document: errorDocument,
});

// Use a synced folder to manage the files of the website.
const syncedFolder = new synced.AzureBlobFolder("synced-folder", {
 path: sitePath,
 resourceGroupName: resourceGroup.name,
 storageAccountName: account.name,
 containerName: website.containerName,
});

// Create a storage container for the serverless app.
const appContainer = new azure.storage.BlobContainer("app-container", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 publicAccess: azure.storage.PublicAccess.None,
});

// Upload the serverless app to the storage container.
const appBlob = new azure.storage.Blob("app-blob", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 containerName: appContainer.name,
 source: new pulumi.asset.FileArchive(appPath),
});

// Create a shared access signature to give the Function App access to the code.
const signature = azure.storage.listStorageAccountServiceSASOutput({
 resourceGroupName: resourceGroup.name,
 accountName: account.name,
 protocols: azure.storage.HttpProtocol.Https,
 sharedAccessStartTime: "2022-01-01",
 sharedAccessExpiryTime: "2030-01-01",
 resource: azure.storage.SignedResource.C,
 permissions: azure.storage.Permissions.R,
 contentType: "application/json",
 cacheControl: "max-age=5",
 contentDisposition: "inline",
 contentEncoding: "deflate",
 canonicalizedResource: pulumi.interpolate`/blob/${account.name}/${appContainer.name}`,
});

// Create an App Service plan for the Function App.
const plan = new azure.web.AppServicePlan("plan", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: "Y1",
 tier: "Dynamic",
 },
});

// Create the Function App.
const functionApp = new azure.web.WebApp("function-app", {
 resourceGroupName: resourceGroup.name,
 serverFarmId: plan.id,
 kind: "FunctionApp",
 siteConfig: {
 appSettings: [
 {
 name: "FUNCTIONS_WORKER_RUNTIME",
 value: "node",
 },
 {
 name: "WEBSITE_NODE_DEFAULT_VERSION",
 value: "~14",
 },
 {
 name: "FUNCTIONS_EXTENSION_VERSION",
 value: "~3",
 },
 {
 name: "WEBSITE_RUN_FROM_PACKAGE",
 value: pulumi.all([account.name, appContainer.name, appBlob.name, signature])
 .apply(([accountName, containerName, blobName, signature]) => `https://${accountName}.blob.core.windows.net/${containerName}/${blobName}?${signature.serviceSasToken}`),
 },
 ],
 cors: {
 allowedOrigins: [
 "*"
 ],
 },
 },
});

// Create a JSON configuration file for the website.
const configFile = new azure.storage.Blob("config.json", {
 source: functionApp.defaultHostName
 .apply(host => new pulumi.asset.StringAsset(JSON.stringify({ api: `https://${host}/api` }))),
 contentType: "application/json",
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 containerName: website.containerName,
});

// Export the URLs of the website and serverless endpoint.
export const siteURL = account.primaryEndpoints.apply(primaryEndpoints => primaryEndpoints.web);
export const apiURL = pulumi.interpolate`https://${functionApp.defaultHostName}/api`;

Here, Pulumi first defines the configuration options for your project, including the directories to look at for your application code and your website, as well as what the index and error documents should be. It then goes on to set up your blob storage account and containers for your website and serverless function, before uploading the serverless function itself with all permissions and configurations necessary to operate.

Extending Templates

In addition to the Pulumi code above, each template includes a simple website that utilizes a provided serverless function to display the current time and date, constantly updating. With only two CLI commands, you have deployed the core infrastructure necessary to get your serverless application online in the cloud, without writing a single line of code yourself.

From here, you’re ready to drop in your own application code. Pulumi has already handled the boring work for you, complying with best practices from the beginning so you only have to worry about building your own application, not how to get the infrastructure online!

Pulumi Architecture Templates exist for a variety of applications and common use-cases, including containerized applications and kubernetes, with more being added over time. Keep an eye out for new additions and ways to make engineering for the cloud less painful!

Introducing Pulumi Architecture Templates

Laura Santamaria — Wed, 19 Oct 2022 10:59:37 -0500

🚀 Deploying cloud infrastructure is hard. Getting the architecture right from the start can be time-consuming. What if you could skip the hassle and start with prebuilt, best-practice templates?

📢 Pulumi Architecture Templates let you scaffold cloud infrastructure instantly with a single command. Whether you’re launching a serverless app on AWS, a container service on GCP, or a Kubernetes cluster on Azure, Pulumi gives you ready-to-use templates to get started faster.

➡️ Let’s dive in and see how these templates simplify cloud deployments.

Best Practices for Common Architectures

While Pulumi allows you to define any architecture for any cloud, we often get asked for opinionated architectures to get started with different cloud-based scenarios. To meet this need, we’ve started building templates around best-practice architectures like a serverless architecture on Google Cloud or a container service architecture on AWS. To give a sense of what these templates are like, let’s explore the serverless template for Google Cloud, which uses Cloud Storage and Cloud Functions to deploy a small application that tells the current time.

Google Cloud Functions Example

There are a lot of additional components to add to any infrastructure on modern clouds, including roles created through access management. The Google Cloud Serverless Application template defines a number of necessary components:

A storage bucket
An Identity Account Management (IAM) binding for the bucket
A Google Cloud Folder custom component to sync a local folder to the bucket (so you don’t have to create individual objects for each file in a directory!)
Another storage bucket
A bucket object to hold the function app code
A Cloud Function
Another IAM member to run the Function
An object in the bucket to hold some configuration values

Deployments Made Simpler

Using this template (or any of the other templates, for that matter), you can create a new Pulumi project with the pulumi new command. The template’s creation steps will now ask for all of the necessary configuration values for this template. No more deployment errors because you forgot to define your Google Cloud project with pulumi config set!

$ pulumi new serverless-gcp-python
This command will walk you through creating a new Pulumi project.

Enter a value or leave blank to accept the (default), and press <ENTER>.
Press ^C at any time to quit.

project name: (serverless-app)
project description: (A serverless web application on Google Cloud Platform)
Created project 'serverless-app'

Please enter your desired stack name.
To create a stack in an organization, use the format <org-name>/<stack-name> (e.g. `acmecorp/dev`).
stack name: (dev)
Created stack 'dev'

gcp:project: The Google Cloud project to deploy into: fake-proj-1
gcp:region: The Google Cloud region to deploy into: (us-central1)
appPath: The path to the folder containing the functions to be deployed: (./app)
errorDocument: The file to use for error pages: (error.html)
indexDocument: The file to use for top-level pages: (index.html)

Pulumi Templates vs Manual Setup

Feature	Pulumi Architecture Templates	Manual Setup
Preconfigured Best Practices	✅ Yes	❌ No
Multi-Cloud Support	✅ AWS, GCP, Azure	❌ Typically single-cloud
Faster Deployments	✅ One command setup	❌ Manual coding required
Scalability	✅ Easily extensible	⚠️ Needs custom scripts
Infrastructure-as-Code (IaC)	✅ Pulumi-native	❌ Requires manual IaC setup

Test Templates Yourself

There are already a number of templates built, and more are coming over the next weeks and months. We’ll be exploring more templates in detail here on the blog and on PulumiTV in the future. Review all the currently available architecture templates at our templates page. We’d love to hear what you think!