Why does the resource created differ by provider?

Each cloud has a different "default" storage primitive worth demonstrating: an S3 bucket for AWS, a Storage Account for Azure, and a GCS bucket for GCP. Picking a provider swaps in that provider's Pulumi SDK import and the equivalent resource class for whichever language you've chosen.

Is the Go or C# output guaranteed to compile as-is?

It's a structurally accurate skeleton following each SDK's real class and method names, but a real Pulumi program also needs a `Pulumi.yaml` project file, resolved dependencies (`go.mod`, a `.csproj`), and often more resource arguments than the minimal set shown here. Treat the output as the correct starting shape to build from, not a complete standalone project.

What is the stack config value for?

Pulumi's `Config` class lets a stack read a per-environment value (like an instance size or a feature flag) set with `pulumi config set`. The generator shows that value being read with a fallback default and then exported as a stack output, the two most common config operations in a real program.

Why is there a YAML language option, isn't Pulumi normally a general-purpose language tool?

Pulumi added a YAML-based program format so infrastructure can be declared without any general-purpose programming language runtime at all, similar in spirit to Terraform's HCL. It uses the same resource providers and engine underneath, just a declarative syntax instead of imperative code.

Pulumi Generator - TypeScript, Python, Go, C#, or YAML

Overview

Introduction

Pulumi's pitch is writing infrastructure in a real programming language, but that also means five different SDKs with five different idioms for the same operation: declaring a resource and reading a stack config value.

This tool generates that minimal pattern, one storage resource plus a config read/export, in whichever of TypeScript, Python, Go, C#, or YAML you're working in, for AWS, Azure, or GCP.

What Is Pulumi Program Generator?

A Pulumi program generator covering five language targets (TypeScript, Python, Go, C#, Pulumi YAML) and three cloud providers (AWS, Azure, GCP), each combination producing a storage resource declaration and a stack config read/export in that language's real SDK conventions.

The AWS path uses `@pulumi/aws`/`pulumi_aws`/the Go and C# AWS SDKs to create an S3 bucket, Azure uses `azure-native`'s Storage Account, and GCP uses `@pulumi/gcp`'s storage Bucket.

How Pulumi Program Generator Works

You pick a language and a cloud provider, then provide a resource name and a stack config key/default value.

The tool renders the correct import/using statements, the resource declaration using that provider's real Pulumi resource class and required arguments, and a config block that reads the given key (falling back to your default) and exports it as a stack output, all in the chosen language's syntax.

When To Use Pulumi Program Generator

Use it when starting a new Pulumi stack and you want the correct import statements and resource class name for your provider without checking each SDK's reference docs.

It's also useful for comparing how the same conceptual program looks across Pulumi's different language SDKs, useful when a team is deciding which language to standardize on.

Often used alongside Terraform Config Generator.

Features

Advantages

Covers all five Pulumi-supported languages, including the less common Go, C#, and YAML targets that most quick examples skip.
Uses each provider's real Pulumi resource class names (aws.s3.Bucket, azure_native.storage.StorageAccount, gcp.storage.Bucket) rather than a generic placeholder.
Demonstrates the config read/export pattern alongside the resource, the two things almost every real Pulumi program needs.

Limitations

Only generates one resource; real stacks typically declare many resources and reference outputs between them.
Doesn't generate the surrounding project files (Pulumi.yaml, package.json/go.mod/.csproj) a real, runnable project needs alongside the program file.

Examples

TypeScript program for an AWS S3 bucket

Input

language: typescript, provider: aws, resourceName: appData, configKey: environment, configValue: dev

Output

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

const appData = new aws.s3.Bucket("appData", {
  tags: { Environment: "dev" },
});

const config = new pulumi.Config();
export const environment = config.get("environment") ?? "dev";

The config value falls back to the provided default ("dev") if `pulumi config set environment <value>` hasn't been run for the current stack.

Best Practices & Notes

Best Practices

Read secrets with `config.requireSecret()`/`getSecret()` (language-appropriate equivalent) instead of plain `get()`, so Pulumi encrypts them in state.
Export only the outputs other stacks or tooling actually consume, not every resource's every attribute, to keep the stack's public interface small.
Pin provider SDK versions in your project's dependency file once a prototype becomes a real stack, rather than floating on "latest".

Developer Notes

Each language target uses that SDK's idiomatic construction pattern rather than a lowest-common-denominator translation: TypeScript/Python use direct object/kwarg construction, Go follows the `NewBucket(ctx, name, &Args{...})` plus explicit error-handling convention every Pulumi Go program uses, C# uses the `Deployment.RunAsync` lambda returning a stack outputs dictionary, and YAML uses Pulumi's declarative program schema with `resources`/`outputs`/`config` top-level keys.

Pulumi Program Generator Use Cases

Starting a new Pulumi stack in an unfamiliar language target
Comparing the same resource declaration pattern across Pulumi's five supported languages
Teaching the stack config read/export pattern alongside a concrete resource

Common Mistakes

Copying the Go or C# output expecting a fully runnable project without also setting up go.mod/.csproj and Pulumi.yaml.
Reading a secret value with the plain config getter instead of the secret-aware one, leaving it unencrypted in stack state.

Tips

Use the Terraform Generator instead if your team has already standardized on HCL-based infrastructure rather than Pulumi's general-purpose-language approach.

Pulumi Program Generator