DEV Community: Nedim Hozic

Pulumi + Azure: Managing Multiple Environments (Dev, Staging, Prod)

Nedim Hozic — Tue, 06 May 2025 09:21:39 +0000

Any real-world project has at least two environments — dev and prod — and often more: qa, staging, sometimes even region-specific environments.

Why? Because you want to catch mistakes before they reach production and impact your users.

From an infrastructure perspective, environments often differ significantly: different data, sizes, pricing tiers… even access controls. It’s not just about testing functionality — it’s about protecting production, reducing costs, and keeping things clean.

📚 Pulumi Stacks 101

In Pulumi, environments are managed through stacks. A stack is an isolated instance of your Pulumi program, with its own configuration, state, and resources.

When you initialized your project, you may have already created a stack — but you can add more at any time. For example:

pulumi stack init dev
pulumi stack init prod

This sets up two separate environments. To switch between them:

pulumi stack select dev

Commands like pulumi up, preview, and refresh will apply to the currently selected stack.

To list all your stacks and see which one is active:

pulumi stack ls

🛠 Using Configuration Per Environment

Pulumi uses per-stack config files like Pulumi.dev.yaml and Pulumi.prod.yaml to separate settings between environments—keeping your code the same while using different values.

You can define environment-specific values for things like resource names, SKUs, or feature toggles. For example:

pulumi config set storageAccessTier Cool --stack dev
pulumi config set storageAccessTier Hot --stack prod

If you’re working within the currently selected stack, you can omit the --stack parameter:

pulumi config set storageAccessTier Cool

To read configuration values in your code:

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

const config = new pulumi.Config();
const storageAccessTier = config.require("storageAccessTier");

✨ Small Demo: Different Storage Accounts for Dev and Prod

Let’s create two storage accounts — one for dev and one for prod—with different tiers and naming based on the environment.

First, switch to the dev environment and set up your config:

pulumi stack select dev

pulumi config set env dev
pulumi config set storageAccountTier Standard_LRS

Then, do the same for the prod environment:

pulumi stack select prod

pulumi config set env dev
pulumi config set storageAccountTier Standard_GRS

We’ve now defined two config values per stack: one for the environment name and one for the storage account tier.

While you could use the stack name (dev, prod, etc.) as the environment identifier, it’s often better to separate those concepts. For example, your environment might be named qa-west-europe, while your stack name is just qawe.

Now let’s create a storage account and a resource group per environment using those configs:

import * as pulumi from "@pulumi/pulumi";
import * as resources from "@pulumi/azure-native/resources";
import * as storage from "@pulumi/azure-native/storage";

const config = new pulumi.Config();
const environment = config.require("env");
const storageAccountTier = config.require("storageAccountTier");

// Create an Azure Resource Group
const resourceGroup = new resources.ResourceGroup("resourceGroup", {
    resourceGroupName: `rg-${environment}`,
});

// Create an Azure resource (Storage Account)
const storageAccount = new storage.StorageAccount("sa", {
    accountName: `sapulumitest${environment}`,
    resourceGroupName: resourceGroup.name,
    sku: {
        name: storageAccountTier,
    },
    kind: storage.Kind.StorageV2,
});

This setup creates resource groups named rg-dev and rg-prod, along with storage accounts like sapulumitestdev and sapulumitestprod, each using its specified storage tier.

✅ Easy peasy.

🧠 Pro Tips

Keep stack names simple and lowercase: dev, prod, test.
You can export outputs per stack (like connection strings) and fetch them easily.
Don’t hardcode anything per environment inside the code — always use config where possible.

✅ Wrap-Up

Pulumi stacks give you a clean, structured way to manage different environments like dev, staging, and prod — each with its own state and settings. By combining stacks with environment-specific configuration, you keep your infrastructure flexible, consistent, and easy to maintain.

In the next article, we’ll dive deeper into Pulumi configuration: how to manage complex values, structure settings, and securely handle sensitive data using secrets.

👉 Code for this post is available here on GitHub

Pulumi + Azure Series: Setting Up Your First Project (and Why It's Worth It)

Nedim Hozic — Tue, 29 Apr 2025 08:54:15 +0000

If you're a developer who wants more control over infrastructure - without diving into YAML or learning a new DSL - Pulumi might be exactly what you're looking for.
In this article, we'll explore what Pulumi is, how it compares to Terraform, how it manages state, and how to set up your first Azure resource - a Storage Account - using TypeScript.

🔍 What Is Pulumi?

Pulumi is an Infrastructure as Code (IaC) tool that lets you define cloud infrastructure using real programming languages and frameworks (and optionally YAML).
It supports Node.js/TypeScript, Python, Java, Go, and .NET languages (C#, F#, VB).

In this series, we'll use TypeScript for examples, as most developers know it or can easily understand it.
We'll also use the Azure Native provider, which provisions resources using the Azure Resource Manager (ARM) APIs - covering the full Azure service surface.

🧠 Pulumi vs Terraform (Key Differences)

1. Language

Terraform: Uses HCL (HashiCorp Configuration Language)
Pulumi: Uses real languages - TypeScript, Python, Go, C#, etc.

2. State Management
Terraform uses a .tfstate file to store the state locally, but you also have a choice to store it in HCP Terraform (Terraform managed solution) or Terraform Enterprise (on-premise self-hosted solution).

Similar to that, Pulumi allows you to store the state:

Locally in ~/.pulumi files
Pulumi managed services (Pulumi cloud)
Or in your own backend (like Azure Blob, S3, etc.)

⚡ How Pulumi Handles State

Pulumi CLI fetches the current state from the backend, compares it with your code's desired state, and directly applies diffs to Azure APIs.

Note: Pulumi does not automatically detect drift when running pulumi preview - you must explicitly run pulumi refresh to sync changes made outside of Pulumi. (We'll dive deeper into drift detection in a future post!)

⚙️ Setting Up Your Pulumi Project

First we need to install Pulumi:

brew install pulumi # or choco, curl, etc.

Then, you need to login. Pulumi will ask you where to store the state. Default is Pulumi Cloud (free tier) which we are using this first chapter. Later, we might explore other options as well.

pulumi login

Once you did that, you can freely create new folder with the name of your project, open that folder and execute creation of the actual Pulumi project, like this:

mkdir pulumi-azure-start && cd pulumi-azure-start
pulumi new azure-typescript

You will be asked to enter the project name (folder name per default), stack name (dev, prod, etc), and default Azure location (e.g. westeurope).

📁 Your Project Structure
You'll see files like:

index.ts – Your Pulumi program (TypeScript code)
package.json – Project dependencies
Pulumi.yaml – Project config
Pulumi.dev.yaml – Stack-specific config
tsconfig.json – TypeScript settings

📦 Default index.ts Content

import * as pulumi from "@pulumi/pulumi";
import * as resources from "@pulumi/azure-native/resources";
import * as storage from "@pulumi/azure-native/storage";

// Create an Azure Resource Group
const resourceGroup = new resources.ResourceGroup("resourceGroup");

// Create an Azure resource (Storage Account)
const storageAccount = new storage.StorageAccount("sa", {
    resourceGroupName: resourceGroup.name,
    sku: {
        name: storage.SkuName.Standard_LRS,
    },
    kind: storage.Kind.StorageV2,
});

// Export the primary key of the Storage Account
const storageAccountKeys = storage.listStorageAccountKeysOutput({
    resourceGroupName: resourceGroup.name,
    accountName: storageAccount.name
});

export const primaryStorageKey = storageAccountKeys.keys[0].value;

It is clearly visible that we are having resource group and storage account in that resource group.

Tip: The first parameter (e.g., "resourceGroup", "sa") is the unique name inside Pulumi state, not the actual Azure resource name.

🚀 Preview and Deploy
Preview the changes:

pulumi preview

Example output:

Previewing update (dev)

View in Browser (Ctrl+O): https://app.pulumi.com/xxx/pulumi-azure-start/dev/previews/xxx

     Type                                     Name                    Plan       
 +   pulumi:pulumi:Stack                      pulumi-azure-start-dev  create     
 +   ├─ azure-native:resources:ResourceGroup  resourceGroup           create     
 +   └─ azure-native:storage:StorageAccount   sa                      create     

Outputs:
    primaryStorageKey: output<string>

Resources:
    + 3 to create

Apply the changes:

pulumi up

And just like that, your Azure Storage Account is live!

✅ Wrap-Up and What's Next

In just a few lines of TypeScript, we provisioned an Azure Storage Account - no portals, no YAML, no magic. In the next article, we'll explore how to structure Pulumi projects and use configuration to handle different environments (dev/prod).

👉 Code for this post is available here on GitHub.

Pulumi + Azure Series: A Developer’s Perspective

Nedim Hozic — Sun, 20 Apr 2025 18:46:52 +0000

We live in an era where news and data are everywhere — instantly available, constantly updated, and often overwhelming. In software circles, every tool has its own fan base, community, stack of blog posts, and even full-blown evangelists.

Yet somehow, Pulumi has always felt a bit underappreciated to me. Maybe it’s because it’s not as widely adopted as Terraform, or maybe because it’s relatively young. Either way, I’ve felt a growing urge to share how genuinely powerful it is — especially when combined with Azure, the cloud I work with the most.

Pulumi isn’t limited to Azure, of course. It has great support for AWS, GCP, Kubernetes, and many other providers. But for this series, we’ll be focusing on real-world scenarios in Azure, because that’s where I’ve spent most of my time, and where Pulumi has truly helped me streamline and modernize how I build infrastructure.

💻 Why This Series Matters (Especially if You’re a Dev)

Infrastructure is part of our jobs now — even if you don’t have “DevOps” in your title. Pulumi lets you stay in your language, use your tools, and build infrastructure as if you’re coding features — not writing declarations.

Some time ago, I wrote an article about .NET Aspire and how it’s expanding a developer’s responsibilities into the infrastructure space: .NET Aspire: Bridging the Gap Between Application and Infrastructure. Aspire makes it clear: developers are no longer just writing APIs or frontends — they’re owning how those pieces run in the real world. Things like service discovery, environment configuration, diagnostics, and containerization are now just normal dev tasks.

But even outside of Aspire or .NET, this shift is happening everywhere. Developers today often need to spin up queues, databases, storage accounts, or set up secure communication between microservices. And let’s be honest — waiting on another team to provision these, or managing them manually through the Azure Portal, is not scalable or fun.

With Pulumi, you can own those pieces with the same tools and patterns you already use:

You can write infra using TypeScript, Python, Go, C#, or your team’s stack.
You can commit it to Git, test it, refactor it, and review it like any other code.
You don’t need to switch between a DSL like Bicep or write giant YAML files.

That’s a big deal.

Pulumi doesn’t ask you to become an infrastructure engineer overnight. It just lets you take ownership of the parts that are closest to your applications — things like:

Your app’s hosting environment (App Service, Function, Container App)
Connected services (Redis, CosmosDB, Storage)
Communication and messaging layers (Kafka, Event Hubs, Service Bus, SignalR)
Identity and secrets
It’s about bringing infrastructure closer to the people who understand the app best — you.

🔧 What You Can Expect from This Series

Here’s a glimpse of what’s coming:

How to set up your first Pulumi project with Azure Deploying real-world infrastructure (App Services, Functions, Storage, AKS, etc.)
Writing reusable Pulumi components for Azure
Managing environments and secrets with Pulumi configs
CI/CD pipelines and automation for IaC
Tips, gotchas, and Pulumi tricks I’ve learned along the way

Whether you’re new to Pulumi or just curious about a different approach to Azure infrastructure, I hope this series will help you see what’s possible when you combine real code with cloud automation.

Let’s get started 🚀

👉 Next up: Pulumi + Azure: Setting Up Your First Project