diff --git a/content/blog/announcing-7-0-of-the-pulumi-aws-provider/index.md b/content/blog/announcing-7-0-of-the-pulumi-aws-provider/index.md index 288dcf812024..32a51586904b 100644 --- a/content/blog/announcing-7-0-of-the-pulumi-aws-provider/index.md +++ b/content/blog/announcing-7-0-of-the-pulumi-aws-provider/index.md @@ -2,6 +2,7 @@ title: "Pulumi AWS Provider 7.0: Multi-Region Support, IAM Role Chaining, and S3 Resource Simplification" allow_long_title: true date: 2025-08-05T09:00:00-04:00 +updated: 2026-08-22 draft: false meta_desc: "Pulumi AWS Provider 7.0 adds multi-region support, IAM role chaining, and improved S3 resource management for seamless AWS infrastructure as code." authors: @@ -14,7 +15,7 @@ category: product --- -[Pulumi AWS provider 7.0](https://www.pulumi.com/registry/packages/aws/) is here with powerful new capabilities that simplify and scale **infrastructure as code on AWS**. As the most widely used provider in the Pulumi ecosystem, it offers access to the full surface area of the upstream Terraform AWS Provider in Pulumi projects in all supported languages, like TypeScript, Python, Go, .NET, Java, and YAML. +[Pulumi AWS provider 7.0](https://www.pulumi.com/registry/packages/aws/) is here with powerful new capabilities that simplify and scale **infrastructure as code on AWS**. As the most widely used provider in the Pulumi ecosystem, it offers access to the resource surface of the upstream Terraform AWS Provider in Pulumi projects in all supported languages, like TypeScript, Python, Go, .NET, Java, and YAML. The [7.0 release](https://github.com/pulumi/pulumi-aws/releases/tag/v7.0.0) brings fixes and improvements to the provider, including several breaking changes as part of the major version release. diff --git a/content/blog/aws-cdk-vs-pulumi-why-sst-switched/index.md b/content/blog/aws-cdk-vs-pulumi-why-sst-switched/index.md index 0631f1b4441d..e63301320f15 100644 --- a/content/blog/aws-cdk-vs-pulumi-why-sst-switched/index.md +++ b/content/blog/aws-cdk-vs-pulumi-why-sst-switched/index.md @@ -8,7 +8,7 @@ title: "AWS CDK vs Pulumi: Why SST Chose Pulumi" # the time portion of the date value; posts are sorted in descending order by # date/time. date: 2024-09-25T07:32:40Z -updated: 2025-03-05 +updated: 2026-08-22 # The draft setting determines whether a post is published. Set it to true if # you want to be able to merge the post without publishing it. @@ -156,7 +156,7 @@ One of Pulumi's most significant benefits for SST users is the simplified mental Instead of having to navigate the complexities of intermediary formats, deployment pipelines, and the separation between infrastructure code and deployment code, SST users can now focus on writing their infrastructure logic in the same programming languages they use for their application code. This makes it much easier for them to understand, maintain, and extend their infrastructure as their needs evolve. {{< blog/cta-card title="Build across any cloud with Pulumi" >}} -Define your infrastructure in TypeScript, Python, Go, or C#, and deploy it across AWS, Azure, Google Cloud, and on-premises environments from one consistent workflow. +Define your infrastructure in TypeScript, JavaScript, Python, Go, .NET, or Java, and deploy it across AWS, Azure, Google Cloud, and on-premises environments from one consistent workflow. {{< /blog/cta-card >}} ## The Future of SST with Pulumi diff --git a/content/blog/azure-container-apps/index.md b/content/blog/azure-container-apps/index.md index b5e5dc122284..a6e73d986d22 100644 --- a/content/blog/azure-container-apps/index.md +++ b/content/blog/azure-container-apps/index.md @@ -1,7 +1,7 @@ --- title: "Deploy Azure Container Apps with Docker and Pulumi" date: 2021-11-02T09:00:00-07:00 -updated: 2025-03-24 +updated: 2026-08-22 meta_desc: "Learn how to deploy Docker containers to Azure Container Apps using Pulumi. A step-by-step guide for building scalable serverless apps in any language." authors: - mikhail-shilkov @@ -75,7 +75,7 @@ Comparing to other vendors: Azure Container Apps are in the same space as **Goog ## Example: Run an HTTP API with Azure Container Apps and Pulumi -Let's walk through the steps to build an example application with Azure Container Apps using infrastructure as code in familiar languages. In this scenario, we create an HTTP application that is available via a public domain name. We'll use Pulumi to provision the necessary resources. In this example, we will use TypeScript however you could also use JavaScript, Python, Go, and C#. +Let's walk through the steps to build an example application with Azure Container Apps using infrastructure as code in familiar languages. In this scenario, we create an HTTP application that is available via a public domain name. We'll use Pulumi to provision the necessary resources. In this example, we will use TypeScript however you could also use JavaScript, Python, Go, and .NET. You can check out the complete source code in the Pulumi Examples: @@ -489,7 +489,7 @@ $ curl $(pulumi stack output url) Azure Container Apps enable you to build applications in your favorite language with any dependencies and tools, package them as a container image, and deploy them in seconds. Container Apps abstract away infrastructure management by automatically scaling up and down to zero and only charging for the exact resources you use. -This post shows how to use Pulumi to build a container image and publish it as an Azure Container App. Pulumi makes it easy to create artifacts and provision and manage cloud infrastructure on any cloud using familiar programming languages, including C#, TypeScript, Python, and Go. Docker images, ACR registries, container environments, and Apps can be managed within the same infrastructure definition. +This post shows how to use Pulumi to build a container image and publish it as an Azure Container App. Pulumi makes it easy to create artifacts and provision and manage cloud infrastructure on any cloud using familiar programming languages, including .NET, TypeScript, Python, and Go. Docker images, ACR registries, container environments, and Apps can be managed within the same infrastructure definition. ### Further steps diff --git a/content/blog/build-publish-containers-iac/index.md b/content/blog/build-publish-containers-iac/index.md index f288f6707d23..8e7c72545808 100644 --- a/content/blog/build-publish-containers-iac/index.md +++ b/content/blog/build-publish-containers-iac/index.md @@ -6,6 +6,7 @@ tags: [containers, docker, kubernetes] category: tutorials meta_desc: "Go from Dockerfile to a fully running containerized service on your cloud of choice using infrastructure as code." date: "2020-12-08" +updated: 2026-08-22 --- @@ -21,7 +22,7 @@ The general approach will be to create a new infrastructure as code project that * Builds and publishes your container image to that registry * Optionally, consumes the resulting image URL from a containerized task definition in Kubernetes, Amazon ECS, or any other container orchestrator -All told, this will be just a few dozen lines of code. This article demonstrates doing this in AWS, Azure, Google Cloud, DigitalOcean, and Docker Hub, and offers code examples in each supported Pulumi language, namely Python, JavaScript, TypeScript, Go, and C#. These steps will work for any application that has a `Dockerfile` and is buildable by Docker. In principle, similar steps could be applied if you prefer to build your container image using different means, such as Buildpack. +All told, this will be just a few dozen lines of code. This article demonstrates doing this in AWS, Azure, Google Cloud, DigitalOcean, and Docker Hub, and offers code examples in Python, JavaScript, TypeScript, Go, and .NET. These steps will work for any application that has a `Dockerfile` and is buildable by Docker. In principle, similar steps could be applied if you prefer to build your container image using different means, such as Buildpack. For purposes of illustration, we'll create a simple Nginx web server whose `Dockerfile` contains: diff --git a/content/blog/claude-code-orchestration-frameworks/index.md b/content/blog/claude-code-orchestration-frameworks/index.md index de503e55a6a8..c0edf5904a28 100644 --- a/content/blog/claude-code-orchestration-frameworks/index.md +++ b/content/blog/claude-code-orchestration-frameworks/index.md @@ -2,6 +2,7 @@ title: "Superpowers, GSD, and GSTACK: Picking the Right Framework for Your Coding Agent" allow_long_title: true date: 2026-04-13 +updated: 2026-08-22 draft: false meta_desc: "Three frameworks for AI coding agents compared: Superpowers enforces TDD, GSD prevents context rot, and GSTACK adds role-based governance." feature_image: feature.png @@ -34,7 +35,7 @@ social: Here's how they compared. --- -Three community frameworks have emerged that fix the specific ways AI coding agents break down on real projects. [Superpowers](https://github.com/obra/superpowers) enforces test-driven development. [GSD](https://github.com/gsd-build/get-shit-done) prevents context rot. [GSTACK](https://github.com/garrytan/gstack) adds role-based governance. All three started with Claude Code but now work across Cursor, Codex, Windsurf, Gemini CLI, and more. +Three community frameworks have emerged that fix the specific ways AI coding agents break down on real projects. [Superpowers](https://github.com/obra/superpowers) enforces test-driven development. [GSD](https://github.com/gsd-build/get-shit-done) prevents context rot. [GSTACK](https://github.com/garrytan/gstack) adds role-based governance. All three started with Claude Code and have since added support for Cursor and Codex, though each has its own further list of supported agents beyond that shared core. Pulumi uses general-purpose programming languages to define infrastructure. TypeScript, JavaScript, Python, Go, .NET, Java. Every framework that makes AI agents write better TypeScript also makes your `pulumi up` better. After spending a few weeks with each one, I have opinions about when to use which. diff --git a/content/blog/incident-response-as-code-pagerduty-pulumi/index.md b/content/blog/incident-response-as-code-pagerduty-pulumi/index.md index f98e31c92ee9..fdc1350592b1 100644 --- a/content/blog/incident-response-as-code-pagerduty-pulumi/index.md +++ b/content/blog/incident-response-as-code-pagerduty-pulumi/index.md @@ -1,6 +1,7 @@ --- title: "Incident Response as Code: Managing PagerDuty with Pulumi" date: 2026-07-20 +updated: 2026-08-22 draft: false meta_desc: "Manage PagerDuty teams, schedules, escalation policies, and services with Pulumi, and wire alerting to the AWS infrastructure in the same program." feature_image: feature.png @@ -55,7 +56,7 @@ flowchart LR EP -->|"level 2, after 15 min"| Lead["Team lead"] ``` -Everything on both sides of that diagram is one TypeScript program. If you would rather write Python, JavaScript, Go, .NET, Java, or YAML, the [Pulumi PagerDuty provider](https://www.pulumi.com/registry/packages/pagerduty/) supports all of them. It is bridged from PagerDuty's official Terraform provider (which started life as a community project by Alexander Hellbom before PagerDuty adopted it), so the resource coverage is identical. +Everything on both sides of that diagram is one TypeScript program. If you would rather write Python, JavaScript, Go, .NET, Java, or YAML, the [Pulumi PagerDuty provider](https://www.pulumi.com/registry/packages/pagerduty/) supports all of them. It is bridged from PagerDuty's official Terraform provider (which started life as a community project by Alexander Hellbom before PagerDuty adopted it), so its resource coverage closely tracks the upstream provider. ## Prerequisites diff --git a/content/blog/why-choose-pulumi-over-terraform/index.md b/content/blog/why-choose-pulumi-over-terraform/index.md index 359053f6b691..51a1406e4ca9 100644 --- a/content/blog/why-choose-pulumi-over-terraform/index.md +++ b/content/blog/why-choose-pulumi-over-terraform/index.md @@ -1,7 +1,7 @@ --- title: "Why Choose Pulumi Over Terraform?" date: 2026-06-02 -lastmod: 2026-06-05 +lastmod: 2026-08-22 meta_desc: "See why teams choose Pulumi over Terraform for modern infrastructure as code, with examples for refactoring, secrets, testing, and safer changes." feature_image: feature.png authors: @@ -59,7 +59,7 @@ The tradeoff is important: Pulumi is still an infrastructure as code engine. Pro Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever [supported programming language](https://www.pulumi.com/docs/iac/languages-sdks/) they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks. -Teams with HCL muscle memory are not left out, either. Pulumi now [supports HCL natively](https://www.pulumi.com/docs/iac/languages-sdks/hcl/) as one of its languages, alongside Python, TypeScript, JavaScript, Go, .NET, Java, and YAML. Part of a team can keep authoring in HCL while the project still benefits from Pulumi components, testing, and the same engine and package workflows as every other language. +Teams with HCL muscle memory are not left out, either. Pulumi now [supports HCL natively](https://www.pulumi.com/docs/iac/languages-sdks/hcl/) as one of its languages, alongside Python, TypeScript, JavaScript, Go, .NET, Java, and YAML. A project written in Pulumi HCL runs your existing `.tf` files largely unchanged, backed by the same state management, secrets handling, and deployment engine as every other Pulumi language. For example, a platform team can wrap a standard storage pattern in a `ComponentResource` and share it like any other TypeScript abstraction: diff --git a/content/blog/why-switch-to-pulumi/index.md b/content/blog/why-switch-to-pulumi/index.md index 54f60655c9e8..7a6770c692a0 100644 --- a/content/blog/why-switch-to-pulumi/index.md +++ b/content/blog/why-switch-to-pulumi/index.md @@ -327,8 +327,9 @@ scalability, and collaboration. infrastructure engineer that works inside your existing workflow: it proposes changes, runs previews, responds to failures, and opens pull requests in tight feedback loops, grounded in the real state of your infrastructure in Pulumi - Cloud. Because that infrastructure is defined in Python, TypeScript, Go, .NET, or - Java rather than a bespoke configuration language, Neo can read, reason about, + Cloud. Because that infrastructure is defined in a [general-purpose + programming language](https://www.pulumi.com/docs/iac/languages-sdks/) rather + than a bespoke configuration language, Neo can read, reason about, test, and ship it the same way an AI coding agent already handles the rest of your codebase. Terraform, by contrast, is defined in HCL, a domain-specific configuration language that AI agents can generate and reason about less