From 56686b6636329cbc46168e63261a613d487a8c00 Mon Sep 17 00:00:00 2001 From: Christian Nunciato Date: Sat, 27 Jun 2026 09:16:11 -0700 Subject: [PATCH] Soften HCL/configuration-language rhetoric for native HCL launch Pulumi is adding first-class support for HCL, so this softens content that framed HCL and "configuration languages" as inferior, repositioning general-purpose languages as a flexible choice rather than a fundamentally superior one. - Reframes flagship pages (what-is-pulumi, superintelligence-infrastructure, the OpenTofu ad) around breadth of language choice, including native HCL. - Surgically neutralizes evaluative clauses across docs comparisons, what-is explainers, marketing/event/gads pages, and marketing layouts. - Adds an {{% hcl-note %}} shortcode and applies it to 15 dated blog posts that disparage HCL, rather than rewriting bylined history. Scope notes: factual critiques of the Terraform *platform* (BUSL relicense, lock-in) are preserved; license facts are kept accurate (Pulumi Apache 2.0 is not equated with OpenTofu's MPL 2.0); customer quotes are left untouched. Co-Authored-By: Claude Opus 4.8 --- .../index.md | 2 ++ .../cloud-engineering-on-the-rise/index.md | 2 ++ .../index.md | 2 ++ .../index.md | 2 ++ .../index.md | 2 ++ content/blog/hcl-vs-pulumi/index.md | 2 ++ .../index.md | 2 ++ .../infrastructure-as-code-tools/index.md | 2 ++ .../index.md | 2 ++ .../index.md | 2 ++ .../index.md | 2 ++ .../index.md | 2 ++ .../the-superintelligence-flywheel/index.md | 2 ++ content/blog/why-switch-to-pulumi/index.md | 2 ++ .../index.md | 2 ++ content/case-studies/bmw.md | 2 +- content/cloud-engineering/_index.md | 2 +- content/docs/iac/comparisons/opentofu.md | 4 ++-- .../docs/iac/comparisons/terraform/_index.md | 4 ++-- .../iac/get-started/terraform/convert-hcl.md | 2 +- .../iac/get-started/terraform/first-look.md | 2 +- .../index.md | 2 +- .../getting-started-with-aws-java/index.md | 2 +- .../index.md | 2 +- .../index.md | 4 ++-- content/gads/opentofu/index.md | 6 ++--- content/gads/python-iac/index.md | 2 +- content/gads/terraform-migration/index.md | 4 ++-- content/gads/terraform/index.md | 10 ++++----- content/migrate/tf2pulumi.md | 4 ++-- .../superintelligence-infrastructure.md | 22 +++++++++---------- .../javascript-and-infrastructure-as-code.md | 4 ++-- content/what-is/top-iac-tools.md | 6 ++--- .../what-is/what-is-agentic-infrastructure.md | 2 +- .../what-is/what-is-infrastructure-as-code.md | 2 +- .../what-is-infrastructure-as-software.md | 4 ++-- content/what-is/what-is-pulumi.md | 12 +++++----- ...se-innovation-through-cloud-engineering.md | 2 +- layouts/awsx/aws.html | 2 +- layouts/migrate/terraform.html | 2 +- layouts/migrate/tf2pulumi.html | 5 ++--- layouts/shortcodes/hcl-note.html | 12 ++++++++++ layouts/shortcodes/hcl-note.markdown.md | 1 + 43 files changed, 100 insertions(+), 58 deletions(-) create mode 100644 layouts/shortcodes/hcl-note.html create mode 100644 layouts/shortcodes/hcl-note.markdown.md diff --git a/content/blog/cloud-engineering-fuels-startup-innovation/index.md b/content/blog/cloud-engineering-fuels-startup-innovation/index.md index 1c143f0e6c80..05f697ee4af6 100644 --- a/content/blog/cloud-engineering-fuels-startup-innovation/index.md +++ b/content/blog/cloud-engineering-fuels-startup-innovation/index.md @@ -38,6 +38,8 @@ tags: --- The story of how the cloud fuels startup innovation seems never ending. In the beginning, AWS birthed cloud computing with its first service, SQS, in 2004 and quickly released several additional services (like S3, EC2, and SimpleDB). From this innovation, startups flourished because they were able to build, experiment, and grow faster than before at much lower cost. Airbnb, Netflix, Zynga, and many more were born, and the rest is history. +{{% hcl-note %}} + Today, a new generation of startups is flourishing because of the cloud, but this time with modern cloud architectures that are distributed, API-driven, and more resilient and scalable than ever. Today’s startups have to get to market even faster and rapidly innovate in order to delight customers and carve out market share. Most startups understand the benefits of adopting the modern cloud to help them achieve this goal. However, their ability to reap these benefits for competitive advantage depends on how well they can harness the modern cloud. Within the [cloud engineering](/cloud-engineering/) community, we see several common patterns for harnessing the modern cloud. Some startups have teams of full-stack developers who need to deploy cloud infrastructure and applications safely and at high velocity. Others might have a few infrastructure or platform engineers who need to enable other developers to use cloud infrastructure easily on a self-serve basis. Many of these teams started off using domain-specific languages (DSLs) to manage infrastructure as code and quickly found that these languages were the limiting factor in achieving faster velocity. DSLs are cumbersome to use and don’t support the logic and expressiveness needed to build and manage modern architectures that are more complex in nature. DSLs are also a barrier to entry to most developers. diff --git a/content/blog/cloud-engineering-on-the-rise/index.md b/content/blog/cloud-engineering-on-the-rise/index.md index 87bd2b4d22fb..38206f0dde8b 100644 --- a/content/blog/cloud-engineering-on-the-rise/index.md +++ b/content/blog/cloud-engineering-on-the-rise/index.md @@ -14,6 +14,8 @@ One of the most fulfilling aspects of working at Pulumi is learning how customer +{{% hcl-note %}} + Pulumi is born from the experiences and needs of teams practicing cloud engineering every day. When we [announced](/blog/pulumi-3-0/) the Pulumi Cloud Engineering Platform in April, CEO & Founder Joe Duffy [talked about](https://www.youtube.com/watch?v=Zko70KVGcgo) bringing cloud engineering to everyone. Over the past year we have seen significant growth in cloud engineering and usage of Pulumi across companies of all industries and sizes, and spanning a diverse spectrum of teams and engineering disciplines. We’re also seeing growing numbers of job postings with “cloud engineer” in the title or which have Pulumi as a requirement or desired skill set. Recently, we published several case studies about how teams are applying cloud engineering best practices. Cloud engineers apply standard software engineering practices and tools uniformly across infrastructure management, application development, and security to tame the complexity of delivering and managing modern cloud applications. We’ve published on our [website](/cloud-engineering/) and in this [blog](/blog/infrastructure-testing-concepts/) some of the key cloud engineering best practices that we see broadly across the community, and encourage you to read further to see three stories of cloud engineering in action. diff --git a/content/blog/config-chaos-to-programming-languages/index.md b/content/blog/config-chaos-to-programming-languages/index.md index 70987438fdf5..fd574895bbfa 100644 --- a/content/blog/config-chaos-to-programming-languages/index.md +++ b/content/blog/config-chaos-to-programming-languages/index.md @@ -22,6 +22,8 @@ social: *This post is based on our video interview with Daniel Ward, a Software Developer/Consultant at Lean TECHniques and Microsoft MVP. Daniel shares his strategies for moving teams from configuration chaos to programming languages for infrastructure, including the 10% rule for change, viral adoption, and why Pulumi beats YAML for complex systems. Watch the video below or read on. - Adam Gordon Bell* +{{% hcl-note %}} + {{< youtube "3VKbaNtbdSs?rel=0" >}} Imagine your infrastructure codebase has evolved from a few files to thousands of lines across dozens of configuration files. Your team spends hours deciphering CloudFormation templates, your AWS CDK deployments take 30+ minutes, and introducing any change becomes a multi-day effort. This is the reality many organizations face when their infrastructure-as-code approach outgrows their tooling. diff --git a/content/blog/getting-started-aks-pulumi-csharp/index.md b/content/blog/getting-started-aks-pulumi-csharp/index.md index a87524b9b57d..374eb22a6651 100644 --- a/content/blog/getting-started-aks-pulumi-csharp/index.md +++ b/content/blog/getting-started-aks-pulumi-csharp/index.md @@ -35,6 +35,8 @@ social: +{{% hcl-note %}} + Live demos keep you honest. On June 10th my AKS workshop went a little sideways. Partway through, Docker Hub rate-limited my image pull and we had to adapt the content on the fly. The original plan was to stand up an AKS cluster with Cilium, an Azure Container Registry with the cluster's pull permission wired in code, and a random-cat web app, then split the infrastructure from the workload into separate Pulumi stacks. Live, we didn't make it through all of that, but we had some fun tangents and it turned out to be a great session. So here are my six recommendations for working with Kubernetes on Azure from this recent workshop. ## 1. Pick the language your team already uses diff --git a/content/blog/gitops-best-practices-i-wish-i-had-known-before/index.md b/content/blog/gitops-best-practices-i-wish-i-had-known-before/index.md index 5f26516e122e..8b4c657b12c3 100644 --- a/content/blog/gitops-best-practices-i-wish-i-had-known-before/index.md +++ b/content/blog/gitops-best-practices-i-wish-i-had-known-before/index.md @@ -36,6 +36,8 @@ Getting started with GitOps can feel like trying to herd cats through a YAML fac +{{% hcl-note %}} + If you're not familiar with the formal definition, the [OpenGitOps](https://opengitops.dev/) project distills it into four principles: * Declarative desired state diff --git a/content/blog/hcl-vs-pulumi/index.md b/content/blog/hcl-vs-pulumi/index.md index 30c963f306af..88b5b8d21f2d 100644 --- a/content/blog/hcl-vs-pulumi/index.md +++ b/content/blog/hcl-vs-pulumi/index.md @@ -29,6 +29,8 @@ tags: The Java Language Architect at Oracle, Brian Goetz, author of Java Concurrency in Practice, has commented how declarative languages can be a double-edged sword: +{{% hcl-note %}} + ![brian-goetz-tweet](brian-goetz-tweet.png) HashiCorp’s infrastructure as code solution, Terraform, uses a domain-specific language (DSL) to declare cloud diff --git a/content/blog/hidden-costs-of-infrastructure-management/index.md b/content/blog/hidden-costs-of-infrastructure-management/index.md index 1d3a59b55364..2841af9d0b0e 100644 --- a/content/blog/hidden-costs-of-infrastructure-management/index.md +++ b/content/blog/hidden-costs-of-infrastructure-management/index.md @@ -15,6 +15,8 @@ Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. [Learn [Infrastructure as Code (IaC)](/what-is/what-is-infrastructure-as-code/) has revolutionized how cloud resources are managed, allowing for more efficient, scalable, and repeatable deployments. We designed [Pulumi IaC](/product/infrastructure-as-code/) to let you program cloud infrastructure using familiar programming languages like TypeScript, JavaScript, Python, Go, .NET, Java, and YAML. This approach not only simplifies the process but also integrates seamlessly with existing development tools and ecosystems (e.g., IDEs, standard unit test frameworks, integration test). You can define infrastructure with code, often in just one line, for serverless, Kubernetes, AI/ML, databases, and more. You can also preview changes before deploying unlike many other IaC solutions. Pulumi IaC is fully open source with a [public roadmap](https://github.com/orgs/pulumi/projects/44/). We value working with the community to shape the product through feedback and contributions. +{{% hcl-note %}} + ## What is Pulumi Cloud? Infrastructure as Code tools like Pulumi require systems for coordinating deployments, which include concurrency control, state management, and security. For the purposes of this post, let's refer to these systems as IaC backends. There are several options for managing these backends: you can either handle them yourself, which we'll call DIY, or you can leverage [Pulumi Cloud](/product/pulumi-cloud/), available as a SaaS or self-hosted solution. With Pulumi Cloud, you gain access to a comprehensive infrastructure management platform designed to handle everything running in the cloud. This platform automates your IaC deployments, centralizes [secrets management](/what-is/what-is-secrets-management/) and orchestration to manage secrets sprawl effectively, and employs AI to oversee infrastructure assets and ensure compliance. On the other hand, with a DIY approach, you have the flexibility to build everything Pulumi Cloud offers or opt for a more minimalistic setup tailored to your organization's specific needs. Both options are well-supported by Pulumi, but there are distinct advantages to choosing Pulumi Cloud over the DIY method, which we'll explore further. diff --git a/content/blog/infrastructure-as-code-tools/index.md b/content/blog/infrastructure-as-code-tools/index.md index 02a2d8be9def..cf3e564c8281 100644 --- a/content/blog/infrastructure-as-code-tools/index.md +++ b/content/blog/infrastructure-as-code-tools/index.md @@ -21,6 +21,8 @@ Infrastructure as Code (IaC) has evolved beyond simple automation into a fundame +{{% hcl-note %}} + As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration. This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you're starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we'll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure. diff --git a/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md b/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md index fb029aea856d..4d6d5e2e9391 100644 --- a/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md +++ b/content/blog/migrating-my-infrastructure-from-terraform-to-pulumi/index.md @@ -16,6 +16,8 @@ Pulumi community member [Erik Näslund](https://blog.ekik.org/) shares his thoug +{{% hcl-note %}} + I've been using [Terraform](https://www.terraform.io/) for a couple of years and overall I've been quite happy with it. However there's a few things that started to bother me more and more recently. Terraform uses a language called Hashicorp HCL to define the infrastructure. It's a relatively simple declarative language, but it's something I had to learn along the way. Just like any language it has it's little quirks, and I often found myself spending more time than I wanted to figure out how to do certain things. As I'm doing all the infrastructure myself I really wanted to be able to use a language I'm familiar with, to make things simple. diff --git a/content/blog/next-level-iac-briding-the-declarative-gap/index.md b/content/blog/next-level-iac-briding-the-declarative-gap/index.md index b6ac350da94e..e69ee1ad2372 100644 --- a/content/blog/next-level-iac-briding-the-declarative-gap/index.md +++ b/content/blog/next-level-iac-briding-the-declarative-gap/index.md @@ -19,6 +19,8 @@ Pulumi stands out in the world of infrastructure-as-code (IaC) for its flexibili +{{% hcl-note %}} + In Pulumi, you describe your infrastructure in code – real code, not a [DSL][dsl-wiki] or [YAML][yaml-wiki] – using your preferred general purpose programming language. You don't have to become a specialist in a niche proprietary declarative language, like Terraform's HCL. Rather, you can reuse your existing programming skills, writing in standard imperative, object-oriented, and even [functional language][fsharp-example] styles, while still gaining all of the benefits of the declarative style that other tools emphasize. Pulumi provides a unique mix of a [declarative model][pulumi-declarative-imperative-docs] embedded and implemented inside of a standard programming language, allowing all the flexibility of custom imperative code, while still enabling Pulumi's [deployment engine][pulumi-engine-docs] to infer opportunities for parallel asynchronous execution and to converge a partially-realized system. diff --git a/content/blog/next-level-iac-package-ecosystems/index.md b/content/blog/next-level-iac-package-ecosystems/index.md index c7b26617f381..32e93cff10b6 100644 --- a/content/blog/next-level-iac-package-ecosystems/index.md +++ b/content/blog/next-level-iac-package-ecosystems/index.md @@ -18,6 +18,8 @@ tags: Every experienced tech professional I know has a programming language they love. But is it the syntax and symbols that make it so loveable? Not really. It's the community and package ecosystem surrounding the language that makes a real impact on your heart... and on your productivity! If we look at some of the biggest success stories in tech --- Python, Node.js, Ruby, Perl, and Go --- the common thread between all of them is an extensive ecosystem of packages, libraries, modules (or whatever you decide to call them… ahem, Gems?!). A great language will allow you to build anything you can imagine, but a great ecosystem will have already written it for you, and made it available in a convenient to install-and-use package. +{{% hcl-note %}} + ![Pulumi Language Ecosystem](pulumi-language-ecosystem.png) One of the amazing things about Pulumi is that it is built around general-purpose programming languages, and that means your Pulumi programs have access to the entire ecosystem of packages that come with each language. This is a stark difference between Pulumi and other infrastructure automation tools that use proprietary domain-specific languages with not much in the way of community around them. Some tools might allow you to write custom code, but they certainly don’t make it convenient, and still… you have to write it yourself, which just adds so much overhead to a project where your core concern isn’t writing that custom function, but rather shipping your own product on the infrastructure you are trying to automate. diff --git a/content/blog/pulumi-for-aws-automate-secure-manage/index.md b/content/blog/pulumi-for-aws-automate-secure-manage/index.md index a5b0a3500769..5e12f8c18c80 100644 --- a/content/blog/pulumi-for-aws-automate-secure-manage/index.md +++ b/content/blog/pulumi-for-aws-automate-secure-manage/index.md @@ -22,6 +22,8 @@ Stop by the Pulumi re:Invent booth #370 this week to chat with experts on the Pu +{{% hcl-note %}} + ## Why Pulumi for AWS? Pulumi empowers your organization to automate AWS cloud infrastructure through code, tame secrets sprawl through centralized secrets management, and manage cloud assets and compliance with the help of AI. Pulumi encourages infrastructure, platform, development, DevOps, and security teams to collaborate and accelerates time to market with greater control and minimized risk. diff --git a/content/blog/the-superintelligence-flywheel/index.md b/content/blog/the-superintelligence-flywheel/index.md index 11d32d26db94..1bd07d4c0f2b 100644 --- a/content/blog/the-superintelligence-flywheel/index.md +++ b/content/blog/the-superintelligence-flywheel/index.md @@ -26,6 +26,8 @@ The infrastructure required to build superintelligence demands superintelligence +{{% hcl-note %}} + The systems being built today for superintelligence are already straining human platform teams to their limits and yet we're still only just getting started. To succeed, we will have no choice but to use AI itself to help us manage the infrastructure scaling ahead on the path to superintelligence. Superintelligence demands more infrastructure, which demands superintelligent approaches to managing and scaling that infrastructure, which leads to faster progress towards superintelligence. diff --git a/content/blog/why-switch-to-pulumi/index.md b/content/blog/why-switch-to-pulumi/index.md index 16d8879ca6ee..a75847000873 100644 --- a/content/blog/why-switch-to-pulumi/index.md +++ b/content/blog/why-switch-to-pulumi/index.md @@ -33,6 +33,8 @@ are bogged down by: - Rolling out updates across regions takes weeks - The combinations of modern cloud architectures seems infinite +{{% hcl-note %}} + You know there has to be a better way. A way to truly harness the power of the cloud and turn it into your competitive advantage. diff --git a/content/blog/yaml-terraform-pulumi-whats-the-smart-choice-for-deployment-automation-with-kubernetes/index.md b/content/blog/yaml-terraform-pulumi-whats-the-smart-choice-for-deployment-automation-with-kubernetes/index.md index b7ad80b3fde0..232a0e081243 100644 --- a/content/blog/yaml-terraform-pulumi-whats-the-smart-choice-for-deployment-automation-with-kubernetes/index.md +++ b/content/blog/yaml-terraform-pulumi-whats-the-smart-choice-for-deployment-automation-with-kubernetes/index.md @@ -55,6 +55,8 @@ YAML and [Kubernetes](https://kubernetes.io/) go together like peanut butter and It's often the first tool developers encounter when diving into Kubernetes, and for good reason - its human-readable format makes it the preferred choice in most tutorials, documentation, and even production deployments. +{{% hcl-note %}} +
Description of image
diff --git a/content/case-studies/bmw.md b/content/case-studies/bmw.md index 92a2d0cdc0e4..a1a60391bea1 100644 --- a/content/case-studies/bmw.md +++ b/content/case-studies/bmw.md @@ -23,7 +23,7 @@ aliases: As organizations scale their cloud infrastructure, they face a critical choice: continue managing infrastructure and applications as separate concerns with different tools and workflows, or unify them under a single, programmable approach. Traditional infrastructure-as-code tools require learning proprietary languages and often force teams to maintain parallel toolchains for application deployment and infrastructure provisioning. -Platform engineering teams need solutions that can scale to thousands of resources across multiple environments while maintaining security, compliance, and developer productivity. They need the full power of real programming languages, not limited domain-specific languages. And they need infrastructure that integrates naturally with their existing CI/CD pipelines rather than requiring separate automation workflows. +Platform engineering teams need solutions that can scale to thousands of resources across multiple environments while maintaining security, compliance, and developer productivity. They need the full power of general-purpose programming languages, with the libraries, tooling, and abstractions those languages provide. And they need infrastructure that integrates naturally with their existing CI/CD pipelines rather than requiring separate automation workflows. ## About CodeCraft diff --git a/content/cloud-engineering/_index.md b/content/cloud-engineering/_index.md index a88d71f00649..abde7dccdd73 100644 --- a/content/cloud-engineering/_index.md +++ b/content/cloud-engineering/_index.md @@ -27,7 +27,7 @@ build: - title: General-Purpose Programming Languages description: | Define infrastructure with general-purpose programming languages like TypeScript/JavaScript, Python, Go, .NET, and Java and use standard constructs like loops - and conditionals. This gives you more flexibility and reduces complexity compared to domain-specific languages. You could also use markup languages like YAML as a simple way for consuming complex infrastructure modeled in general-purpose languages. + and conditionals. This gives you the flexibility of loops, functions, and conditionals when you want them. You can also use a markup language like YAML, or a domain-specific language like HCL, depending on what fits your team. - title: Broad Development Ecosystem description: | diff --git a/content/docs/iac/comparisons/opentofu.md b/content/docs/iac/comparisons/opentofu.md index 539d2afd57be..62b41d456720 100644 --- a/content/docs/iac/comparisons/opentofu.md +++ b/content/docs/iac/comparisons/opentofu.md @@ -55,7 +55,7 @@ OpenTofu is an open-source, declarative infrastructure as code tool forked from ### Language support and the authoring experience -OpenTofu configurations are written in [HCL](https://opentofu.org/docs/language/), a declarative DSL with a fixed set of [built-in functions](https://opentofu.org/docs/language/functions/) and meta-arguments (`for_each`, `count`, `dynamic`) for shaping resources. The DSL keeps configurations declarative but constrains abstraction: there are no classes, no first-class testing frameworks, and no general-purpose package ecosystem. Pulumi programs are written in general-purpose languages, so authors get loops, conditionals, classes, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems. Pulumi also supports [YAML](/docs/iac/languages-sdks/yaml/) for users who prefer a markup format. +OpenTofu configurations are written in [HCL](https://opentofu.org/docs/language/), a declarative DSL with a fixed set of [built-in functions](https://opentofu.org/docs/language/functions/) and meta-arguments (`for_each`, `count`, `dynamic`) for shaping resources. HCL is declarative and configuration-focused. General-purpose languages offer a different model, with classes, richer runtime logic, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems, so Pulumi lets you choose the approach that fits the project. Pulumi supports HCL natively as well, alongside [YAML](/docs/iac/languages-sdks/yaml/) for users who prefer a markup format. ### Cloud and service coverage @@ -77,7 +77,7 @@ Pulumi treats secrets as a first-class primitive. Values marked as secrets are e ### Modularity and reuse -OpenTofu modules are units of HCL referenced from a local path, a Git URL, or a registry. They compose well within HCL but cannot share runtime helpers or types with non-module code. Pulumi's [Component Resources](/docs/iac/concepts/components/) are runtime objects with explicit parent/child relationships, so a component and the resources inside it form a coherent unit in plan output, deletion, and state. Components can be authored in one language and consumed from any other supported language by publishing them as a [Pulumi Package](/docs/iac/concepts/packages/). Pulumi can also [consume OpenTofu modules directly](/docs/iac/guides/building-extending/using-existing-tools/use-terraform-module/), automatically installing and invoking OpenTofu to execute them — useful for teams that have invested heavily in module libraries and want to keep using them while moving to Pulumi. +OpenTofu modules are units of HCL referenced from a local path, a Git URL, or a registry. Modules compose within HCL. Pulumi's [Component Resources](/docs/iac/concepts/components/) are runtime objects that can share helpers and types with the rest of your program, with explicit parent/child relationships, so a component and the resources inside it form a coherent unit in plan output, deletion, and state. Components can be authored in one language and consumed from any other supported language by publishing them as a [Pulumi Package](/docs/iac/concepts/packages/). Pulumi can also [consume OpenTofu modules directly](/docs/iac/guides/building-extending/using-existing-tools/use-terraform-module/), automatically installing and invoking OpenTofu to execute them — useful for teams that have invested heavily in module libraries and want to keep using them while moving to Pulumi. ### Automation API diff --git a/content/docs/iac/comparisons/terraform/_index.md b/content/docs/iac/comparisons/terraform/_index.md index e9111bcda220..d552b3a66fe2 100644 --- a/content/docs/iac/comparisons/terraform/_index.md +++ b/content/docs/iac/comparisons/terraform/_index.md @@ -38,7 +38,7 @@ Terraform is an infrastructure as code tool created by HashiCorp (acquired by IB | Feature | Pulumi | Terraform | | --- | --- | --- | -| Language support | Python, TypeScript, JavaScript, Go, .NET, Java, and YAML — general-purpose languages with familiar syntax for loops, conditionals, and abstractions | HashiCorp Configuration Language (HCL) — a configuration-focused DSL whose syntax for control flow and dynamic blocks grows harder to read as project complexity increases | +| Language support | Python, TypeScript, JavaScript, Go, .NET, Java, and YAML — general-purpose languages with familiar syntax for loops, conditionals, and abstractions | HashiCorp Configuration Language (HCL) — a configuration-focused DSL with its own syntax for control flow and dynamic blocks | | Cloud and service support | [Pulumi Registry](/registry/) of packages, including [bridged, native, parameterized, and dynamic providers](/docs/iac/concepts/providers/#types-of-providers); schema-generated native providers include [Kubernetes](/registry/packages/kubernetes/), [Azure Native](/registry/packages/azure-native/), [AWS Cloud Control](/registry/packages/aws-native/), and [Google Cloud Native](/registry/packages/google-native/); [any Terraform provider](/docs/iac/concepts/providers/any-terraform-provider/) can be adapted into a Pulumi provider | HashiCorp- and community-maintained providers in the [Terraform Registry](https://registry.terraform.io/) | | Transpiled to another format? | No — programs run directly in their host language | No — HCL is interpreted directly by the Terraform CLI | | State management | [Managed by Pulumi Cloud by default](/docs/iac/concepts/state-and-backends/); self-managed backends include S3, Azure Blob Storage, Google Cloud Storage, local files, and others | Local files by default; remote backends include S3, Azure Blob Storage, Google Cloud Storage, Consul, and HCP Terraform's [managed state](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/state) | @@ -56,7 +56,7 @@ Terraform is an infrastructure as code tool created by HashiCorp (acquired by IB ### Language support and the authoring experience -Terraform requires HCL, a domain-specific language designed for configuration. HCL fits compactly into small projects but lacks the abstractions of a general-purpose language: there are no classes, limited runtime logic, and reuse only through the module system. Pulumi programs are written in general-purpose languages, so authors get loops, conditionals, classes, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems. Pulumi also supports [YAML](/docs/iac/languages-sdks/yaml/) for users who prefer a markup format. +Terraform uses HCL, a domain-specific language designed for configuration. HCL is compact and configuration-focused, with reuse through its module system. General-purpose languages offer a different model, with classes, richer runtime logic, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems, so Pulumi lets you pick the approach that fits the project. Pulumi supports HCL natively as well, alongside [YAML](/docs/iac/languages-sdks/yaml/) for users who prefer a markup format. ### Provider and cloud coverage diff --git a/content/docs/iac/get-started/terraform/convert-hcl.md b/content/docs/iac/get-started/terraform/convert-hcl.md index 87a956cb254d..80288fefc038 100644 --- a/content/docs/iac/get-started/terraform/convert-hcl.md +++ b/content/docs/iac/get-started/terraform/convert-hcl.md @@ -17,7 +17,7 @@ aliases: Converting HCL to Pulumi code makes sense in several scenarios: -* **Complex logic**: Terraform's HCL limitations make certain operations difficult +* **Complex logic**: Operations that need rich runtime logic can be more natural in a general-purpose language * **Testing requirements**: You need unit testing capabilities for infrastructure code * **Integration needs**: Infrastructure code needs to integrate with application code * **Team preferences**: Your team prefers general-purpose programming languages diff --git a/content/docs/iac/get-started/terraform/first-look.md b/content/docs/iac/get-started/terraform/first-look.md index e7d9af2739c0..d95f8a36fbcf 100644 --- a/content/docs/iac/get-started/terraform/first-look.md +++ b/content/docs/iac/get-started/terraform/first-look.md @@ -41,7 +41,7 @@ output "latest_ubuntu_ami_name" { } ``` -If you run this Terraform config, you should see output showing the latest Ubuntu AMI information. However, it's important to note that HCL is *not* a programming language. It is a configuration language, similar to YAML or JSON, with a bit more expressiveness and modularization capabilities. In Pulumi, you use general purpose programming languages to express your desired state of your cloud resources, in the context of a Pulumi program. +If you run this Terraform config, you should see output showing the latest Ubuntu AMI information. HCL is a configuration language, similar in spirit to YAML or JSON but with more expressiveness and modularization. Pulumi lets you describe the same desired state in a general-purpose programming language (and supports HCL and YAML too), so you can choose the style that fits your team. ## Pulumi programs diff --git a/content/events/accelerating-ai-powered-app-modernization-with-pulumi-on-google-cloud/index.md b/content/events/accelerating-ai-powered-app-modernization-with-pulumi-on-google-cloud/index.md index 8d6b58cb0a61..867bbb32205a 100644 --- a/content/events/accelerating-ai-powered-app-modernization-with-pulumi-on-google-cloud/index.md +++ b/content/events/accelerating-ai-powered-app-modernization-with-pulumi-on-google-cloud/index.md @@ -45,7 +45,7 @@ description: | As enterprises race to modernize their applications for the AI era, the complexity of managing cloud infrastructure has become a critical bottleneck. This hands-on workshop demonstrates how Google Cloud customers can accelerate their app modernization journey by leveraging Pulumi's developer-first Infrastructure as Code approach alongside Google Cloud's cutting-edge AI services. Unlike traditional infrastructure tools like Terraform, which were built for operators, creating friction between development and DevOps teams. Pulumi revolutionizes this paradigm by empowering developers to manage Google Cloud resources using familiar programming languages, such as Python, TypeScript, Go, C#, and Java. - No need to learn HCL or file tickets, just build, deploy, and iterate faster with code. + Build, deploy, and iterate with the languages you already know, no ticket queues required. learn: - Deploy AI/ML workloads on Google Cloud using Pulumi's intuitive programming model - Leverage Google Cloud's Vertex AI, GKE, and Cloud Run with familiar development practices diff --git a/content/events/getting-started-with-aws-java/index.md b/content/events/getting-started-with-aws-java/index.md index 3970972320f5..8cd845e861f7 100644 --- a/content/events/getting-started-with-aws-java/index.md +++ b/content/events/getting-started-with-aws-java/index.md @@ -42,7 +42,7 @@ location: virtual # Description of the event. description: | - In this workshop, you'll discover how Pulumi empowers Java development teams to confidently manage cloud infrastructure while maintaining enterprise-grade security and control. As organizations face increasing complexity in cloud operations, Pulumi's Cloud Engineering platform offers a natural path forward by allowing your developers to use familiar Java skills to manage cloud resources - eliminating the need to learn new domain-specific languages. + In this workshop, you'll discover how Pulumi empowers Java development teams to confidently manage cloud infrastructure while maintaining enterprise-grade security and control. As organizations face increasing complexity in cloud operations, Pulumi's Cloud Engineering platform offers a natural path forward by allowing your developers to use familiar Java skills to manage cloud resources without picking up a separate domain-specific language. This session is designed for engineering leaders and developers looking to modernize their cloud infrastructure practices. Through practical demonstrations and real-world examples, you'll see how Pulumi's enterprise platform streamlines cloud operations by unifying infrastructure management, security controls, and secrets management in a single dashboard. We'll also explore proven strategies for adopting Pulumi within your organization, including practical approaches for transitioning from existing tools like Terraform while maintaining business continuity. diff --git a/content/events/getting-started-with-iac-on-aws-python/index.md b/content/events/getting-started-with-iac-on-aws-python/index.md index c310377a7815..2ebbe5a2491e 100644 --- a/content/events/getting-started-with-iac-on-aws-python/index.md +++ b/content/events/getting-started-with-iac-on-aws-python/index.md @@ -42,7 +42,7 @@ location: virtual # Description of the event. description: | - This workshop offers a hands-on exploration of how modern infrastructure management can be streamlined using familiar programming languages. In this workshop, you'll discover how Pulumi empowers developers and operations teams to define cloud infrastructure using Python - eliminating the need to learn domain-specific languages while unlocking the full power of software engineering practices for infrastructure code. + This workshop offers a hands-on exploration of how modern infrastructure management can be streamlined using familiar programming languages. In this workshop, you'll discover how Pulumi empowers developers and operations teams to define cloud infrastructure using Python, so teams can apply familiar software engineering practices to infrastructure code without adopting a separate domain-specific language. Participants will experience firsthand how Pulumi's approach bridges the gap between application and infrastructure development, allowing teams to manage AWS resources with the same tools, practices, and languages they already use for application development. This workshop demonstrates how this unified approach not only accelerates productivity but enables organizations to build more reliable, scalable, and secure cloud architectures. diff --git a/content/events/migrating-iac-terraform-to-typescript/index.md b/content/events/migrating-iac-terraform-to-typescript/index.md index 3be1db721b00..f0349c8425f5 100644 --- a/content/events/migrating-iac-terraform-to-typescript/index.md +++ b/content/events/migrating-iac-terraform-to-typescript/index.md @@ -42,14 +42,14 @@ location: virtual # Description of the event. description: | - Organizations often find themselves constrained by domain-specific languages when managing cloud infrastructure, leading to complex workarounds and maintenance challenges. This workshop demonstrates how transitioning to a general-purpose programming language can transform your infrastructure management, making common tasks more intuitive and maintainable. + Teams managing cloud infrastructure sometimes want the flexibility of a general-purpose language for complex workflows and long-term maintainability. This workshop demonstrates how transitioning to a general-purpose programming language can transform your infrastructure management, making common tasks more intuitive and maintainable. You'll discover how TypeScript's rich ecosystem of libraries and familiar syntax can simplify everything from dynamic resource creation to complex configuration management. Through practical examples, we'll explore strategies for gradually migrating existing infrastructure code while maintaining operational stability. Whether you're dealing with repetitive boilerplate, struggling with complex state management, or seeking more flexibility in your infrastructure automation, you'll learn how to leverage TypeScript's capabilities to build more elegant and powerful infrastructure solutions that scale with your organization's needs. learn: - - How general-purpose languages like TypeScript make infrastructure management easier compared to domain-specific languages like HCL and YAML + - How a general-purpose language like TypeScript can simplify common infrastructure tasks for teams that prefer one - How to introduce Pulumi IaC and either coexist with or convert your existing Terraform code - How Pulumi's advanced features can help enable even greater capabilities for your organization to keep teams moving fast, securely diff --git a/content/gads/opentofu/index.md b/content/gads/opentofu/index.md index 138093a90c69..1dd20f953b4d 100644 --- a/content/gads/opentofu/index.md +++ b/content/gads/opentofu/index.md @@ -1,6 +1,6 @@ --- title: "OpenTofu Alternative | Pulumi" -meta_desc: "You chose open source for the license. Now choose real languages over HCL. Pulumi is Apache 2.0, no resource caps, 170+ providers." +meta_desc: "Open source, with your choice of language. Use Python, TypeScript, Go, or C# alongside HCL. Pulumi is Apache 2.0, no resource caps, 170+ providers." layout: gads-template block_external_search_index: true hide_platform_details: true @@ -21,8 +21,8 @@ customer_quote: link: /case-studies/snowflake overview: - title: "You Left HCL's License.
Now Leave Its Limits." - description: 'Looking for an OpenTofu alternative? OpenTofu solved the licensing problem but you still write HCL. Pulumi is also Apache 2.0 open source, but uses Python, TypeScript, Go, or C# with real testing, IDE support, and 170+ providers. Pulumi Cloud manages OpenTofu state directly.' + title: "Open Source, and the Language of Your Choice" + description: 'Looking for an OpenTofu alternative? OpenTofu solved the licensing question. Pulumi is open source too, under the permissive Apache 2.0 license, and it adds a choice of language: author in Python, TypeScript, Go, or C# with testing, IDE support, and 170+ providers, or keep writing HCL, now supported natively. Pulumi Cloud manages OpenTofu state directly.' key_features_above: items: diff --git a/content/gads/python-iac/index.md b/content/gads/python-iac/index.md index b9db6f733199..d1fddf6625fe 100644 --- a/content/gads/python-iac/index.md +++ b/content/gads/python-iac/index.md @@ -20,7 +20,7 @@ customer_quote: link: /case-studies/supabase/ overview: - title: Write Cloud Infrastructure in Python.
Not YAML. Not HCL. + title: Write Cloud Infrastructure in Python. description: | Looking for infrastructure as code python? Define AWS, Azure, GCP, and Kubernetes resources in Python with full IDE support, type checking, and testing. 170+ cloud providers. Free tier. diff --git a/content/gads/terraform-migration/index.md b/content/gads/terraform-migration/index.md index f53c5a7103a7..b2abc859a37d 100644 --- a/content/gads/terraform-migration/index.md +++ b/content/gads/terraform-migration/index.md @@ -26,7 +26,7 @@ overview: key_features_above: items: - - title: "Convert HCL to real code with tf2pulumi" + - title: "Convert HCL to Python, TypeScript, Go, or C# with tf2pulumi" sub_title: "Free Migration Tools" description: Use the free tf2pulumi converter to turn Terraform .tf files into Pulumi programs in Python, TypeScript, Go, or C#. No resource caps. No forced deadlines. Keep your current infrastructure running while you migrate. @@ -108,7 +108,7 @@ key_features: Use tf2pulumi to convert your existing Terraform HCL to Python, TypeScript, Go, or C#. Import existing state with pulumi import. Keep your current infrastructure running while you migrate at your own pace. No forced deadlines. No resource caps. image: "/images/product/pulumi-iac-code.png" features: - - title: Convert HCL to real code + - title: Convert HCL to a general-purpose language icon: exchange description: | The tf2pulumi tool converts your .tf files to Pulumi programs in your language of choice. [Try it at pulumi.com/migrate/tf2pulumi](/migrate/tf2pulumi/). diff --git a/content/gads/terraform/index.md b/content/gads/terraform/index.md index 8e249c9b5b91..ffea895c96ed 100644 --- a/content/gads/terraform/index.md +++ b/content/gads/terraform/index.md @@ -1,6 +1,6 @@ --- title: "Terraform Alternative | Pulumi" -meta_desc: "Use Python, TypeScript, Go, or C# instead of HCL. Free migration tools, no resource caps on the free tier, 170+ cloud providers." +meta_desc: "Use Python, TypeScript, Go, or C# — or HCL — for infrastructure as code. Free migration tools, no resource caps on the free tier, 170+ cloud providers." layout: gads-template block_external_search_index: true hide_platform_details: true @@ -21,16 +21,16 @@ customer_quote: link: /case-studies/snowflake overview: - title: Real Languages. No Resource Caps.
Migrate at Your Pace. + title: Your Choice of Language. No Resource Caps.
Migrate at Your Pace. description: | Looking for a Terraform alternative? HCP Terraform's free tier caps you at 500 managed resources. Pulumi Cloud has no resource caps. Write infrastructure in Python, TypeScript, Go, or C# with full IDE support, testing, and 170+ cloud providers. Free tf2pulumi migration tool included. key_features_above: items: - - title: "Switch from HCL to real languages" + - title: "Author infrastructure in the language you prefer" sub_title: "Pulumi Infrastructure as Code Engine" description: - Stop writing HCL. Author infrastructure as code using programming languages you already know, including Python, TypeScript, Go, C#, Java, and YAML. Use the free tf2pulumi converter to migrate your existing Terraform files. Deploy to 170+ providers. + Author infrastructure as code using programming languages you already know, including Python, TypeScript, Go, C#, Java, and YAML. Bring your existing Terraform along with the free tf2pulumi converter. Deploy to 170+ providers. features: - title: Code faster description: | @@ -58,7 +58,7 @@ key_features: Use tf2pulumi to convert your existing Terraform HCL to Python, TypeScript, Go, or C#. Import existing state with pulumi import. Keep your current infrastructure running while you migrate at your own pace. No forced deadlines. No resource caps. image: "/images/product/pulumi-iac-code.png" features: - - title: Convert HCL to real code + - title: Convert HCL to a general-purpose language icon: exchange description: | The tf2pulumi tool converts your .tf files to Pulumi programs in your language of choice. Try it at [pulumi.com/tf2pulumi](/tf2pulumi/). diff --git a/content/migrate/tf2pulumi.md b/content/migrate/tf2pulumi.md index 3b47a8ef265d..f9f4c216064b 100644 --- a/content/migrate/tf2pulumi.md +++ b/content/migrate/tf2pulumi.md @@ -1,5 +1,5 @@ --- -title: Convert Your Terraform to a Modern Language +title: Convert Your Terraform to the Language of Your Choice url: /tf2pulumi layout: tf2pulumi linktitle: Terraform to Pulumi @@ -9,7 +9,7 @@ menu: weight: 4 aliases: - /migrate/tf2pulumi -meta_desc: See what your Terraform HCL would look like in a modern language thanks to Pulumi. +meta_desc: See what your Terraform HCL would look like in Python, TypeScript, Go, or C# with Pulumi. examples: - name: AWS EC2 Instance filename: main.tf diff --git a/content/product/superintelligence-infrastructure.md b/content/product/superintelligence-infrastructure.md index d717c1c194b0..9930e2d8f4e0 100644 --- a/content/product/superintelligence-infrastructure.md +++ b/content/product/superintelligence-infrastructure.md @@ -67,9 +67,9 @@ features: casestudy: title: Trusted for building AI products at massive scale supabase: - title: From Terraform's configuration language to 80K resources in real code + title: From Terraform HCL to 80,000 resources in Pulumi description: | - Supabase needed infrastructure that could scale without operational overhead. Terraform's HCL meant constant context switching between TypeScript (application services) and a proprietary configuration language (infrastructure). + Supabase needed infrastructure that could scale without operational overhead. With Terraform, the team context-switched between TypeScript for application services and HCL for infrastructure, and wanted one language across both. After migrating to Pulumi: - **Regional expansion**: 1 week to infrastructure readiness @@ -100,7 +100,7 @@ enablement: body: | Pulumi's code-native architecture creates a fundamental advantage: AI systems can read, write, and optimize infrastructure written in Python, TypeScript, or Go. The same languages used to train large language models. - This isn't AI translating natural language into proprietary configuration syntax. This is AI working directly with production infrastructure code. + Neo works directly with your production infrastructure code, in the same general-purpose languages your engineers already use. subheader: "Neo: AI-powered infrastructure operations, grounded in reality" subbody: | Once you're managing infrastructure with Pulumi, Neo automates the operations that slow development cycles. Neo is grounded in Pulumi's 2+ petabyte corpus of real production infrastructure deployments. While generic AI tools can hallucinate plausible-sounding configurations, Neo draws on battle-tested patterns from billions of real cloud resources: @@ -109,7 +109,7 @@ enablement: - **Drift remediation** detects and fixes configuration drift in GPU clusters based on how teams actually manage these resources at massive scale - **Multi-cloud migration** converts AWS SageMaker infrastructure to Azure ML or GCP Vertex AI using production-ready patterns closing: | - **The code-native advantage:** LLMs are trained on real code, not proprietary configuration languages. Pulumi IS code. This enables fundamentally deeper AI integration than tools that require translation layers. + **The code-native advantage:** LLMs are trained extensively on general-purpose languages like Python and TypeScript, so AI tools can read and write Pulumi programs directly, in the same languages your engineers use. cta: "Get started with Neo" link: /docs/pulumi-cloud/neo/get-started/ image: /images/product/hcl-to-pulumi.png @@ -120,19 +120,19 @@ capabilities: description: | Infrastructure written in Python, TypeScript, and Go. The same languages your ML engineers already know. - No proprietary configuration languages. + Author in Python, TypeScript, Go, or C#, with HCL available when you prefer it. building_blocks: title: "Why AI infrastructure requires dynamic orchestration" items: - - header: "Static configuration languages (Terraform HCL)" + - header: "Static configuration (Terraform HCL)" body: - Designed for long-lived resources that change infrequently - - Cannot dynamically rebalance GPU capacity as workloads shift - - Proprietary DSL requires learning syntax separate from application development - - "AI tools must translate natural language → DSL → infrastructure (abstraction overhead)" - - "Limited to configuration-specific operations; can't leverage full programming language ecosystems" - - Testing requires DSL-specific tools and frameworks + - Rebalancing GPU capacity as workloads shift means regenerating and reapplying configuration + - Uses a declarative syntax that's separate from application development + - AI tools translate intent into configuration syntax before it reaches your infrastructure + - Logic and reuse come from the tool's built-in functions and module system + - Testing uses the tool's own frameworks - header: Code-native infrastructure (Pulumi) subheader: "Ask questions about your infrastructure and get actionable answers:" body: diff --git a/content/what-is/javascript-and-infrastructure-as-code.md b/content/what-is/javascript-and-infrastructure-as-code.md index 05603b87fadd..0e28e7460247 100644 --- a/content/what-is/javascript-and-infrastructure-as-code.md +++ b/content/what-is/javascript-and-infrastructure-as-code.md @@ -51,7 +51,7 @@ A few practical reasons drive most adoptions: * **The team already knows it.** Most full-stack and frontend-heavy organizations already run Node.js in production. Using the same language for IaC means no new training, no new style guides, no new package manager. * **The npm ecosystem is huge.** Thousands of utility libraries, validators, AWS/GCP/Azure SDK clients, retry helpers, schema validators, and logging libraries are already published, tested, and vetted at scale. -* **Real abstractions, not text templates.** Functions, classes, modules, generics. A repeating VPC pattern becomes a Pulumi component you import, not a folder of copy-pasted HCL. +* **Real abstractions, not text templates.** Functions, classes, modules, generics. A repeating VPC pattern becomes a Pulumi component you import and parameterize, rather than a module you copy and edit. * **Real testing tools.** Jest, Vitest, ts-mocha, supertest. Unit tests for IaC use the same runners you already configured for the application code. * **Real IDE support.** Autocomplete, jump-to-definition, refactoring, inline error squiggles. The same VS Code or WebStorm experience that helps with app code helps with cloud APIs that have hundreds of optional properties. @@ -71,7 +71,7 @@ Pulumi templates generate TypeScript projects by default for this reason. The ru ## What does JS/TS offer that an IaC DSL doesn't? -DSLs like HCL or CloudFormation YAML are deliberately limited: no functions, limited loops, no real type system, no module system other than what the DSL provides. That keeps the surface area small at the cost of expressiveness. JS/TS gives back what the DSL took away: +DSLs like HCL or CloudFormation YAML keep their surface area small on purpose. They favor a constrained, declarative model, and general-purpose languages trade that simplicity for functions, richer loops, and a type system. JS/TS gives you those when you want them: * **Loops and conditionals that compose.** A subnet per availability zone, a Lambda per region, or a Kubernetes namespace per tenant, all expressed as familiar `.map()` and `for` loops rather than DSL-specific iteration features. * **Abstractions you actually own.** A Pulumi component is just a TypeScript class. It can take typed inputs, build any combination of underlying resources, and expose typed outputs. You can publish it to npm, version it semantically, and depend on it from many stacks. diff --git a/content/what-is/top-iac-tools.md b/content/what-is/top-iac-tools.md index 0dcfb9c1459d..1b0981a00164 100644 --- a/content/what-is/top-iac-tools.md +++ b/content/what-is/top-iac-tools.md @@ -29,13 +29,13 @@ Multi-cloud solutions prevent vendor lock-in, maintain flexibility, and promote ### [Terraform](https://www.terraform.io/) -Terraform is a multi-cloud Infrastructure as Code (IaC) tool that utilizes the HashiCorp Configuration Language (HCL). HCL is designed to be both human-readable and machine-friendly, striking a balance between simplicity and power. While it lacks some of the advanced programming constructs of general-purpose languages, HCL offers a declarative approach that many find intuitive for infrastructure definition. HCL lacks full programming constructs, which may necessitate workarounds for handling complex logic. +Terraform is a multi-cloud Infrastructure as Code (IaC) tool that utilizes the HashiCorp Configuration Language (HCL). HCL is designed to be both human-readable and machine-friendly, striking a balance between simplicity and power. It offers a declarative approach that many find intuitive for infrastructure definition, and its constrained model keeps definitions readable. Complex logic that needs loops or conditionals is typically handled through HCL's own meta-arguments or by composing modules. For state management, Terraform uses a state file to track the current state of your infrastructure. While this approach requires manual configuration, including setting up remote backends and state locking, it does offer fine-grained control over state. Terraform integrates well with existing development workflows and CI/CD pipelines. A Kubernetes provider exists that supports the Kubernetes Core APIs and offers some support for Custom Resource Definitions (CRDs). Terraform is popular, with a large ecosystem and also has a wide range of plugins, integrations, and comprehensive documentation. -- **Flexibility**: Utilizes HCL. Lacks full programming constructs. +- **Flexibility**: Uses HCL, a declarative configuration language purpose-built for infrastructure. - **Multi-cloud**: Offers support for AWS, Azure, GCP, Oracle cloud and many others. - **State**: Provides fine-grained control over state management, but requires manual configuration including remote backends and state locking, which can add complexity to collaboration. - **Integration**: Integrates well with existing development workflows and CI/CD pipelines. Provides a Kubernetes provider for basic cluster management. @@ -97,7 +97,7 @@ Managing complex templates can be challenging, and template size limitations and Azure Resource Manager (ARM) supports JSON-based configuration or using Bicep - an ARM-specific DSL. ARM integrates deeply with Azure services including Azure DevOps, and can be integrated with other CI/CD workflows using its `az` cli tool. ARM provides comprehensive support for Kubernetes features through Azure Kubernetes Service (AKS), Self-managed Kubernetes clusters on Azure are not included, however. Azure Resource Manager is preferred by those who want a native Azure tool and are deeply invested in the Azure ecosystem. -- **Flexibility**: Uses JSON-based templates or Bicep - a DSL. Lacks some of the abstraction and modularity of other tools. +- **Flexibility**: Uses JSON-based templates or Bicep, a DSL focused on Azure. Other tools offer more cross-cutting abstraction and modularity. - **Integration**: Offers deep integration with Azure services, including Azure DevOps and Azure Kubernetes Service. Broader integration to non-Azure CI/CD is possible, while native Kubernetes cluster support is not. - **Ecosystem**: Supported by documentation, tutorials and troubleshooting advice and by the greater Azure ecosystem. diff --git a/content/what-is/what-is-agentic-infrastructure.md b/content/what-is/what-is-agentic-infrastructure.md index 254ea7527140..98e0ad7e5a55 100644 --- a/content/what-is/what-is-agentic-infrastructure.md +++ b/content/what-is/what-is-agentic-infrastructure.md @@ -42,7 +42,7 @@ Three things follow from this: **Agents get richer training signal.** Public Python and TypeScript include genuinely production-scale open source: real patterns at large scale, not tutorial snippets. A model that has learned from millions of Python programs brings that experience to bear when writing infrastructure code in Python. Infrastructure DSL corpora are much thinner, and skew toward documentation examples rather than production usage. -**Agents can use real software engineering primitives.** Loops, functions, classes, package imports, unit tests, type checking, IDE tooling: these apply to Pulumi programs the same way they apply to application code. An agent writing a Pulumi program can import a library, write a test, refactor a module, or inherit from a base class. It's not limited to what a configuration language can express. +**Agents can use real software engineering primitives.** Loops, functions, classes, package imports, unit tests, type checking, IDE tooling: these apply to Pulumi programs the same way they apply to application code. An agent writing a Pulumi program can import a library, write a test, refactor a module, or inherit from a base class. It can reach for software-engineering primitives that go beyond what a configuration language is designed to express. **Every change is verifiable.** `pulumi preview` maps code changes to a concrete, auditable list of resource operations (what will be created, updated, or deleted) before anything in the cloud changes. An agent can verify its own output. That feedback loop (write, preview, validate, adjust) is what makes autonomous infrastructure tractable at scale. As Duffy notes: "Just as we wouldn't vibe code without git showing us the source changes, we shouldn't vibe infrastructure without a tool that shows what it will do before it does it, and what it has already done in the past." It's essentially `git diff` for your cloud. diff --git a/content/what-is/what-is-infrastructure-as-code.md b/content/what-is/what-is-infrastructure-as-code.md index f8c54c68f5ff..27c6a1fa7447 100644 --- a/content/what-is/what-is-infrastructure-as-code.md +++ b/content/what-is/what-is-infrastructure-as-code.md @@ -160,7 +160,7 @@ Declarative is the more common style for cloud infrastructure because the lifecy The key elements of infrastructure as code are the same key elements you'd find in the majority of software engineering environments. These include: -1. **An infrastructure as code mechanism:** For all practical purposes, in order to do infrastructure as code you need a tool or engine that is responsible for translating the IaC instructions into something the cloud provider APIs understand and can use. Infrastructure as code tools may be provided by and limited to a single cloud provider (AWS CloudFormation is one example), or may support multiple cloud providers. Tools may be limited to supporting YAML or JSON; may require the use of a specialized and proprietary domain-specific language (DSL); or may support the use of general purpose programming languages such as TypeScript/JavaScript, C#, Go, Python, and Java. +1. **An infrastructure as code mechanism:** For all practical purposes, in order to do infrastructure as code you need a tool or engine that is responsible for translating the IaC instructions into something the cloud provider APIs understand and can use. Infrastructure as code tools may be provided by and limited to a single cloud provider (AWS CloudFormation is one example), or may support multiple cloud providers. Tools may be limited to supporting YAML or JSON; may require a purpose-built domain-specific language (DSL); or may support general-purpose programming languages such as TypeScript/JavaScript, C#, Go, Python, and Java. 1. **Version control:** When infrastructure is described as code, it can be checked into source control, versioned and code-reviewed using existing software engineering practices. Version control systems, like [GitHub](https://github.com/), [GitLab](https://about.gitlab.com/), or [BitBucket](https://bitbucket.org/), enable you to see _what_ changes were made, _when_ the changes were made, and _who_ made the changes. 1. **Tests:** As any critical system grows in complexity, people can start to feel nervous about making changes. With infrastructure as code, teams can write tests for their infrastructure to ensure its correctness. They can encode policies so that all provisioned infrastructure and its configurations [are compliant](/docs/iac/guides/testing/property-testing/). Once they're tested, infrastructure components can be reusable pieces of code that capture best practices and that can be shared across teams. No more reinventing the wheel. 1. **CI/CD pipelines:** Assuming the infrastructure as code tool supports the functionality (most do), changes to infrastructure (found in changes to the code that defines the infrastructure) can be deployed using existing CI/CD tools, much in the same way CI/CD pipelines automatically build and deploy other forms of software. diff --git a/content/what-is/what-is-infrastructure-as-software.md b/content/what-is/what-is-infrastructure-as-software.md index ba295a0a6cf2..35b614451b43 100644 --- a/content/what-is/what-is-infrastructure-as-software.md +++ b/content/what-is/what-is-infrastructure-as-software.md @@ -29,7 +29,7 @@ customer_logos: authors: ["cam-soper"] --- -**Infrastructure as Software (IaS) is the practice of defining cloud infrastructure in general-purpose programming languages and applying the full toolchain of modern software engineering to it: real types, real abstractions, real tests, real package management, real APIs, and real CI/CD.** It's the natural next step after [infrastructure as code (IaC)](/what-is/what-is-infrastructure-as-code/), which uses domain-specific languages (DSLs) or markup formats like HCL, JSON, and YAML, and which makes most of these engineering practices either awkward or unavailable. +**Infrastructure as Software (IaS) is the practice of defining cloud infrastructure in general-purpose programming languages and applying the full toolchain of modern software engineering to it: real types, real abstractions, real tests, real package management, real APIs, and real CI/CD.** It's the natural next step after [infrastructure as code (IaC)](/what-is/what-is-infrastructure-as-code/), which uses domain-specific languages (DSLs) or markup formats like HCL, JSON, and YAML. Those formats keep infrastructure declarative and approachable, and some software-engineering practices (rich abstraction, in-language testing, packaging) are harder to apply directly in them. The two terms overlap in intent. They both aim to replace manual cloud operations with reviewable, automated, reproducible code. They differ in *how much code engineering* you can do once your infrastructure is in code. IaS treats every cloud resource as a software object whose lifecycle can be programmed, abstracted, tested, packaged, and called from other programs. That last property is the one that opens up automation patterns DSL-based IaC can't reach: building self-service portals, embedding `pulumi up` inside a SaaS product, and using the same APIs internally that Pulumi itself uses. @@ -48,7 +48,7 @@ In this article, we'll cover the key questions about infrastructure as software: DSL-based IaC was a big jump forward in the 2010s. It introduced versioning, code review, and reproducible environments to cloud operations. Three pressures since then have stretched its limits and motivated the move toward IaS: -* **Sophisticated, multi-layer architectures.** A typical service today spans containers, Kubernetes, serverless functions, managed databases, message brokers, secrets, IAM, DNS, and CDN. Composing all of those in a DSL turns into thousands of lines of templates and external glue. A general-purpose language can express the same composition in dozens of lines of typed code. +* **Sophisticated, multi-layer architectures.** A typical service today spans containers, Kubernetes, serverless functions, managed databases, message brokers, secrets, IAM, DNS, and CDN. Composing all of those in a DSL can grow into many lines of templates plus external glue, where a general-purpose language can factor the same composition into typed, reusable functions. * **Ephemeral and dynamic infrastructure.** Cloud resources change daily or hourly. Templating engines and string interpolation in YAML weren't designed for that pace; real loops, conditionals, and types are. * **Self-service platforms.** Platform engineering teams need to expose cloud capabilities to product teams through forms, APIs, and chat commands, not by handing them HCL files. Doing that on top of a DSL means writing a templating shim; doing it on top of a programming language means importing the IaC as a library. diff --git a/content/what-is/what-is-pulumi.md b/content/what-is/what-is-pulumi.md index d39209af7cb9..6591de3c16ba 100644 --- a/content/what-is/what-is-pulumi.md +++ b/content/what-is/what-is-pulumi.md @@ -7,15 +7,15 @@ page_title: "What is Pulumi?" authors: ["asaf-ashirov"] --- -The modern cloud landscape has transformed how organizations build and deploy applications, but managing cloud infrastructure often remains a complex, error-prone process involving clicking through web consoles, writing brittle scripts, or learning domain-specific languages. Pulumi emerges as a solution that fundamentally changes this paradigm by enabling developers and infrastructure teams to manage cloud resources using the same programming languages they already know and love. +The modern cloud landscape has transformed how organizations build and deploy applications, but managing cloud infrastructure often remains a complex, error-prone process involving clicking through web consoles, writing brittle scripts, or learning a new tool-specific language. Pulumi emerges as a solution that fundamentally changes this paradigm by enabling developers and infrastructure teams to manage cloud resources using the same programming languages they already know and love. -Pulumi is a cloud engineering platform that treats infrastructure as software, allowing teams to define, deploy, and manage cloud resources using familiar programming languages like TypeScript, Python, Go, C#, Java, and YAML. Rather than forcing teams to learn proprietary configuration languages or rely on limited templating systems, Pulumi brings the full power of modern software development practices to infrastructure management. +Pulumi is a cloud engineering platform that treats infrastructure as software, letting teams define, deploy, and manage cloud resources using familiar programming languages like TypeScript, Python, Go, C#, Java, and YAML, plus HCL as a first-class option. Whichever language a team chooses, Pulumi brings the full power of modern software development practices to infrastructure management. ## The evolution of infrastructure management To understand Pulumi's significance, it's helpful to consider how infrastructure management has evolved. In the early days of cloud computing, infrastructure was typically managed through web consoles or command-line interfaces. While functional, this approach suffered from poor repeatability, limited collaboration capabilities, and difficulty tracking changes over time. -The introduction of infrastructure as code (IaC) tools like Terraform and AWS CloudFormation represented a significant improvement, enabling teams to define infrastructure declaratively and version control their configurations. However, these tools introduced their own challenges through domain-specific languages that required additional learning curves and offered limited expressiveness compared to general-purpose programming languages. +The introduction of infrastructure as code (IaC) tools like Terraform and AWS CloudFormation represented a significant improvement, enabling teams to define infrastructure declaratively and version control their configurations. These tools introduced domain-specific languages with their own learning curves. They favor a constrained, declarative model, while general-purpose languages trade that simplicity for richer abstraction and reuse. Pulumi represents the next evolution in this space by embracing what the company calls "infrastructure as software." This approach enables teams to leverage the full software engineering ecosystem (including testing frameworks, package managers, IDEs, and development workflows) when managing their cloud infrastructure. @@ -73,9 +73,9 @@ Pulumi AWSx components represent opinionated, well-architected patterns for comm ## The power of real programming languages -One of Pulumi's most significant differentiators is its support for general-purpose programming languages rather than domain-specific languages. This design choice has profound implications for how teams approach infrastructure management. +One of Pulumi's defining features is the breadth of languages it supports: general-purpose languages like TypeScript, Python, Go, C#, and Java, alongside YAML and HCL. Teams can pick the language that best fits how they already work, which shapes how they approach infrastructure management. -Using familiar programming languages means developers can apply existing skills and knowledge to infrastructure problems. They can leverage the full ecosystem of language features, including package managers, testing frameworks, and development tools. This approach eliminates the need to learn proprietary configuration languages and enables teams to create more sophisticated, maintainable infrastructure code. +Using familiar programming languages means developers can apply existing skills and knowledge to infrastructure problems. They can use the full ecosystem of language features, including package managers, testing frameworks, and development tools, while still reaching for declarative formats like YAML or HCL when those fit better. The result is infrastructure code that's easier to maintain and build on. The ability to use standard programming constructs like loops, conditionals, and functions enables dynamic infrastructure definitions that would be difficult or impossible with templating-based approaches. For example, you might programmatically create resources based on environment variables, implement complex business logic within your infrastructure code, or generate resources based on external data sources. @@ -141,7 +141,7 @@ These success stories demonstrate how Pulumi enables organizations to achieve su When compared to established infrastructure as code tools, Pulumi offers several distinct advantages that address common pain points in infrastructure management. -Traditional tools like Terraform require teams to learn domain-specific languages with limited expressiveness compared to general-purpose programming languages. Pulumi's approach enables teams to leverage existing language skills while providing access to the full ecosystem of development tools and practices. +Tools like Terraform center on a domain-specific language built for IaC. Pulumi lets teams use languages they already know, and now supports HCL as well, so adopting it builds on existing skills while providing access to the full ecosystem of development tools and practices. The testing capabilities represent another significant advantage. While some tools offer limited testing options, Pulumi's integration with language-native testing frameworks enables comprehensive testing strategies including unit tests, integration tests, and property-based testing approaches. diff --git a/content/whitepapers/enterprise-innovation-through-cloud-engineering.md b/content/whitepapers/enterprise-innovation-through-cloud-engineering.md index 60dee04e9207..c09e1db1c121 100644 --- a/content/whitepapers/enterprise-innovation-through-cloud-engineering.md +++ b/content/whitepapers/enterprise-innovation-through-cloud-engineering.md @@ -139,7 +139,7 @@ Pulumi promotes creating reusable and modular components which allows standard a #### Establishing software supply chain -The next step after building reusable and modular components is establishing a secure software supply chain for each of the components. Enterprises broadly implement software versioning and supply chain for application development. Pulumi brings true software versioning and a secure software supply chain to the way organizations manage infrastructure. Legacy markup and DSL toolchains have limited supply chain capabilities leading to configuration drift and insecure practices. Teams often copy-and-paste configuration changes, and when critical security misconfigurations happen in an environment, they need to manually track down all places in which the same configuration mistakes were copied. With Pulumi, an infrastructure change is versioned just like software. Out-of-date versions can be audited the same way, and rollouts can be performed using standard release techniques, giving teams confidence they aren’t running out of date configurations. +The next step after building reusable and modular components is establishing a secure software supply chain for each of the components. Enterprises broadly implement software versioning and supply chain for application development. Pulumi brings true software versioning and a secure software supply chain to the way organizations manage infrastructure. Markup- and template-based toolchains often have limited software supply-chain capabilities, which can lead to configuration drift when changes are copied between environments. Teams often copy-and-paste configuration changes, and when critical security misconfigurations happen in an environment, they need to manually track down all places in which the same configuration mistakes were copied. With Pulumi, an infrastructure change is versioned just like software. Out-of-date versions can be audited the same way, and rollouts can be performed using standard release techniques, giving teams confidence they aren’t running out of date configurations. #### Automating and orchestrating the control plane diff --git a/layouts/awsx/aws.html b/layouts/awsx/aws.html index 314a4dc9ece9..9e0cf79f3361 100644 --- a/layouts/awsx/aws.html +++ b/layouts/awsx/aws.html @@ -65,7 +65,7 @@

Modern Architectures like containers and serverless

Get up and running on "day one" with containers -- using Amazon Elastic Container Service (ECS), including "Fargate" or Kubernetes (EKS) -- or serverless -- using AWS Lambda or API Gateway. Benefit from secure and reliable defaults, and customize only where you need to.

-

With Pulumi's unique approach to infrastructure as code, you'll focus more on code and business logic, and less on DSL configuration languages.

+

With Pulumi's approach to infrastructure as code, you can focus on code and business logic while choosing the language that fits your team — general-purpose languages like TypeScript, Python, Go, and Java, or YAML and HCL.

Get Started

diff --git a/layouts/migrate/terraform.html b/layouts/migrate/terraform.html index 048359975db3..ec0b95a4a48f 100644 --- a/layouts/migrate/terraform.html +++ b/layouts/migrate/terraform.html @@ -10,7 +10,7 @@

The open source infrastructure as code platform

Pulumi is fully open source while Terraform is committed to the Business Source License, a restrictive source available license. - Pulumi uses general purpose programming languages and YAML that better help you tame cloud complexity and accelerate development velocity, rather than proprietary domain-specific languages (DSL) such as HashiCorp Configuration Language (HCL). + Pulumi lets you choose the approach that fits your team — general-purpose programming languages, YAML, or HashiCorp Configuration Language (HCL) — to tame cloud complexity and accelerate development velocity. See our Pulumi vs. Terraform guide for detailed differences between the two platforms.

diff --git a/layouts/migrate/tf2pulumi.html b/layouts/migrate/tf2pulumi.html index ae6729a1c48e..92504bda768d 100644 --- a/layouts/migrate/tf2pulumi.html +++ b/layouts/migrate/tf2pulumi.html @@ -2,8 +2,7 @@ {{ partial "hero" (dict "title" "Convert Your Terraform to Pulumi") }}

- If you already have some Terraform and want to see what it would look like in your favorite language, we've got you covered. This conversion tool will do the magic of - translating your HCL into modern code using Pulumi. + If you already have some Terraform and want to see what it would look like in your favorite language, we've got you covered. This conversion tool translates your HCL into Pulumi code in your favorite language.

{{ partial "convert" (dict "from" "tf" "examples" .Params.examples ) }} @@ -28,7 +27,7 @@

Learn More

Compare Pulumi to Terraform

- Pulumi is a comprehensive infrastructure as code platform. Instead of using a proprietary DSLs, you can use the industry's best languages and tools. + Pulumi is a comprehensive infrastructure as code platform. You can use general-purpose languages and tools, or HCL — whichever fits your workflow.

Learn how they compare
diff --git a/layouts/shortcodes/hcl-note.html b/layouts/shortcodes/hcl-note.html new file mode 100644 index 000000000000..796bdcffcf8f --- /dev/null +++ b/layouts/shortcodes/hcl-note.html @@ -0,0 +1,12 @@ +
+
+ {{ partial "icon.html" (dict "name" "info" "weight" "fill") }} +
+
+
+ Since this post was published, Pulumi has added first-class support for HCL. You can now + author Pulumi programs directly in HashiCorp Configuration Language, alongside TypeScript, + Python, Go, C#, Java, and YAML. To see how it works today, see + Pulumi HCL. +
+
diff --git a/layouts/shortcodes/hcl-note.markdown.md b/layouts/shortcodes/hcl-note.markdown.md new file mode 100644 index 000000000000..9cecf9f25fd7 --- /dev/null +++ b/layouts/shortcodes/hcl-note.markdown.md @@ -0,0 +1 @@ +> **Note:** Since this post was published, Pulumi has added first-class support for HCL. You can now author Pulumi programs directly in HashiCorp Configuration Language, alongside TypeScript, Python, Go, C#, Java, and YAML. To see how it works today, see [Pulumi HCL](/docs/iac/languages-sdks/hcl/).