{"id":"src_jjcTPC7jQ256vfihHZAgC","slug":"pulumi-blog","name":"Pulumi Blog","type":"feed","url":"https://www.pulumi.com/blog/","orgId":"org_CXx7IPNbZpLaDROi03ZTh","productId":null,"productSlug":null,"org":{"id":"org_CXx7IPNbZpLaDROi03ZTh","slug":"pulumi","name":"Pulumi"},"isPrimary":false,"isHidden":false,"discovery":"curated","metadata":"{\"evaluatedMethod\":\"feed\",\"evaluatedAt\":\"2026-04-11T13:59:04.992Z\",\"feedUrl\":\"https://www.pulumi.com/blog/rss.xml\",\"feedType\":\"rss\",\"feedDiscoveredAt\":\"2026-04-11T13:59:04.992Z\",\"noFeedFound\":false,\"feedEtag\":\"W/\\\"ffa88d7931fc43c01507d2c46a55a891\\\"\",\"feedLastModified\":\"Mon, 20 Jul 2026 21:08:23 GMT\",\"marketingFilter\":true,\"feedContentDepth\":\"summary-only\",\"enrichment\":{\"consecutiveFailures\":3},\"sourceActor\":{\"nextAlarmAt\":\"2026-07-21T01:20:56.058Z\",\"lastAlarmAt\":\"2026-07-20T21:20:56.765Z\",\"managed\":true}}","notice":null,"kind":"platform","stars":null,"starsFetchedAt":null,"releaseCount":92,"releasesLast30Days":16,"avgReleasesPerWeek":3,"latestVersion":null,"latestDate":"2026-07-20T00:00:00.000Z","changelogUrl":null,"hasChangelogFile":false,"lastFetchedAt":"2026-07-20T21:21:29.753Z","lastPolledAt":"2026-07-20T21:21:15.703Z","changeDetectedAt":null,"trackingSince":"2025-12-16T00:00:00.000Z","releases":[{"id":"rel_EYs08lIpOVZT9HDoM5Lqh","version":null,"type":"feature","title":"Incident Response as Code: Managing PagerDuty with Pulumi","summary":"![](https://www.pulumi.com/images/generated/blog/incident-response-as-code-pagerduty-pulumi/index.png)\n\nYou usually find out in the postmortem: the al...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/images/generated/blog/incident-response-as-code-pagerduty-pulumi/index.png)\n\nYou usually find out in the postmortem: the alarm fired, but it paged a schedule nobody was on anymore. Or the service had been running in production for three months before anyone created the matching [PagerDuty](https://www.pagerduty.com/) service, so the first person to notice the outage was a customer. The infrastructure was code, reviewed and versioned. The incident response setup was forty clicks in a web UI, done once, by someone who has since changed teams.\n\nPagerDuty’s own engineering team has been making the case for [managing PagerDuty as code](https://www.pagerduty.com/eng/how-why-terraform/) for years, and the OneUptime folks recently published a [hands-on guide to the PagerDuty Terraform provider](https://oneuptime.com/blog/post/2026-02-23-how-to-configure-pagerduty-provider-in-terraform/view) that walks the whole resource catalog. I liked both posts, and you probably know where this is going: I want the same thing in TypeScript, with the on-call setup and the infrastructure it protects living in the same Pulumi program. Teams, schedules, escalation policies, services, and the CloudWatch alarm that pages you: one `pulumi up`.\n\n## What you are building\n\nThe demo models a small platform team that owns a checkout service on AWS. On the PagerDuty side: a team with three members, a weekly on-call rotation, an escalation policy with two levels, and a service with a CloudWatch integration. On the AWS side: a dead-letter queue, an alarm that fires when a message lands in it, and an SNS topic that forwards the alarm to PagerDuty. The interesting part is where the two meet: the integration key PagerDuty mints flows straight into the SNS subscription without ever touching a clipboard.\n\n```\nflowchart LR\nDLQ[\"SQS dead-letter queue\"] --> Alarm[\"CloudWatch alarm\"]\nAlarm --> SNS[\"SNS topic\"]\nSNS -->|\"HTTPS subscription
with integration key\"| Int[\"CloudWatch integration\"]\nInt --> Svc[\"PagerDuty service
Checkout API\"]\nSvc --> EP[\"Escalation policy\"]\nEP -->|\"level 1\"| Sched[\"Weekly rotation
Lena, Jonas, Mia\"]\nEP -->|\"level 2, after 15 min\"| Lead[\"Team lead\"]\n```\n\nEverything on both sides of that diagram is one TypeScript program. If you would rather write Python, Go, C#, Java, or YAML, the [Pulumi PagerDuty provider](https://www.pulumi.com/registry/packages/pagerduty/) supports all of them. It is bridged from PagerDuty’s official Terraform provider (which started life as a community project by Alexander Hellbom before PagerDuty adopted it), so the resource coverage is identical.\n\n## Prerequisites\n\nBefore getting started, ensure you have:\n\n- [Pulumi CLI](https://www.pulumi.com/docs/iac/download-install/) installed and configured\n- A [Pulumi Cloud account](https://app.pulumi.com/signup)\n- A PagerDuty account with admin access; a [free trial](https://www.pagerduty.com/sign-up/) works fine\n- An [AWS](https://aws.amazon.com/) account for the alarm wiring in the second half\n- Node.js 18+ for the TypeScript program\n\n## The provider and the token\n\nCreate a new project and add the PagerDuty provider:\n\n```bash\npulumi new aws-typescript --name pagerduty-oncall\nnpm install @pulumi/pagerduty\n\n```\n\nThe provider authenticates with a REST API key. In PagerDuty, navigate to **Integrations** > **API Access Keys** and create a new key. This is the account-level REST API key, not a user token: user tokens are scoped to what one person can see, and you want the automation to manage the whole account.\n\nI store the key in [Pulumi ESC](https://www.pulumi.com/docs/esc/) so it never lands in a `.env` file, shell history, or agent context:\n\n```bash\npulumi env init /pagerduty-demo/dev\n\n```\n\nAdd the token to the environment definition:\n\n```yaml\nvalues:\n pagerduty:\n token:\n fn::secret: \n pulumiConfig:\n pagerduty:token: ${pagerduty.token}\n\n```\n\nThen reference the environment from your stack in `Pulumi.dev.yaml`:\n\n```yaml\nenvironment:\n - /pagerduty-demo/dev\n\n```\n\nIn a hurry? `pulumi config set pagerduty:token --secret` does the same job for a single stack, and the provider also reads the `PAGERDUTY_TOKEN` environment variable. If your account lives on the EU service region, additionally set `pagerduty:serviceRegion` to `eu`.\n\n## Teams, users, and memberships\n\nEverything in PagerDuty hangs off teams and users, so that is where the program starts:\n\n```typescript\nimport * as pagerduty from \"@pulumi/pagerduty\";\n\nconst platformTeam = new pagerduty.Team(\"platform-team\", {\n name: \"Platform Engineering\",\n description: \"Owns the checkout path and the shared platform\",\n});\n\nconst lena = new pagerduty.User(\"lena\", {\n name: \"Lena Fischer\",\n email: \"lena@example.com\",\n});\n\nconst jonas = new pagerduty.User(\"jonas\", {\n name: \"Jonas Weber\",\n email: \"jonas@example.com\",\n});\n\nconst mia = new pagerduty.User(\"mia\", {\n name: \"Mia Schneider\",\n email: \"mia@example.com\",\n});\n\nnew pagerduty.TeamMembership(\"lena-platform\", {\n userId: lena.id,\n teamId: platformTeam.id,\n role: \"manager\",\n});\n\nnew pagerduty.TeamMembership(\"jonas-platform\", {\n userId: jonas.id,\n teamId: platformTeam.id,\n role: \"responder\",\n});\n\nnew pagerduty.TeamMembership(\"mia-platform\", {\n userId: mia.id,\n teamId: platformTeam.id,\n role: \"responder\",\n});\n\n```\n\nThree users, one team, three memberships. Reorgs stop being an afternoon of UI archaeology and become a pull request where the diff shows exactly who moved where.\n\nIf your users already come from SSO or SCIM provisioning (they usually do), don’t create them in the program. Look them up instead with the `getUser` data source: `pagerduty.getUserOutput({ email: \"lena@yourcompany.com\" })`. And if your account restricts sign-ups to your company’s email domain, the API enforces that too, so swap the `example.com` addresses for ones on your own domain when trying this out.\n\n## A schedule people can live with\n\nThe on-call schedule is where incident response meets real life, so it deserves more care than a demo usually gives it. If you have seen PagerDuty schedules in Terraform before, you probably remember the `Schedule` resource and its `layers`. That resource is deprecated in the current provider because it speaks the legacy v1 schedules API; its successor `Schedulev2` uses PagerDuty’s new model built on rotations, events, and RFC 5545 recurrence rules:\n\n```typescript\nconst primary = new pagerduty.Schedulev2(\"primary\", {\n name: \"Platform Primary On-Call\",\n description: \"Weekly hand-off rotation for the platform team\",\n timeZone: \"Europe/Berlin\",\n teams: [platformTeam.id],\n rotations: [{\n events: [{\n name: \"Weekly rotation\",\n startTime: \"2026-08-03T09:00:00+02:00\",\n endTime: \"2026-08-10T09:00:00+02:00\",\n effectiveSince: \"2026-08-03T07:00:00Z\",\n recurrences: [\"RRULE:FREQ=WEEKLY;BYDAY=MO\"],\n assignmentStrategies: [{\n type: \"rotating_member_assignment_strategy\",\n shiftsPerMember: 1,\n members: [\n { type: \"user_member\", userId: lena.id },\n { type: \"user_member\", userId: jonas.id },\n { type: \"user_member\", userId: mia.id },\n ],\n }],\n }],\n }],\n});\n\n```\n\nRead it from the inside out. The event is one shift: it starts Monday at 09:00 Berlin time and ends the following Monday at 09:00, and the RRULE makes it recur weekly. The assignment strategy hands each occurrence to the next member in the list, so Lena, Jonas, and Mia each take a full week, round robin. `effectiveSince` tells PagerDuty when this configuration starts producing shifts. Business-hours-only coverage falls out of the same model: shorten the shift window and change the recurrence to `RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR`.\n\n## The escalation policy\n\nThe escalation policy reads top to bottom, the same way the incident will play out:\n\n```typescript\nconst escalation = new pagerduty.EscalationPolicy(\"platform-escalation\", {\n name: \"Platform Escalation Policy\",\n numLoops: 2,\n teams: platformTeam.id,\n rules: [\n {\n escalationDelayInMinutes: 15,\n targets: [{\n type: \"schedule_reference\",\n id: primary.id,\n }],\n },\n {\n escalationDelayInMinutes: 10,\n targets: [{\n type: \"user_reference\",\n id: lena.id,\n }],\n },\n ],\n});\n\n```\n\nPage whoever the primary schedule says is on call. If nobody acknowledges within 15 minutes, page Lena directly. If the whole chain runs dry, `numLoops: 2` starts it over twice more before PagerDuty gives up. When someone asks what actually happens when this fires at 3 AM, the answer is a dozen lines of reviewed code, not a screenshot of a UI that may or may not be current.\n\n## The service\n\nA PagerDuty service is the unit incidents attach to, and it is where the escalation policy gets wired in:\n\n```typescript\nconst checkoutService = new pagerduty.Service(\"checkout\", {\n name: \"Checkout API\",\n escalationPolicy: escalation.id,\n autoResolveTimeout: \"14400\",\n acknowledgementTimeout: \"600\",\n});\n\n```\n\nThink of a service as the thing that can break, like the checkout API or the payments queue behind it. Every incident in PagerDuty opens against exactly one service, and the service decides what happens next. The escalation policy answers who gets paged. `acknowledgementTimeout` re-triggers an incident that was acknowledged and then went quiet for ten minutes, so a sleepy “ack” cannot make a problem disappear. And `autoResolveTimeout` closes an incident that has sat open for four hours, which keeps the dashboard honest when everyone forgot to press resolve. Map services one-to-one to the things your team actually owns, and the service directory turns into an honest inventory of your system, each entry with an owner attached.\n\n## The payoff: the alarm and the pager in one program\n\nSo far this is a nicer syntax for what the Terraform guides already do. Here is where it starts earning its keep. Remember the service from the top of this post that ran for three months without a pager? The place that failure usually hides is a dead-letter queue, where bad news piles up quietly. This is what it looks like when the queue, the alarm, and the pager live in one program:\n\n```typescript\nimport * as aws from \"@pulumi/aws\";\nimport * as pulumi from \"@pulumi/pulumi\";\n\nconst cloudwatch = pagerduty.getVendorOutput({ name: \"Amazon CloudWatch\" });\n\nconst checkoutIntegration = new pagerduty.ServiceIntegration(\"checkout-cloudwatch\", {\n name: \"Amazon CloudWatch\",\n service: checkoutService.id,\n vendor: cloudwatch.id,\n});\n\nconst alarmTopic = new aws.sns.Topic(\"checkout-alarms\");\n\nnew aws.sns.TopicSubscription(\"checkout-alarms-to-pagerduty\", {\n topic: alarmTopic.arn,\n protocol: \"https\",\n endpoint: pulumi.interpolate`https://events.pagerduty.com/integration/${checkoutIntegration.integrationKey}/enqueue`,\n endpointAutoConfirms: true,\n});\n\nconst dlq = new aws.sqs.Queue(\"checkout-dlq\");\n\nnew aws.cloudwatch.MetricAlarm(\"checkout-dlq-alarm\", {\n alarmDescription: \"Messages are landing in the checkout dead-letter queue\",\n namespace: \"AWS/SQS\",\n metricName: \"ApproximateNumberOfMessagesVisible\",\n dimensions: {\n QueueName: dlq.name,\n },\n statistic: \"Maximum\",\n period: 60,\n evaluationPeriods: 1,\n threshold: 1,\n comparisonOperator: \"GreaterThanOrEqualToThreshold\",\n alarmActions: [alarmTopic.arn],\n okActions: [alarmTopic.arn],\n});\n\n```\n\nFollow the integration key. PagerDuty mints it when the `ServiceIntegration` is created, and a few lines later it is interpolated into the SNS subscription endpoint. In the two-tool world, this is the step where you open the PagerDuty UI, copy the integration URL, and paste it into a variables file or a wiki page, which is exactly the step that gets skipped at 5 PM on a Friday. Here it cannot be skipped, because it is a dependency: Pulumi will not create the subscription before the integration exists.\n\n`endpointAutoConfirms: true` matters because PagerDuty answers the SNS subscription handshake on its own; without it, the subscription sits in “pending confirmation” forever. And since the alarm sends its OK state to the same topic, PagerDuty resolves the incident automatically once the queue drains.\n\nTearing down the service? The alarm, the topic, the subscription, and the PagerDuty service all go in the same `pulumi destroy`, which spares you the orphaned PagerDuty service that keeps paging people about infrastructure that no longer exists. I have seen that one too.\n\n## Azure and Google Cloud, same trick\n\nNothing about this is AWS-specific. It is always the same two steps: PagerDuty mints a key, the monitoring side consumes it. On Google Cloud, Cloud Monitoring has a native PagerDuty channel type, and its `serviceKey` is the integration key of an Events API v2 integration:\n\n```typescript\nimport * as gcp from \"@pulumi/gcp\";\n\nconst gcpIntegration = new pagerduty.ServiceIntegration(\"checkout-gcp\", {\n name: \"Google Cloud Monitoring\",\n service: checkoutService.id,\n type: \"events_api_v2_inbound_integration\",\n});\n\nnew gcp.monitoring.NotificationChannel(\"checkout-pagerduty\", {\n displayName: \"PagerDuty: Checkout API\",\n type: \"pagerduty\",\n sensitiveLabels: {\n serviceKey: gcpIntegration.integrationKey,\n },\n});\n\n```\n\nOn Azure, an Azure Monitor action group with a webhook receiver does the same job, pointed at the familiar enqueue URL (with `resourceGroup` being an `azure.resources.ResourceGroup` from earlier in your program):\n\n```typescript\nimport * as azure from \"@pulumi/azure-native\";\n\nconst azureVendor = pagerduty.getVendorOutput({ name: \"Microsoft Azure\" });\n\nconst azureIntegration = new pagerduty.ServiceIntegration(\"checkout-azure\", {\n name: \"Microsoft Azure\",\n service: checkoutService.id,\n vendor: azureVendor.id,\n});\n\nnew azure.monitor.ActionGroup(\"checkout-pagerduty\", {\n resourceGroupName: resourceGroup.name,\n location: \"global\",\n groupShortName: \"checkout\",\n enabled: true,\n webhookReceivers: [{\n name: \"pagerduty\",\n serviceUri: pulumi.interpolate`https://events.pagerduty.com/integration/${azureIntegration.integrationKey}/enqueue`,\n useCommonAlertSchema: true,\n }],\n});\n\n```\n\nThe `location: \"global\"` is not a placeholder. Action groups are a global service, and Azure rejects regular regions like `westeurope` for them; setting it explicitly makes that intent obvious in the code.\n\nSame program, same key handoff, different cloud. If your platform spans all three, the PagerDuty side does not care.\n\n## Breaking a Fargate payment service on purpose\n\nEverything so far wires configuration together, but I did not want to publish wiring I had never watched fire. So I put it to the test: a companion project that deploys a small payment service on [AWS Fargate](https://aws.amazon.com/fargate/) together with its entire failure chain, and then breaks it on purpose.\n\nThe worker is deliberately boring: the plain AWS CLI container image running a shell loop. It receives payment messages from an SQS queue, processes anything that has an `amount`, and refuses everything else. A refused message goes back to the queue, and after three failed receives SQS moves it to the dead-letter queue. From there, the chain from earlier in this post takes over: DLQ alarm, SNS topic, CloudWatch integration, escalation policy, phone.\n\nA valid payment flows through in seconds:\n\n```bash\n./scripts/send-payment.sh\n# worker log: processed payment: {\"orderId\":\"4711\",\"amount\":\"49.99\",\"currency\":\"EUR\"}\n\n```\n\nA payment without an amount poisons the queue:\n\n```bash\n./scripts/inject-failure.sh\n\n```\n\nHere is the timeline from my test run, as the test script observed it through the AWS and PagerDuty APIs:\n\nElapsed\n\nWhat happened\n\n0:00\n\nPoison payment injected\n\n3:45\n\nThird receive failed, message redriven to the DLQ, alarm in `ALARM`\n\n3:49\n\nPagerDuty incident triggered on Payment Service\n\n3:50\n\nRecovery: dead-letter queue purged\n\n6:48\n\nAlarm back to `OK`\n\n6:49\n\nIncident resolved\n\n![The PagerDuty incidents view showing the triggered incident: the dead-letter queue alarm on Payment Service, high urgency, assigned to the on-call engineer](pagerduty-incident.png)\n\nUnder four minutes from a bad message to a page, and I never touched the PagerDuty UI in either direction; the incident opened and closed itself off the alarm’s state transitions. The incident timeline spells it out: automatically triggered and assigned, then resolved through the integration API.\n\n![The resolved incident’s timeline in PagerDuty: automatically triggered and assigned at 9:58 AM, the on-call notified by email, and resolved through the integration API 12 minutes later](pagerduty-resolved.png)\n\nThe full program, the worker loop, and the inject and recover scripts are in the companion repo:\n\n[![GitHub repository: dirien/pulumi-pagerduty-fargate-demo](https://opengraph.githubassets.com/1/dirien/pulumi-pagerduty-fargate-demo)\n\ngithub.com/dirien/pulumi-pagerduty-fargate-demo\n\n](https://github.com/dirien/pulumi-pagerduty-fargate-demo)\n\n## Growing without the drift: a reusable component\n\nWhether any of this stays consistent as your organization grows comes down to defaults. If creating a properly paged service takes a checklist, people will skip items. If it takes a [component](https://www.pulumi.com/docs/iac/concepts/components/), they won’t, because the component is less work than the checklist. So wrap the service, the integration, and the alarm topic into one:\n\n```typescript\nexport class OnCallService extends pulumi.ComponentResource {\n public readonly service: pagerduty.Service;\n public readonly alarmTopic: aws.sns.Topic;\n\n constructor(name: string, args: {\n displayName: string;\n escalationPolicy: pulumi.Input<string>;\n }, opts?: pulumi.ComponentResourceOptions) {\n super(\"acme:oncall:OnCallService\", name, {}, opts);\n\n this.service = new pagerduty.Service(name, {\n name: args.displayName,\n escalationPolicy: args.escalationPolicy,\n autoResolveTimeout: \"14400\",\n acknowledgementTimeout: \"600\",\n }, { parent: this });\n\n const cloudwatch = pagerduty.getVendorOutput({ name: \"Amazon CloudWatch\" });\n\n const integration = new pagerduty.ServiceIntegration(name, {\n name: \"Amazon CloudWatch\",\n service: this.service.id,\n vendor: cloudwatch.id,\n }, { parent: this });\n\n this.alarmTopic = new aws.sns.Topic(name, {}, { parent: this });\n\n new aws.sns.TopicSubscription(name, {\n topic: this.alarmTopic.arn,\n protocol: \"https\",\n endpoint: pulumi.interpolate`https://events.pagerduty.com/integration/${integration.integrationKey}/enqueue`,\n endpointAutoConfirms: true,\n }, { parent: this });\n\n this.registerOutputs({});\n }\n}\n\n```\n\nAnd now every new service ships with a pager attached. The `checkout` instance here replaces the hand-rolled service, integration, and topic from earlier:\n\n```typescript\nconst checkout = new OnCallService(\"checkout\", {\n displayName: \"Checkout API\",\n escalationPolicy: escalation.id,\n});\n\nconst payments = new OnCallService(\"payments\", {\n displayName: \"Payments API\",\n escalationPolicy: escalation.id,\n});\n\n```\n\nApp teams get one contract: point your alarms at `alarmTopic`. The escalation policy, the timeouts, the integration, the SNS wiring, all of it becomes the paved road instead of a checklist item. This is the same [components-and-templates story](https://www.pulumi.com/blog/golden-paths-infrastructure-components-and-templates/) I keep telling for compute and networking; incident response just turns out to be another thing a platform team can pave.\n\n## Importing what you already clicked together\n\nNobody starts from an empty PagerDuty account. The realistic adoption path is `pulumi import`, resource by resource:\n\n```bash\npulumi import pagerduty:index/team:Team platform-team PXXXXXX\npulumi import pagerduty:index/service:Service checkout PYYYYYY\n\n```\n\nThe IDs are in the URL when you open a team or service in the PagerDuty web UI, and `pulumi import` writes the matching code for you, so bringing an existing setup under management is mostly a copy-paste loop. The [import guide](https://www.pulumi.com/docs/iac/guides/migration/import/) covers the mechanics.\n\nOne habit matters after that, and PagerDuty’s engineering post makes the same point about Terraform: once a resource is managed as code, stop editing it in the UI. Changes made in the web console are drift, and you will want to run `pulumi refresh` (or let [drift detection](https://www.pulumi.com/blog/day-2-operations-drift-detection-and-remediation/) do it on a schedule) to catch them before the 3 AM page tests your assumptions for you.\n\n## Conclusion\n\nThe pitch for managing PagerDuty as code has less to do with YAML versus HCL versus TypeScript than with the gap between two systems that each hold half the truth. Your infrastructure code knows a queue exists; PagerDuty knows who gets paged when it backs up. Keep them in separate tools and that gap is maintained by hand, which means it is maintained until the person who cared about it leaves.\n\nPutting both sides in one Pulumi program closes the gap structurally. The integration key becomes a dependency edge instead of a wiki entry, and forgetting the escalation policy is not even possible, because `escalationPolicy` is a required property and the program will not compile without it. That is the version of “nothing gets forgotten” I am willing to rely on.\n\nTo go further:\n\n- The [PagerDuty provider in the Pulumi Registry](https://www.pulumi.com/registry/packages/pagerduty/) covers the full resource catalog: event orchestrations, maintenance windows, response plays, and more.\n- [Pulumi ESC](https://www.pulumi.com/docs/esc/) keeps the API token out of your shell history.\n- Coming from the Terraform provider? Your resource knowledge maps one-to-one, and the [migration guide](https://www.pulumi.com/docs/iac/guides/migration/migrating-to-pulumi/from-terraform/) covers the rest.\n\nIf you build something with this, or if your on-call setup has a horror story that code would have prevented, come tell me in the [Pulumi Community Slack](https://slack.pulumi.com/).","publishedAt":"2026-07-20T00:00:00.000Z","fetchedAt":"2026-07-20T17:21:21.720Z","url":"https://www.pulumi.com/blog/incident-response-as-code-pagerduty-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/incident-response-as-code-pagerduty-pulumi/index.png","r2Key":"releases/ccd248f83005f6e0e33797cdef1c94dac5012ee6f7ff9ca25ead89c1119910b3.png","r2Url":"https://media.releases.sh/releases/ccd248f83005f6e0e33797cdef1c94dac5012ee6f7ff9ca25ead89c1119910b3.png"},{"type":"image","url":"https://opengraph.githubassets.com/1/dirien/pulumi-pagerduty-fargate-demo","alt":"GitHub repository: dirien/pulumi-pagerduty-fargate-demo","r2Key":"releases/93e8674807ad31cb88d5f3a7b3c0278e7941894d11f45b7aea248261da8b2a49.png","r2Url":"https://media.releases.sh/releases/93e8674807ad31cb88d5f3a7b3c0278e7941894d11f45b7aea248261da8b2a49.png"}],"coverageCount":0},{"id":"rel_2S0bqFkOiignZ-Ah-hQ4p","version":null,"type":"feature","title":"Best Terraform Alternatives in 2026","summary":"Blog post surveys infrastructure-as-code alternatives to Terraform in 2026, covering general-purpose-language platforms (Pulumi, AWS CDK), HCL-compatible forks (OpenTofu), and cloud-specific tools (CloudFormation, Azure Bicep, Crossplane). Analysis highlights licensing shifts, HCL's composability ceiling, and AI agent compatibility as key factors driving re-evaluation.","titleGenerated":"Pulumi evaluates top Terraform alternatives in 2026","titleShort":"Top Terraform alternatives in 2026 evaluated","breaking":"none","importance":3,"content":"![](https://www.pulumi.com/images/generated/blog/best-terraform-alternatives/index.png)\n\nThe strongest Terraform alternatives in 2026 split into three groups: general-purpose-language platforms like Pulumi and AWS CDK, HCL-compatible forks like OpenTofu, and cloud- or platform-specific tools like AWS CloudFormation, Azure Bicep, and Crossplane. Which one fits depends less on syntax preference than on how well it lets your team, and increasingly your AI coding agents, read, test, and safely change infrastructure code.\n\n## Why teams are re-evaluating Terraform in 2026\n\nTerraform has been the default infrastructure-as-code tool for most of the last decade, and for good reason: a mature provider ecosystem, a large community, and a state model that most platform teams have learned to live with. But three forces are pushing teams to look again at what else is available.\n\nThe first is licensing. HashiCorp moved Terraform from the open-source Mozilla Public License to the Business Source License in August 2023, a shift that triggered the community fork now known as OpenTofu. HashiCorp itself became a wholly owned subsidiary of IBM when that acquisition closed in February 2025. Neither event breaks anything for existing Terraform users, but both changed how governance and long-term product direction get decided, and that’s enough for some platform teams to want a documented Plan B.\n\nThe second is the accumulated cost of working in a domain-specific language. HCL wasn’t designed for the abstraction, composition, and testing patterns that platform engineering now expects: sharing logic across teams, writing meaningful unit tests, and building internal libraries that read like software rather than templated configuration. Terraform has closed some of this gap over time, adding a native test framework in version 1.6, but the ceiling on what a declarative DSL can express is still lower than what a general-purpose language offers.\n\nThe third, and the one reshaping the conversation fastest, is agentic AI. Coding agents like GitHub Copilot, Claude, and Pulumi’s own Neo are now a standing part of how engineering teams write and review code, and infrastructure is not exempt. These agents were trained on enormous volumes of real Python, TypeScript, Go, and Java, plus their entire testing and tooling ecosystems, but on comparatively little well-formed HCL. When an agent can write and modify infrastructure in a language it already understands deeply, the feedback loop of propose, test, preview, and ship gets tighter. When it has to reason about a purpose-built DSL, that loop lengthens and the agent is more likely to produce configuration nobody would write by hand. That gap doesn’t disqualify Terraform, but it does mean “which IaC tool works best with AI agents” is now a first-class question when teams evaluate alternatives, alongside the perennial ones about multi-cloud reach and governance.\n\nNone of this is an argument that Terraform is going away. It remains a capable, widely adopted tool with a genuinely large provider catalog. It’s an argument that 2026 is a reasonable moment to look at what else exists, honestly, and pick the tool that fits where your infrastructure and your engineering workflow are actually headed. For a broader look at how AI agents are changing infrastructure work generally, see [building for agentic infrastructure](https://www.pulumi.com/releases/agentic-infrastructure-era/). For a head-to-head look at Pulumi and Terraform specifically, see our [Pulumi vs. Terraform comparison](https://www.pulumi.com/docs/iac/comparisons/terraform/).\n\n## Pulumi\n\nPulumi is an infrastructure-as-code platform that lets you define cloud infrastructure in general-purpose languages, including Python, TypeScript, Go, C#, and Java, plus a YAML option for teams that prefer a declarative format. Rather than compiling down to another tool’s templates, Pulumi programs run directly against a deployment engine that supports more than 180 providers in total, covering AWS, Azure, Google Cloud, Kubernetes, and a long tail of SaaS and on-prem targets.\n\nWriting infrastructure in a real language means you get the tooling that comes with it for free: IDE autocomplete and type checking, unit and integration test frameworks, package managers for sharing reusable components, and the same code review and CI/CD conventions your application teams already use. It also means Pulumi programs run directly through Pulumi’s own deployment engine against any cloud or SaaS platform, with no separate compile-to-template step in between, unlike CDK-style tools that transpile into another system’s format before anything deploys. For an AI agent iterating on infrastructure, fewer steps between “write code” and “see the result” means a tighter feedback loop. [Pulumi Neo](https://www.pulumi.com/product/neo/), the platform’s infrastructure agent, builds on this directly: it can propose Terraform-to-Pulumi migrations, run policy-checked previews, respond to failures, and open pull requests inside a team’s existing review workflow.\n\nFor platform teams, Pulumi adds built-in guardrails that Terraform typically requires bolting on through third-party tooling: [policy as code](https://www.pulumi.com/what-is/what-is-policy-as-code/) for enforcing organizational rules before a deployment ships, a secrets and configuration management layer (ESC), human-in-the-loop approval gates, and reusable components that teams can publish and consume like any other internal library, in whatever language they use. The tradeoff is ecosystem maturity in the opposite direction from Terraform: Pulumi’s provider catalog, while broad, has a shorter history than Terraform’s for a handful of niche or long-tail providers, and some teams will need to weigh that against the language and workflow benefits.\n\nAt scale, Pulumi customers report concrete outcomes. BMW’s Software Factory manages more than 20,000 cloud resources with Python-based infrastructure code for over 11,000 developers. Wiz manages more than a million cloud resources through Pulumi’s Automation API and Kubernetes operator, pushing hundreds of thousands of daily infrastructure updates across hundreds of data centers. Supabase scaled from a single region to 16 regions and roughly 80,000 resources. Atlassian’s Bitbucket team reported a 50% reduction in infrastructure maintenance time after adopting Pulumi.\n\n## OpenTofu\n\n[OpenTofu](https://www.pulumi.com/docs/iac/comparisons/terraform/opentofu/) is an open-source fork of Terraform, governed by the Linux Foundation rather than a single vendor. It emerged directly from HashiCorp’s August 2023 license change: a group of Terraform users and vendors forked the last MPL-licensed Terraform release and committed to keeping the fork under a permissive open-source license going forward.\n\nThe practical pitch is continuity: OpenTofu aims to stay a close drop-in replacement for Terraform, using the same HCL syntax, the same provider ecosystem (most Terraform providers work unmodified), and largely the same workflow, so teams can migrate with minimal rewriting. Since forking, OpenTofu’s maintainers have also started adding features HashiCorp hadn’t shipped, including state encryption at rest, giving it a case for teams who want to stay in HCL but prioritize community governance over vendor governance.\n\nThe tradeoff is that OpenTofu inherits HCL’s ceiling along with its familiarity. It solves the licensing and governance concern cleanly, but it doesn’t address the testing, composability, or general-purpose-language advantages that come with moving to a platform like Pulumi or AWS CDK, and AI coding agents face the same reasoning gap with OpenTofu’s HCL that they do with Terraform’s.\n\n## AWS CloudFormation\n\nCloudFormation is AWS’s native infrastructure-as-code service, using YAML or JSON templates that AWS itself parses, validates, and rolls back on failure. Because it’s built and operated by AWS, it gets first access to new AWS service features, and its state is managed entirely by AWS rather than a separate backend your team has to configure and secure.\n\nThe obvious limit is scope: CloudFormation only provisions AWS resources, so any team running infrastructure across more than one cloud, or alongside Kubernetes and SaaS resources, will need a second tool for everything outside AWS. Authoring in raw YAML or JSON also means the same testing and abstraction limitations that HCL-based tools face, without even Terraform’s ecosystem of community modules to offset it. Many AWS-focused teams increasingly write CloudFormation stacks through AWS CDK rather than by hand.\n\n## AWS CDK\n\nAWS CDK (Cloud Development Kit) lets you define AWS infrastructure using general-purpose languages including TypeScript, JavaScript, Python, Java, C#, and Go. Under the hood, CDK code compiles down to standard CloudFormation templates, which AWS then deploys the same way it deploys any other CloudFormation stack.\n\nCDK gives AWS-only teams most of the general-purpose-language benefits that Pulumi offers: real loops, functions, tests, and packages, plus the IDE support that comes with a mainstream language. The compile step is the notable difference from a platform like Pulumi, which runs your program directly against cloud provider APIs: CDK synthesizes a CloudFormation template first, then hands that off, which adds a layer between what your code says and what gets deployed, and can slow the feedback loop an AI coding agent depends on when it’s proposing and testing changes iteratively. CDK is also AWS-only, so it doesn’t help teams who need one consistent authoring model across multiple clouds.\n\nIt’s worth distinguishing AWS CDK clearly from HashiCorp’s CDK for Terraform (CDKTF), which offered a similar general-purpose-language wrapper around Terraform’s HCL engine. HashiCorp sunset and archived CDKTF in December 2025, stating in its own FAQ that the project “did not find product-market fit at scale” and redirecting investment to Terraform core instead. Existing CDKTF code still runs, but the project receives no further commits, fixes, or provider updates, which makes it a poor foundation for new work regardless of language preference.\n\n## Crossplane\n\nCrossplane is a Kubernetes-native framework for infrastructure as code, letting platform teams define and provision cloud resources as Kubernetes custom resources, managed by controllers running inside a cluster. Rather than running a separate CLI-driven apply cycle, Crossplane treats the cluster’s control plane as the single source of truth for both application and infrastructure state.\n\nThis model is a natural fit for teams already standardized on Kubernetes as their platform layer: infrastructure gets the same GitOps, RBAC, and reconciliation patterns as application workloads, and platform teams can build self-service abstractions (Crossplane calls these Compositions) that let application developers request infrastructure without learning Crossplane’s own resource model directly. The tradeoff is that Crossplane assumes a Kubernetes-centric operating model; teams without an existing cluster-based platform will be adopting Kubernetes as a prerequisite, not just an infrastructure tool, and Crossplane’s ecosystem of documented, named enterprise deployments is thinner than Terraform’s or Pulumi’s, making it harder to evaluate at-scale track record from public case studies alone.\n\n## Azure Bicep\n\nBicep is Microsoft’s domain-specific language for deploying Azure resources, designed as a cleaner authoring layer over Azure Resource Manager templates. Bicep code transpiles to ARM JSON, but with syntax that’s considerably easier to read and write than hand-authored ARM. It’s open source under the MIT license, and Microsoft’s own documentation recommends it over raw ARM JSON for new Azure-only infrastructure work.\n\nLike CloudFormation, Bicep’s scope is a single cloud, in this case Azure exclusively, so it isn’t a candidate for teams managing infrastructure across providers. It’s also a DSL rather than a general-purpose language, which means the same testing and reuse ceiling as HCL, though for teams fully committed to Azure and nothing else, it remains a well-supported, low-friction choice.\n\n## Ansible\n\nAnsible is an agentless configuration management and automation tool that uses YAML playbooks to describe the desired state of servers, software, and application deployments. Red Hat, which acquired Ansible in 2015 and was itself acquired by IBM in 2019, maintains it today as part of Red Hat Ansible Automation Platform.\n\nAnsible is often grouped with Terraform in “IaC tool” comparisons, but the two solve different problems and are frequently used together rather than as substitutes: Terraform or Pulumi provisions the resource, and Ansible then configures the operating system, installs software, and manages ongoing configuration state on top of it. Ansible does ship cloud provisioning modules and can create resources directly, but its design center is procedural configuration management, not declarative resource provisioning at the scale Terraform-class tools target. Teams evaluating Terraform alternatives for cloud provisioning specifically will usually want a tool from this list’s other categories, with Ansible layered in afterward for day-two configuration.\n\n## Terragrunt\n\nTerragrunt is a thin orchestration wrapper maintained by Gruntwork that sits on top of Terraform or OpenTofu, rather than replacing either one. Its job is keeping multi-environment, multi-module HCL configurations DRY, and coordinating the order in which modules apply across a larger infrastructure codebase.\n\nIt’s worth being precise about what Terragrunt is not: it doesn’t introduce a new language, provider model, or state backend, and it doesn’t address HCL’s testing or abstraction limitations on its own. Teams considering Terragrunt aren’t choosing a Terraform alternative; they’re choosing a companion tool that makes Terraform or OpenTofu easier to operate at scale. If the underlying frustration is with HCL itself rather than with configuration sprawl, Terragrunt won’t resolve it.\n\n## Comparison table\n\nTool\n\nLanguage\n\nCloud coverage\n\nAI-agent readiness\n\nGovernance & policy\n\nBest for\n\nPulumi\n\nPython, TypeScript, Go, C#, Java, YAML\n\n180+ providers, any cloud\n\nHigh — real languages agents are trained on; Neo agent built in\n\nPolicy as code, ESC secrets, human-in-the-loop approvals\n\nTeams standardizing on AI-native, multi-cloud engineering workflows\n\nOpenTofu\n\nHCL\n\nSame provider ecosystem as Terraform\n\nSame as Terraform — DSL limits agent reasoning\n\nCommunity-governed; adding features like state encryption\n\nTerraform users prioritizing open governance with minimal migration\n\nAWS CloudFormation\n\nYAML/JSON\n\nAWS only\n\nLow — templated config, no native testing\n\nAWS-managed state and rollback\n\nTeams fully committed to AWS wanting a fully managed native service\n\nAWS CDK\n\nTypeScript, Python, Java, C#, Go\n\nAWS only (compiles to CloudFormation)\n\nMedium — real languages, but a compile step slows feedback\n\nInherits CloudFormation governance\n\nAWS-only teams wanting general-purpose languages\n\nCrossplane\n\nKubernetes YAML/CRDs\n\nAny cloud, via Kubernetes control plane\n\nMedium — benefits from Kubernetes-native agent tooling\n\nRBAC and GitOps via Kubernetes\n\nPlatform teams already standardized on Kubernetes\n\nAzure Bicep\n\nBicep DSL (compiles to ARM)\n\nAzure only\n\nLow — DSL, no general-purpose tooling\n\nInherits Azure Resource Manager governance\n\nAzure-only teams wanting a cleaner ARM authoring layer\n\nAnsible\n\nYAML playbooks\n\nAny cloud, config-management focused\n\nLow for provisioning; not its design center\n\nRole-based playbooks, limited policy tooling\n\nDay-two configuration management alongside an IaC tool\n\nTerragrunt\n\nHCL (wraps Terraform/OpenTofu)\n\nSame as underlying Terraform/OpenTofu\n\nSame as underlying Terraform/OpenTofu\n\nSame as underlying Terraform/OpenTofu\n\nKeeping large Terraform/OpenTofu codebases DRY, not a language alternative\n\n## How to choose\n\nIf your team is standardizing on a single cloud and wants the deepest, most tightly integrated tooling for it, the native option, CloudFormation for AWS or Bicep for Azure, is a reasonable default, especially for smaller platform teams that don’t need cross-cloud abstraction. If you’re on AWS specifically and want general-purpose languages without leaving the CloudFormation ecosystem, AWS CDK is the more capable choice, with the caveat that its compile-then-deploy step adds a layer between code and infrastructure.\n\nIf your team is already running Kubernetes as its platform layer and wants infrastructure provisioning to follow the same GitOps and RBAC model as application workloads, Crossplane is worth a serious look, understanding that it comes with Kubernetes as a hard dependency.\n\nIf you’re deep in Terraform today, comfortable with HCL, and your primary concern is licensing and governance rather than language or workflow, OpenTofu is the lowest-friction path: same syntax, same providers, community governance instead of vendor governance.\n\nIf your team is investing in AI coding agents as part of its engineering workflow, wants multi-cloud reach without maintaining separate tools per provider, and values real testing, packaging, and code review practices for infrastructure the same way it does for application code, Pulumi is built specifically for that combination. It’s also the most direct migration path for teams currently on Terraform or CDKTF who want to move to a general-purpose language without changing which clouds they manage.\n\n## Frequently asked questions\n\n### Is Terraform still free to use?\n\nYes, for most teams. Terraform’s core CLI and the vast majority of its providers remain free under the Business Source License that HashiCorp adopted in August 2023. The license restricts a narrow set of commercial use cases, mainly building a competing managed offering on top of Terraform, which doesn’t affect ordinary infrastructure teams using it internally.\n\n### What is the best open-source Terraform alternative?\n\nOpenTofu is the closest open-source alternative if you want to keep using HCL and the Terraform provider ecosystem, since it’s a direct fork governed by the Linux Foundation. If open-source licensing matters but you’re open to a different language, Pulumi’s SDKs and CLI are open source (Apache 2.0), and Crossplane is a CNCF project for teams standardized on Kubernetes.\n\n### Which IaC tool works best with AI coding agents?\n\nTools built on general-purpose languages give AI coding agents the strongest foundation, since those agents have far more training exposure to real Python, TypeScript, Go, C#, and Java than to any infrastructure-specific DSL. Pulumi and AWS CDK both fit this category; AWS CDK’s compile step to CloudFormation adds a layer of indirection that Pulumi, which runs directly against provider APIs, doesn’t have.\n\n### Can I migrate from Terraform without rewriting everything?\n\nIt depends on which alternative you choose. Moving to OpenTofu requires essentially no rewriting, since it’s HCL-compatible by design. Moving to Pulumi, AWS CDK, or another general-purpose-language platform does require translating configuration into program code, though tools like Pulumi’s import and conversion tooling, and increasingly AI coding agents themselves, can automate a meaningful share of that translation rather than requiring a manual line-by-line rewrite.\n\n### Is Pulumi a drop-in Terraform replacement?\n\nNot syntactically. Pulumi uses general-purpose programming languages rather than HCL, so moving from Terraform to Pulumi means translating configuration into code rather than reusing files unchanged. What carries over is the underlying model: state, providers, and resources map conceptually in similar ways, and Pulumi provides tooling to import existing Terraform-managed infrastructure and convert Terraform configuration into a starting Pulumi program, which teams typically use as a first draft rather than a finished migration.\n\n### Does OpenTofu support everything Terraform does?\n\nOpenTofu tracks Terraform’s last open-source release closely and remains compatible with most existing Terraform configurations and providers. Since forking, its Linux Foundation-governed maintainers have also shipped features Terraform hadn’t offered, such as state encryption, while newer HashiCorp-only Terraform features naturally won’t appear in OpenTofu unless the community implements equivalents independently.\n\nFor a broader roundup covering the full infrastructure-as-code category rather than Terraform alternatives specifically, see our guide to [the best IaC tools](https://www.pulumi.com/what-is/top-iac-tools/).\n\n## Conclusion\n\nTerraform remains a capable, widely used tool, and for teams with no appetite to change, OpenTofu offers a nearly friction-free path to the same workflow under different governance. But the more interesting question for 2026 isn’t whether Terraform still works, it’s whether your infrastructure tooling can keep pace with how your engineering organization is actually building software now: with AI coding agents as active participants, not just autocomplete. That question favors platforms built on real, general-purpose languages, tested and reviewed the same way application code is, over any tool, new or established, still built around a purpose-specific configuration syntax. Evaluate honestly against your own cloud footprint, existing platform investment, and how central AI-assisted development already is to your team, and the right alternative, or the right reason to stay put, becomes clear quickly.","publishedAt":"2026-07-18T00:00:00.000Z","fetchedAt":"2026-07-20T21:21:24.881Z","url":"https://www.pulumi.com/blog/best-terraform-alternatives/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/best-terraform-alternatives/index.png","r2Key":"releases/8ebb3a423f1b0188d15ac15909f530de8b75a501e6e834b4a126735baf2a7413.png","r2Url":"https://media.releases.sh/releases/8ebb3a423f1b0188d15ac15909f530de8b75a501e6e834b4a126735baf2a7413.png"}],"coverageCount":0},{"id":"rel_mAuHGaA3-NACURZ0PdIKs","version":null,"type":"feature","title":"Connect Your Cloud Accounts to Pulumi in Minutes","summary":"New Connect cloud accounts wizard discovers every AWS account, Azure subscription, or Google Cloud project in an organization and onboards them all in a single guided flow, handling OIDC setup, ESC environments, and default scans and policies automatically.","titleGenerated":"Pulumi launches Connect cloud accounts wizard to onboard accounts in minutes","titleShort":"Connect cloud accounts wizard ships: bulk discover and onboard in minutes","breaking":"none","importance":4,"content":"![](https://www.pulumi.com/images/generated/blog/connect-your-cloud-accounts-to-pulumi-in-minutes/index.png)\n\n[Pulumi Insights](https://www.pulumi.com/docs/insights/) gives you visibility and governance across your entire cloud footprint, but that visibility is only as complete as the set of accounts you’ve connected. Until now, connecting an account meant repeating a manual setup for each one: OIDC configuration, hand-written [Pulumi ESC](https://www.pulumi.com/docs/esc/) environments, and per-account scan and policy setup. For an organization with dozens or hundreds of AWS accounts, Azure subscriptions, or Google Cloud projects, that per-account friction was the biggest obstacle to getting a complete picture. Today, the new **Connect cloud accounts** wizard removes it: discover every account in your cloud organization, select the ones you want, and onboard them all in a single guided flow.\n\n## From hours of setup to a single flow\n\nThe time savings are real: connecting a batch of accounts across AWS, Azure, and Google Cloud takes about three minutes end to end. Setting up those same accounts with the manual per-account workflow would take hours to days.\n\nThe wizard handles the entire onboarding lifecycle for AWS, Microsoft Azure, and Google Cloud:\n\n- **Bulk discovery**: Authenticate once with your cloud organization and the wizard lists every account, subscription, or project you can access. Accounts that are already connected are recognized and skipped.\n- **Automatic OIDC setup**: The recommended flows configure each account with short-lived credentials based on OpenID Connect (OIDC) and workload identity federation. No long-lived cloud secrets are stored in Pulumi Cloud.\n- **ESC environments, created for you**: The wizard generates [Pulumi ESC](https://www.pulumi.com/docs/esc/) environments that follow the best practices from the manual OIDC guides — environments that previously had to be authored one by one.\n- **Scans and policies from day one**: By default, scheduled discovery scans and a [pre-built policy pack](https://www.pulumi.com/docs/insights/policy/policy-packs/pre-built-packs/) are applied to every account as part of setup: the Pulumi Best Practices pack on the Team and Enterprise editions, or a compliance pack (CIS, or NIST 800-53 for AWS and Google Cloud) on Business Critical.\n\n## How it works\n\nThe wizard walks you through five steps: choose a provider, authenticate, select accounts, configure discovery and policy, and review the results. You can open it from **Insights** > **Accounts** in the Pulumi Cloud console, or from the **Get to know Pulumi** card on the home dashboard.\n\nAuthentication uses each provider’s native federation mechanism: IAM Identity Center (SSO) for AWS, Microsoft Entra ID workload identity federation for Azure, and Workload Identity Federation for Google Cloud. After you sign in, the wizard discovers the accounts in your organization and pre-selects everything that isn’t already connected. You can search, select all, or toggle individual accounts.\n\n![The account picker showing discovered AWS accounts with checkboxes, a search box, and a select all option](account-picker.png)\n\n### Choose the right access level for your security posture\n\nNot every team wants to grant write access on day one. The wizard offers two access levels, and you can set them per account:\n\n- **Build & Manage (read and write)**: Enables the full platform: [Pulumi Neo](https://www.pulumi.com/product/neo/), infrastructure as code, deployments, and policies that remediate issues automatically (Business Critical).\n- **Discovery & Policy (read-only)**: Limited to discovery scanning and inventory. Pulumi can’t modify your infrastructure.\n\nIf your security review requires it, start everything read-only and raise access for specific accounts later.\n\n![The accounts step showing the selected accounts summary, the Build and Manage access level card, and per account access controls](access-level.png)\n\n### Everything set up, nothing hidden\n\nWhen setup completes, the summary shows exactly what was created: the ESC environments grouped by access level, the state of discovery scanning, and the policy pack applied. If any account fails to connect, the summary lists it with the specific error so you can fix the cause and re-run the wizard. Accounts that connected successfully are skipped on retry.\n\n![The summary step showing setup complete with discovery running, the policy pack applied, and the list of created ESC environments](summary.png)\n\nFor security reviewers, the docs include a full accounting of [what the wizard creates](https://www.pulumi.com/docs/insights/discovery/connect-cloud-accounts/#what-the-wizard-creates) in your cloud provider and in Pulumi Cloud: the IAM roles, app registrations, and service accounts on the cloud side, and the ESC environments and Insights accounts on the Pulumi side.\n\n## Get started\n\nThe Connect cloud accounts wizard is available now for all Pulumi Cloud organizations. To connect your first accounts:\n\n1. Navigate to [**Insights** > **Accounts**](https://app.pulumi.com/) in the Pulumi Cloud console and select **Connect cloud accounts**.\n2. Follow the guided flow for AWS, Azure, or Google Cloud.\n3. Explore your [discovered resources](https://www.pulumi.com/docs/insights/discovery/search/) and [policy findings](https://www.pulumi.com/docs/insights/policy/policy-findings/).\n\nTo learn more:\n\n- [Connect cloud accounts documentation](https://www.pulumi.com/docs/insights/discovery/connect-cloud-accounts/) — prerequisites, each wizard step in detail, and troubleshooting\n- [Insights & Governance overview](https://www.pulumi.com/docs/insights/) — full documentation for discovery and policy capabilities\n- [Pulumi ESC](https://www.pulumi.com/docs/esc/) — how the generated environments manage cloud credentials with OIDC","publishedAt":"2026-07-15T00:00:00.000Z","fetchedAt":"2026-07-15T05:19:32.174Z","url":"https://www.pulumi.com/blog/connect-your-cloud-accounts-to-pulumi-in-minutes/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/connect-your-cloud-accounts-to-pulumi-in-minutes/index.png","r2Key":"releases/ef2cded1d9db1de237c51610678644af4b69327140e1e49204d8588d60f701df.png","r2Url":"https://media.releases.sh/releases/ef2cded1d9db1de237c51610678644af4b69327140e1e49204d8588d60f701df.png"}],"coverageCount":0},{"id":"rel_BerdqhK8cCghwoWmApRFu","version":null,"type":"feature","title":"Introducing Usage Limits for Pulumi Neo","summary":"Usage limits for Pulumi Neo let organizations set a monthly dollar cap that pauses the AI agent when reached. Per-member limits and email notifications at 50%, 80%, 95%, and 100% are also available for paid plan organizations.","titleGenerated":"Pulumi Neo adds monthly usage limits and per-member controls","titleShort":"Neo usage limits: monthly dollar cap and per-member controls","breaking":"none","importance":3,"content":"![](https://www.pulumi.com/images/generated/blog/neo-usage-limits/index.png)\n\n[Pulumi Neo](https://www.pulumi.com/docs/ai/) is an AI agent that takes on real infrastructure work, and it’s natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it.\n\n## How usage limits work\n\nYour organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one:\n\n1. In the Pulumi Cloud console, navigate to **Settings → Billing & usage → Neo token usage**.\n2. In the **Manage token usage** panel, enter an organization limit.\n3. Save your changes.\n\nWhen usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then.\n\n![The Manage token usage panel, where an admin sets the organization’s monthly Neo limit and turns on email notifications.](manage-token-usage.png)\n\nEnforcement happens at a natural boundary in Neo’s work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit.\n\n## Per-member limits and alerts\n\nYou can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization’s. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller.\n\n![The per-member limits table, showing each member’s amount used and effective limit for the billing period.](per-member-limits.png)\n\nTurn on **Enable email notifications** to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses.\n\n## Get started\n\nSet your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an **Admin** or **Billing Manager** can set them.\n\n- [Sign in to Pulumi Cloud](https://app.pulumi.com/signin) and set your first organization limit\n- [Read the Neo usage limits documentation](https://www.pulumi.com/docs/ai/usage-limits/) for per-member limits, alerts, and enforcement details\n- [Join the Community Slack](https://slack.pulumi.com/) to share your feedback","publishedAt":"2026-07-14T15:00:00.000Z","fetchedAt":"2026-07-15T01:19:34.927Z","url":"https://www.pulumi.com/blog/neo-usage-limits/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/neo-usage-limits/index.png","r2Key":"releases/7ccbf967642cb69e495a361e09f5e7ae1a9a738112fa10be8bc824db220741ea.png","r2Url":"https://media.releases.sh/releases/7ccbf967642cb69e495a361e09f5e7ae1a9a738112fa10be8bc824db220741ea.png"}],"coverageCount":0},{"id":"rel_ZXUkhuZVB67Gxq8hRaiyQ","version":null,"type":"feature","title":"Knowledge as Code: The Memory File Just Got a Spec","summary":"Google's Open Knowledge Format (OKF) v0.1 formalizes the Karpathy wiki pattern as a specification: markdown files with YAML frontmatter, organized in a directory tree with reserved index.md and log.md filenames. Platform teams can now store runbooks, decision records, and architecture knowledge as code alongside their Pulumi infrastructure, linked via the resource field mapping to Pulumi URNs.","titleGenerated":"Pulumi explores Open Knowledge Format for agent-accessible infrastructure knowledge","titleShort":"Open Knowledge Format brings agent-readable wiki to infrastructure","breaking":"none","importance":2,"content":"![](https://www.pulumi.com/images/generated/blog/knowledge-as-code-the-memory-file-just-got-a-spec/index.png)\n\nFive weeks ago I wrote that the least glamorous piece of an agent loop is also the one that decides whether it compounds: [memory](https://www.pulumi.com/blog/stop-prompting-design-the-loop/). A markdown file outside the context window that holds what is done, what is next, and what was learned, because the model forgets all of it between runs. Write the memory file before the loop.\n\nWhat I left open, because there was nothing to point at, was the format. My memory file looked nothing like yours, and neither of our agents could read the other’s.\n\nThree days after that post went live, Google shipped an answer.\n\n## The pattern everyone copied\n\n[Andrej Karpathy published a gist in April](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) he called the LLM wiki, and it collected thousands of stars and forks. It’s meant to be pasted straight into a coding agent. Instead of indexing your documents for RAG and re-deriving answers from raw text on every query, the agent builds a wiki and keeps it current: interlinked markdown pages, an `index.md` with a one-line summary per page, a `log.md` recording every change, entity pages that grow as sources come in. Drop in a meeting transcript and the agent reads it, updates a dozen existing pages, fixes the cross-references, and appends to the log in one pass.\n\nIt took off for the same reason wikis usually die. A knowledge base is valuable in exact proportion to the bookkeeping nobody wants to do: summarizing, linking, reconciling contradictions, pruning stale claims. Karpathy’s line, which Google now quotes back in its own announcement, is that LLMs “don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.” The human curates sources and asks questions. The agent does the janitorial work that made every previous wiki rot.\n\n## A wiki only your agent can read\n\nThen everyone built one, and every one is a dialect. Mine links related pages in the frontmatter; yours links them at the bottom of the body. Mine has a `tags` field; yours calls it `categories`. None of this matters while the wiki serves one person, because the schema lives in your `CLAUDE.md` and your agent reads it on every run.\n\nIt matters the moment the wiki has to travel. Hand your knowledge base to a teammate and their agent starts guessing at your conventions, or misses half the structure entirely. A platform team that wants one shared wiki, queried independently by everyone’s agents, has no format to agree on. A knowledge base you can’t hand to someone else’s agent is a silo of one. And a team’s collective knowledge should outlive any single person’s markdown habits.\n\n## What Google actually shipped: the Open Knowledge Format\n\nOn June 12, two tech leads in Google Cloud’s data analytics engineering org [announced the Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/), with a [spec and reference tooling on GitHub](https://github.com/GoogleCloudPlatform/knowledge-catalog). Strip the branding and OKF v0.1 is a formalization of the Karpathy pattern:\n\n- A bundle is a directory tree of markdown files. Two filenames are reserved: `index.md` for progressive disclosure and `log.md` for update history. Everything else is a concept document.\n- Every concept carries YAML frontmatter with exactly one required field: `type`. Five more are recommended: `title`, `description`, `resource`, `tags`, `timestamp`. Producers can add anything; consumers must preserve what they don’t understand.\n- A markdown link from one concept to another asserts a relationship. The prose around the link says what kind.\n\nThe whole spec fits on a page, and that’s deliberate. The announcement names three principles: minimally opinionated; producers and consumers independently swappable; a format rather than a platform. No required SDK, no compression scheme, no new runtime. Reading a bundle is `cat`; distributing one is `git clone`. The repo backs it up with reference tooling: an enrichment agent that drafts concept docs from BigQuery datasets, and a static visualizer that renders a bundle as a graph. Three sample bundles, built by that same agent, give you something to copy from.\n\n## The critique is the feature\n\nThe pushback writes itself: there is almost nothing here. Folder indexes and five suggested frontmatter fields, on top of a pattern the community already had. True. Also the point.\n\nThe standards that stick are embarrassingly small. [MCP](https://www.pulumi.com/docs/ai/mcp-server/) didn’t model your tools; it standardized the socket they plug into. `AGENTS.md` fixed nothing but a filename, and that was enough for [Neo to read the same conventions file as every other agent](https://www.pulumi.com/blog/pulumi-neo-now-supports-agentsmd/). [Agent Skills](https://www.pulumi.com/docs/ai/skills/) gave procedure a place to live, and docs sites settled on [/llms.txt](https://www.pulumi.com/llms.txt) for published content. Knowledge was the layer still missing its boring little standard. Whether OKF specifically is the one that survives matters less than the shape it commits to: markdown, frontmatter, git. Every other layer of the agent stack already landed there, so that bet is safe.\n\n## Knowledge as code\n\nPlatform teams should care about this before anyone else. Infrastructure as code captures the what: the resources, the config, the dependency graph. It has never captured the why. The runbook for rotating credentials, the decision record explaining the pinned CNI version, who owns the cluster, what the incident in November taught you. That knowledge lives in a wiki behind an API, a shared drive, a Slack thread, and the heads of two senior engineers. Google’s announcement frames this fragmentation as the problem: agents reassembling answers from systems that each speak a proprietary format.\n\nOKF’s answer is a move platform engineers will recognize, because it’s the same one that produced IaC: put it in git, make it diffable, review changes in pull requests. Knowledge as code, sitting next to the infrastructure as code it explains:\n\n```\nplatform/\n├── index.md\n├── log.md\n├── services/\n│ ├── index.md\n│ ├── checkout-api.md\n│ └── payments-worker.md\n├── runbooks/\n│ ├── index.md\n│ └── rotate-database-credentials.md\n└── decisions/\n├── index.md\n└── why-we-pin-the-vpc-cni-version.md\n```\n\nThe recommended `resource` field takes a URI naming the asset a concept describes, and a Pulumi URN is exactly that:\n\n```yaml\n---\ntype: runbook\ntitle: Rotate the payments database credentials\ndescription: Zero-downtime credential rotation for the payments Postgres instance.\nresource: urn:pulumi:prod::payments::aws:rds/instance:Instance::payments-db\ntags: [payments, postgres]\ntimestamp: 2026-07-01T09:30:00Z\n---\n\n```\n\nNow the runbook names the exact resource it operates on. An agent planning a change to that database can walk from the URN to the runbook to the decision record that explains the constraint, before it proposes anything. In the loop post I said [skills](https://www.pulumi.com/docs/ai/skills/) are intent written down, the conventions an agent reads instead of guessing. A knowledge bundle is the other half: experience written down. Tools give the loop hands, skills give it habits, and the bundle is what it gets to remember.\n\nBefore writing any of that down, I ran the test. A fresh agent got two inputs, the spec and this bundle, and one question: which services touch the payments database, and how do I rotate its credentials without downtime? It read six files and answered correctly, down to why rotating a second time too soon is the dangerous move. What sold me was the file it didn’t read. It left the CNI decision record closed, because the cross-links mark that page as a cluster concern, not a database one.\n\nThe bundle is public, exactly the tree above. Clone it, hand your agent the spec, and ask your own questions:\n\n[![GitHub repository: dirien/pulumi-platform-okf-bundle](https://opengraph.githubassets.com/1/dirien/pulumi-platform-okf-bundle)\n\ngithub.com/dirien/pulumi-platform-okf-bundle\n\n](https://github.com/dirien/pulumi-platform-okf-bundle)\n\n## What a standard won’t do for you\n\nThree caveats, so nobody mistakes this for magic.\n\n**It formats knowledge; it doesn’t create it.** The warning from the loop post applies with no edits: memory is what lets a loop compound, and slop compounds right alongside it. A wrong runbook in a beautifully conformant bundle is still a wrong runbook, now served to every agent on the team with confidence. The leverage isn’t the format. It’s that knowledge changes finally go through review like code changes.\n\n**v0.1 is a draft, and the name may not survive.** Google says so itself: the announcement calls v0.1 “a starting point, not a finished standard.” OKF could lose to a better spec next year. I’d start anyway, because converting markdown with frontmatter into markdown with slightly different frontmatter is the cheapest migration you’ll ever run, and it’s precisely the kind of mechanical pass an agent finishes in an afternoon. The shape is the commitment. The name is a detail.\n\n**Conformance is a floor, not hygiene.** The spec requires consumers to tolerate broken links, missing indexes, and unknown types. That tolerance keeps readers working, and it also means nothing forces your bundle to stay healthy. Karpathy’s gist included a lint pass for a reason: contradictions, orphaned pages, stale claims. Keep it, and run it the way you lint code, on a schedule, with findings that reach a human.\n\n## Where to start\n\n1. **Pick the knowledge that already hurts.** The runbook nobody can find during an incident, the onboarding doc that’s wrong in ways only one person knows. One domain, not the whole org.\n2. **Let the agent do the conversion.** Paste the [spec](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) into your coding agent, point it at the existing folder of docs, and have it refactor them into a bundle. This is exactly the bookkeeping LLMs are good at, and it works as well on a wiki export as on a fresh start.\n3. **Put the bundle where the code lives.** Same repo or a sibling, but in git, behind pull requests. The day a knowledge change gets a review comment is the day the bundle becomes trustworthy.\n4. **Wire it into the loop.** Agents read `index.md` first and drill down only when a concept earns it, which keeps the context window small. The memory file I told you to write before the loop now has a format, and every agent you run, in [whatever harness you built](https://www.pulumi.com/blog/stop-tuning-prompts-build-a-harness/), can read the same one.\n\nThe advice from June holds: write the memory file before the loop. What changed is that the file no longer has to be a private dialect. There’s now a one-page, git-native spec for the layer your agents think with, and the smallness that makes it look trivial is the property that lets it spread. The loop does the typing. The wiki does the remembering. And the remembering is now something you can put in a pull request and hand to the next agent, like everything else you ship.\n\n[Wire Pulumi context into your agents](https://www.pulumi.com/docs/ai/)","publishedAt":"2026-07-14T00:00:00.000Z","fetchedAt":"2026-07-15T01:19:34.927Z","url":"https://www.pulumi.com/blog/knowledge-as-code-the-memory-file-just-got-a-spec/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/knowledge-as-code-the-memory-file-just-got-a-spec/index.png","r2Key":"releases/1101eff54b0488b225d0793887eca73c9fc3a3f07119a062c2bdb216ee43c3b0.png","r2Url":"https://media.releases.sh/releases/1101eff54b0488b225d0793887eca73c9fc3a3f07119a062c2bdb216ee43c3b0.png"},{"type":"image","url":"https://opengraph.githubassets.com/1/dirien/pulumi-platform-okf-bundle","alt":"GitHub repository: dirien/pulumi-platform-okf-bundle","r2Key":"releases/a591a3166155f2f1a5b8e3dc9a2f8955f406dcad64bdcd2d1c1b66a05a238834.png","r2Url":"https://media.releases.sh/releases/a591a3166155f2f1a5b8e3dc9a2f8955f406dcad64bdcd2d1c1b66a05a238834.png"}],"coverageCount":0},{"id":"rel__lVl1_pspFTIGWBuMrWDc","version":null,"type":"feature","title":"Sign in to Pulumi Cloud with Passkeys","summary":"Pulumi Cloud now supports passkeys for users who sign in with email and password, using Touch ID, Face ID, Windows Hello, or hardware keys. Passkeys are phishing-resistant and synced across devices; existing password and MFA configurations remain unchanged.","titleGenerated":"Pulumi Cloud adds passkey support for email-password sign-in","titleShort":"Passkey sign-in for Pulumi Cloud accounts","breaking":"none","importance":3,"content":"![](https://www.pulumi.com/blog/passkey-support-in-pulumi-cloud/meta.png)\n\nPulumi Cloud now supports passkeys for users who sign in with email and password. Select a button, approve with Touch ID, Face ID, Windows Hello, or your hardware key, and you’re signed in.\n\nA passkey is a public-key credential stored on your device: your phone, your laptop, a hardware key (YubiKey, Google Titan, etc.), or your password manager can all function as the authenticator. When you sign in, your device authenticates you locally and signs a challenge from Pulumi Cloud with the private key.\n\nThe private key stays on your device — Pulumi Cloud never sees or stores it. Passkeys are built on the [WebAuthn](https://www.w3.org/TR/webauthn-3/) standard, so they’re already supported on every major browser and operating system.\n\n## Who this is for\n\nThis release applies to users who sign in to Pulumi Cloud with an email address and password. If you sign in through an identity provider (IdP), such as GitHub OAuth, GitLab, Bitbucket, Google, or your organization’s SAML SSO, your existing flow is unchanged.\n\n## Why passkeys\n\nPasswords have always been the weakest link in account security. Since they are shared secrets, they are vulnerable to phishing attacks, and every place you type one is a place that can be impersonated or a data store that can be leaked. Passkeys swap that out for a per-site key pair that lives on your device:\n\n- **Phishing-resistant by design.** A passkey is bound to the exact origin it was registered for. A look-alike domain can’t trigger your authenticator.\n- **Synced across your devices.** Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden: most credential managers now sync passkeys end-to-end-encrypted to every device you’ve signed in on.\n- **Discoverable.** Pulumi Cloud doesn’t need to know which user you are before you authenticate. Just select “Sign in with a passkey” and your device offers the right credential.\n- **Nothing to remember.** A passkey lives on your device. There’s no string to memorize, and no sensitive credential stored by us.\n\n## Setting up a passkey\n\nThe next time you sign in with a password, Pulumi Cloud will ask if you’d like to configure a passkey. It’s a single-step prompt, so you can enroll once and take advantage of passkeys on every subsequent sign-in.\n\nIf you dismiss the prompt and would like to add one later, or want to add multiple passkeys, navigate to **Account Settings → Passkeys** under your user profile. Select **Register a passkey**, complete the OS-level prompt (Touch ID, Face ID, Windows Hello, or your hardware key), and you’re done. Pulumi Cloud will pick a sensible default name like `\"iCloud Keychain\"` or `\"Chrome on macOS\"` based on the authenticator, but you can rename it inline anytime under **Account Settings → Passkeys**.\n\n![Pulumi Cloud Account Settings page showing the Passkeys section, with a “Register a passkey” button and an enrolled passkey named “Pulumipus’s iPhone”.](https://www.pulumi.com/blog/passkey-support-in-pulumi-cloud/account-settings-passkeys.png)\n\nYou can register as many passkeys as you want. Typical setups are one per personal device, or one synced credential plus a hardware key as backup. Removing a passkey takes effect immediately; deleted credentials cannot be used to sign in.\n\n## Signing in\n\nDepending on how you arrive:\n\n- **Explicit sign-in.** On the sign-in page, select **Sign in with a passkey**. Your browser opens the passkey picker, and you authenticate from there.\n- **Autofill.** If your browser supports [conditional mediation](https://web.dev/articles/passkey-form-autofill) (Chrome, Safari, Edge, recent Firefox), the email field on the sign-in page proactively offers your registered passkeys as autofill suggestions. Pick one and you’re signed in.\n\n## What about my existing password and MFA?\n\nYour existing password still works. Passkeys are an additional sign-in option, not a replacement, and they don’t disable password sign-in on your account. If you lose access to every registered passkey, you can still sign in with your email and password as you always have, then register a new passkey from settings.\n\n**Other 2FA still applies.** If you have TOTP-based MFA enabled on your Pulumi account, a passkey sign-in will still prompt for your second factor. WebAuthn doesn’t reliably tell us *how* you unlocked the passkey on your device (biometric, PIN, or something weaker), so we can’t safely treat the passkey itself as proof of two factors. Your existing MFA configuration remains the boundary it always was.\n\n## Try it out\n\nPasskey support is generally available today for every Pulumi Cloud user who signs in with email and password, at no additional cost and with no configuration. Visit [your account settings](https://app.pulumi.com/account/profile) to register your first passkey, and let us know what you think on [our community Slack](https://slack.pulumi.com/) or [GitHub](https://github.com/pulumi/pulumi/issues).","publishedAt":"2026-07-13T00:00:00.000Z","fetchedAt":"2026-07-15T01:19:34.927Z","url":"https://www.pulumi.com/blog/passkey-support-in-pulumi-cloud/","media":[{"type":"image","url":"https://www.pulumi.com/blog/passkey-support-in-pulumi-cloud/meta.png","r2Key":"releases/c14d3a22f7acdd93ec623966995cece12eb7b510405b910088bd1ce0e7307c0c.png","r2Url":"https://media.releases.sh/releases/c14d3a22f7acdd93ec623966995cece12eb7b510405b910088bd1ce0e7307c0c.png"},{"type":"image","url":"https://www.pulumi.com/blog/passkey-support-in-pulumi-cloud/account-settings-passkeys.png","alt":"Pulumi Cloud Account Settings page showing the Passkeys section, with a “Register a passkey” button and an enrolled passkey named “Pulumipus’s iPhone”.","r2Key":"releases/fa3aa269d704de46e8f81535c2bbed2307e2af7f1e7a0b5af0e7b1a839403399.png","r2Url":"https://media.releases.sh/releases/fa3aa269d704de46e8f81535c2bbed2307e2af7f1e7a0b5af0e7b1a839403399.png"}],"coverageCount":0},{"id":"rel_DywsZ2-PeHOcWfXNXZ-ze","version":null,"type":"feature","title":"New: Versioned CLI and SDK Docs","summary":"The Pulumi CLI command reference and SDK API documentation (Node.js, Python, .NET, Java) now include a version selector dropdown, allowing users to view documentation matching their installed version. Immutable snapshots are available back to v3.150.0.","titleGenerated":"Pulumi documentation now includes version selector for CLI and SDK docs","titleShort":"CLI and SDK docs now versioned back to v3.150.0","breaking":"none","importance":2,"content":"![](https://www.pulumi.com/images/generated/blog/previous-cli-and-sdk-version-docs/index.png)\n\nPinned to an older Pulumi CLI or SDK version and finding that the docs describe a newer release? The [Pulumi CLI command reference](https://www.pulumi.com/docs/iac/cli/commands/) and the SDK API docs now include a version selector, so the documentation you’re reading matches the version you’re actually running.\n\n## How it works\n\nWhen you open the [CLI command reference](https://www.pulumi.com/docs/iac/cli/commands/), you’ll see a version dropdown near the top of the page, below the title. The SDK API docs carry the same dropdown in the upper-right corner. Choose a release, and the page loads the documentation generated for that exact version.\n\n![Version selector near the top of the Pulumi CLI command reference](cli-version-selector.png)\n\n![Version selector in the upper-right corner of the Pulumi Node.js SDK API docs](sdk-version-selector.png)\n\n## What’s available\n\nAlongside the latest release, we keep immutable snapshots of previous versions going back to v3.150.0 (early 2025). The CLI command reference and the Node.js, Python, .NET, and Java SDK API docs are all covered, so the docs you need are only a dropdown away. (The Go SDK is versioned on [pkg.go.dev](https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v3), so its documentation lives there rather than in the Pulumi docs.)\n\n## Get started\n\nHead to the [CLI command reference](https://www.pulumi.com/docs/iac/cli/commands/) or the [SDK API docs](https://www.pulumi.com/docs/reference/) and try the version dropdown. Selections are sticky, so when you navigate into a version, you’ll be able to click around within that same version without having to choose it again.\n\nHave feedback? Let us know in the [Pulumi Community Slack](https://slack.pulumi.com) or by opening an issue on [GitHub](https://github.com/pulumi/docs).\n\n[Browse the CLI command reference](https://www.pulumi.com/docs/iac/cli/commands/)","publishedAt":"2026-07-07T00:00:00.000Z","fetchedAt":"2026-07-08T05:03:36.899Z","url":"https://www.pulumi.com/blog/previous-cli-and-sdk-version-docs/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/previous-cli-and-sdk-version-docs/index.png","r2Key":"releases/db9ea628cda98168aef2c47dc5665b8c1784df8cc54d9918fa3bf8bfb758f04f.png","r2Url":"https://media.releases.sh/releases/db9ea628cda98168aef2c47dc5665b8c1784df8cc54d9918fa3bf8bfb758f04f.png"}],"coverageCount":0},{"id":"rel_VQuSav1quHs6neFXwJe2j","version":null,"type":"feature","title":"Most Effective Infrastructure as Code (IaC) Tools","summary":"![](https://www.pulumi.com/images/generated/blog/infrastructure-as-code-tools/index.png)\n\nInfrastructure as Code (IaC) has evolved beyond simple autom...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/images/generated/blog/infrastructure-as-code-tools/index.png)\n\nInfrastructure as Code (IaC) has evolved beyond simple automation into a fundamental shift toward applying software engineering practices to infrastructure management. In 2026, leading organizations aren’t just provisioning infrastructure—they’re treating it as software, complete with testing, version control, code reviews, and continuous integration.\n\nAs 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.\n\nThis 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.\n\nReady to try one of these approaches yourself? [Get started with Pulumi for free](https://www.pulumi.com/docs/install/) and provision your first resource in minutes, or [see Pulumi Neo in action](https://www.pulumi.com/product/neo/) to explore how an AI agent can manage infrastructure changes alongside your team.\n\n## What is Infrastructure as Code?\n\n[Infrastructure as Code (IaC)](https://www.pulumi.com/what-is/what-is-infrastructure-as-code/) is an approach to automating the provisioning and management of infrastructure using software engineering principles, approaches, and tools. Rather than manually configuring servers, networks, and cloud resources through user interfaces or command-line tools, IaC enables you to define your entire infrastructure declaratively through code.\n\nThis approach brings the same benefits that have revolutionized software development—version control, automated testing, code reviews, and CI/CD pipelines—to infrastructure management.\n\n## What Are Infrastructure as Code Tools?\n\nInfrastructure as Code tools are platforms and frameworks that enable you to define, provision, and manage infrastructure resources through code rather than manual processes. These tools translate your infrastructure definitions into API calls that create, modify, or destroy cloud resources across various providers.\n\nThe most effective IaC tools share several key characteristics:\n\n- **Goal-state focus**: Define your desired infrastructure outcome, whether through declarative syntax (like YAML/JSON templates) or imperative languages that express declarative intent\n- **Multi-cloud support**: Work across different cloud providers and services\n- **State management**: Track the current state of your infrastructure\n- **Preview capabilities**: Show what changes will be made before applying them\n- **Idempotency**: Safe to run multiple times with consistent results\n\n## Why Infrastructure as Code Tools Are Essential\n\nThe shift to IaC tools addresses fundamental challenges that manual infrastructure management cannot solve at scale:\n\n**Accelerates Deployment Velocity**: Teams can provision complex multi-cloud architectures in minutes instead of weeks. This speed enables faster time-to-market and more frequent, reliable deployments.\n\n**Enables True Collaboration**: Infrastructure becomes code that teams can review, test, and approve together. This collaborative approach reduces errors and ensures knowledge sharing across the organization.\n\n**Eliminates Configuration Drift**: Manual changes lead to inconsistencies between environments. IaC ensures your production, staging, and development environments remain identical, eliminating the notorious “works on my machine” syndrome for infrastructure.\n\n**Provides Cost Control**: Automated provisioning and deprovisioning prevents resource sprawl. Teams can easily track infrastructure costs, set budget alerts, and optimize resource usage across environments.\n\n**Ensures Compliance and Security**: Codified security policies and compliance requirements are automatically enforced across all deployments. Audit trails become automatic, and policy violations are caught before deployment.\n\n**Guarantees Business Continuity**: Complete infrastructure definitions stored in version control enable rapid disaster recovery. Organizations can reconstruct entire environments from code, minimizing downtime and data loss.\n\n## Infrastructure as Code Tools Overview\n\nThis guide covers the following infrastructure as code tools and platforms:\n\n### 10 Most Used IaC Tools in 2026\n\n1. **Pulumi IaC** - Modern IaC with general-purpose programming languages\n2. **Terraform** - BSL-licensed IaC from HashiCorp that uses the HCL domain-specific language\n3. **AWS CDK** - Cloud Development Kit for AWS\n4. **AWS CloudFormation** - Native AWS integration\n5. **Azure Resource Manager (ARM)** - Native Azure JSON templates\n6. **Azure Bicep** - Azure-native domain-specific language that compiles to ARM\n7. **Google Cloud Infrastructure Manager** - Terraform-based solution for Google Cloud\n8. **Kubernetes YAML** - Native Kubernetes resource definitions\n9. **Crossplane** - Kubernetes as universal control plane\n10. **OpenTofu** - Open-source Terraform alternative\n\n### Configuration Management Tools\n\n- **Chef** - Configuration management and compliance automation\n- **Puppet** - Configuration management and compliance automation\n- **Salt** - Configuration management and remote execution\n\n### Application and Platform Management Tools\n\n- **Kubernetes** - Container orchestration platform\n\n### Security and Compliance Tools\n\n- **Pulumi ESC** - Configuration and secrets management platform\n- **Pulumi Insights** - Cloud resource search, analytics, and compliance platform\n- **Snyk** - Developer security platform with IaC scanning\n- **Wiz** - Comprehensive cloud security platform\n- **HashiCorp Sentinel** - Policy-as-code framework for Terraform\n- **Checkov** - Static analysis for IaC security\n- **TFLint** - Terraform linting and validation\n\n### Infrastructure Automation and Management Platforms\n\n- **Pulumi Cloud** - Managed service for Pulumi IaC with enterprise features\n- **HashiCorp Cloud Platform** - Enterprise SaaS platform for Terraform management and automation\n- **Spacelift** - Automation platform for IaC workflows (not an IaC tool itself)\n- **Env0** - Governance and automation platform for existing IaC tools\n\n## Core Infrastructure as Code Tools\n\n### 1\\. Pulumi\n\nLicense: Apache 2.0 \nBest For: Teams who want flexible, language-agnostic IaC for infrastructure and operations\n\nPulumi IaC represents a modern approach to infrastructure as code, fundamentally changing how teams approach infrastructure by enabling the use of general-purpose programming languages like Python, TypeScript, Go, C#, and Java, plus YAML for simpler configurations. Unlike tools that force teams to learn proprietary domain-specific languages (DSLs), Pulumi leverages familiar languages and software engineering practices, providing unprecedented flexibility, powerful abstractions, and seamless integration with existing development workflows.\n\nPulumi’s approach combines the best of both imperative and declarative paradigms: you use imperative programming languages to define your desired infrastructure state, but the Pulumi engine processes this declaratively to determine what changes are needed to achieve your intended outcome.\n\n### Key Features:\n\n- **Universal language support**: Use Python, TypeScript, Go, C#, Java, or YAML configurations—no new DSL to learn\n- **Any cloud, any architecture**: Deploy to AWS, Azure, Google Cloud, Kubernetes, and 100+ other providers\n- **Real programming constructs**: Leverage loops, conditionals, functions, classes, packages, and third-party libraries\n- **Superior developer experience**: Full IDE support with IntelliSense, debugging, and refactoring\n- **Built-in testing**: [Unit and integration testing](https://www.pulumi.com/docs/using-pulumi/testing/) for infrastructure code\n- **Policy as Code**: Enforce compliance and security policies with [CrossGuard](https://www.pulumi.com/docs/using-pulumi/crossguard/)\n- **Component ecosystem**: Rich library of reusable infrastructure components\n\nUniversal Language Code Examples:\n\n```typescript\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as aws from \"@pulumi/aws\";\nimport * as awsx from \"@pulumi/awsx\";\n\n// Create a VPC with automatic subnets\nconst vpc = new awsx.ec2.Vpc(\"main-vpc\", {\n cidrBlock: \"10.0.0.0/16\",\n numberOfAvailabilityZones: 2,\n});\n\n// Create an ECS cluster\nconst cluster = new aws.ecs.Cluster(\"app-cluster\");\n\n// Create an Application Load Balancer\nconst alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer(\"app-alb\", {\n vpcId: vpc.vpcId,\n subnetIds: vpc.publicSubnetIds,\n});\n\n// Deploy a containerized application\nconst service = new awsx.ecs.FargateService(\"app-service\", {\n cluster: cluster.arn,\n taskDefinitionArgs: {\n container: {\n image: \"nginx:latest\",\n memory: 128,\n ports: [{\n containerPort: 80,\n targetGroup: alb.defaultTargetGroup,\n }],\n },\n },\n});\n\nexport const vpcId = vpc.vpcId;\nexport const serviceUrl = alb.loadBalancer.dnsName;\n\n```\n\n```python\nimport pulumi\nimport pulumi_aws as aws\nimport pulumi_awsx as awsx\n\n# Create a VPC with automatic subnets\nvpc = awsx.ec2.Vpc(\"main-vpc\",\n cidr_block=\"10.0.0.0/16\",\n number_of_availability_zones=2)\n\n# Create an ECS cluster\ncluster = aws.ecs.Cluster(\"app-cluster\")\n\n# Create an Application Load Balancer\nalb = awsx.elasticloadbalancingv2.ApplicationLoadBalancer(\"app-alb\",\n vpc_id=vpc.vpc_id,\n subnet_ids=vpc.public_subnet_ids)\n\n# Deploy a containerized application\nservice = awsx.ecs.FargateService(\"app-service\",\n cluster=cluster.arn,\n task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs(\n container=awsx.ecs.TaskDefinitionContainerDefinitionArgs(\n image=\"nginx:latest\",\n memory=128,\n ports=[awsx.ecs.TaskDefinitionPortMappingArgs(\n container_port=80,\n target_group=alb.default_target_group\n )]\n )\n ))\n\npulumi.export(\"vpc_id\", vpc.vpc_id)\npulumi.export(\"service_url\", alb.load_balancer.dns_name)\n\n```\n\n```go\npackage main\n\nimport (\n \"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ecs\"\n \"github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ec2\"\n \"github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/elasticloadbalancingv2\"\n awsxecs \"github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ecs\"\n \"github.com/pulumi/pulumi/sdk/v3/go/pulumi\"\n)\n\nfunc main() {\n pulumi.Run(func(ctx *pulumi.Context) error {\n // Create a VPC with automatic subnets\n vpc, err := ec2.NewVpc(ctx, \"main-vpc\", &ec2.VpcArgs{\n CidrBlock: pulumi.String(\"10.0.0.0/16\"),\n NumberOfAvailabilityZones: pulumi.Int(2),\n })\n if err != nil {\n return err\n }\n\n // Create an ECS cluster\n cluster, err := ecs.NewCluster(ctx, \"app-cluster\", nil)\n if err != nil {\n return err\n }\n\n // Create an Application Load Balancer\n alb, err := elasticloadbalancingv2.NewApplicationLoadBalancer(ctx, \"app-alb\", &elasticloadbalancingv2.ApplicationLoadBalancerArgs{\n VpcId: vpc.VpcId,\n SubnetIds: vpc.PublicSubnetIds,\n })\n if err != nil {\n return err\n }\n\n // Deploy a containerized application\n _, err = awsxecs.NewFargateService(ctx, \"app-service\", &awsxecs.FargateServiceArgs{\n Cluster: cluster.Arn,\n TaskDefinitionArgs: &awsxecs.FargateServiceTaskDefinitionArgs{\n Container: &awsxecs.TaskDefinitionContainerDefinitionArgs{\n Image: pulumi.String(\"nginx:latest\"),\n Memory: pulumi.Int(128),\n Ports: awsxecs.TaskDefinitionPortMappingArray{\n &awsxecs.TaskDefinitionPortMappingArgs{\n ContainerPort: pulumi.Int(80),\n TargetGroup: alb.DefaultTargetGroup,\n },\n },\n },\n },\n })\n if err != nil {\n return err\n }\n\n ctx.Export(\"vpcId\", vpc.VpcId)\n ctx.Export(\"serviceUrl\", alb.LoadBalancer.DnsName())\n return nil\n })\n}\n\n```\n\n```csharp\nusing System.Collections.Generic;\nusing Pulumi;\nusing Aws = Pulumi.Aws;\nusing Awsx = Pulumi.Awsx;\n\nreturn await Deployment.RunAsync(() =>\n{\n // Create a VPC with automatic subnets\n var vpc = new Awsx.Ec2.Vpc(\"main-vpc\", new()\n {\n CidrBlock = \"10.0.0.0/16\",\n NumberOfAvailabilityZones = 2,\n });\n\n // Create an ECS cluster\n var cluster = new Aws.Ecs.Cluster(\"app-cluster\");\n\n // Create an Application Load Balancer\n var alb = new Awsx.ElasticLoadBalancingV2.ApplicationLoadBalancer(\"app-alb\", new()\n {\n VpcId = vpc.VpcId,\n SubnetIds = vpc.PublicSubnetIds,\n });\n\n // Deploy a containerized application\n var service = new Awsx.Ecs.FargateService(\"app-service\", new()\n {\n Cluster = cluster.Arn,\n TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs\n {\n Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs\n {\n Image = \"nginx:latest\",\n Memory = 128,\n Ports = new[]\n {\n new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs\n {\n ContainerPort = 80,\n TargetGroup = alb.DefaultTargetGroup,\n },\n },\n },\n },\n });\n\n return new Dictionary<string, object?>\n {\n [\"vpcId\"] = vpc.VpcId,\n [\"serviceUrl\"] = alb.LoadBalancer.Apply(lb => lb.DnsName),\n };\n});\n\n```\n\n```yaml\nname: aws-ecs-example\nruntime: yaml\ndescription: An example that deploys an ECS Fargate service with load balancer\n\nresources:\n # Create a VPC with automatic subnets\n main-vpc:\n type: awsx:ec2:Vpc\n properties:\n cidrBlock: \"10.0.0.0/16\"\n numberOfAvailabilityZones: 2\n\n # Create an ECS cluster\n app-cluster:\n type: aws:ecs:Cluster\n\n # Create an Application Load Balancer\n app-alb:\n type: awsx:elasticloadbalancingv2:ApplicationLoadBalancer\n properties:\n vpcId: ${main-vpc.vpcId}\n subnetIds: ${main-vpc.publicSubnetIds}\n\n # Deploy a containerized application\n app-service:\n type: awsx:ecs:FargateService\n properties:\n cluster: ${app-cluster.arn}\n taskDefinitionArgs:\n container:\n image: \"nginx:latest\"\n memory: 128\n ports:\n - containerPort: 80\n targetGroup: ${app-alb.defaultTargetGroup}\n\noutputs:\n vpcId: ${main-vpc.vpcId}\n serviceUrl: ${app-alb.loadBalancer.dnsName}\n\n```\n\nKey Features:\n\n- **General-purpose language support**: Use Python, TypeScript, Go, C#, Java, or YAML without learning new DSLs\n- **Software engineering practices**: Full IDE support, comprehensive testing frameworks, debugging capabilities\n- **Multi-cloud flexibility**: Native cloud provider SDKs with same-day feature access across [150+ providers](https://www.pulumi.com/registry/)\n- **Incremental adoption**: Migration tools and state integration for gradual transitions\n- **Open source licensing**: Apache 2.0 ensures long-term freedom and flexibility\n\nConsiderations:\n\n- **Learning curve**: Teams new to programming may prefer template-based approaches initially\n- **Ecosystem maturity**: Smaller community compared to more established tools like Terraform\n- **Tool complexity**: Advanced features may require more setup than simpler template systems\n\nOrganizations like Unity, Snowflake, and Starburst have reported significant productivity improvements (80-90% deployment time reductions) when adopting programming language-based approaches. These improvements typically occur when transitioning from manual processes or basic template systems to automated approaches with comprehensive testing, IDE integration, and code reusability. Results vary based on starting point, team expertise, infrastructure complexity, and specific use cases.\n\n> **Ready to get started?** [Experience Pulumi’s programming language approach](https://www.pulumi.com/docs/get-started/) and see how familiar languages can transform your infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.\n\n### 2\\. Terraform\n\nLicense: Business Source License (BSL) 1.1 (Not Open Source) \nBest For: Teams with existing Terraform expertise and established workflows\n\n[Terraform](https://www.pulumi.com/docs/iac/comparisons/terraform/) uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers. However, its 2023 licensing change to BSL (no longer open source) and inherent limitations with domain-specific languages create challenges for teams requiring advanced software engineering practices.\n\nKey Features:\n\n- **Extensive provider ecosystem**: Largest collection of community-maintained providers covering virtually every cloud service\n- **Established workflows**: Mature plan-and-apply process with extensive tooling and CI/CD integrations\n- **Community and resources**: Vast ecosystem of modules, extensive documentation, training materials, and community support\n- **Enterprise adoption**: Widely adopted in enterprises with established processes and expertise\n- **Module ecosystem**: Rich collection of reusable Terraform modules for common patterns\n\nWhen Terraform Works Well:\n\n- Teams with existing HCL expertise and Terraform investments\n- Infrastructure patterns that fit well within HCL’s declarative model\n- Teams comfortable with template-based approaches\n\nConsiderations for Complex Scenarios:\n\n- **Language constraints**: HCL’s domain-specific nature can require workarounds for complex logic compared to general-purpose programming languages\n- **Testing approach**: Primarily supports integration testing; teams needing comprehensive unit testing may require additional tooling\n- **IDE experience**: While improving, HCL tooling provides less comprehensive support than mature programming language ecosystems\n- **State management**: Requires manual backend configuration and locking setup for team collaboration\n\nCode Example:\n\n```hcl\ndata \"aws_availability_zones\" \"available\" {}\n\nresource \"aws_vpc\" \"main\" {\n cidr_block = \"10.0.0.0/16\"\n\n tags = {\n Name = \"main-vpc\"\n }\n}\n\nresource \"aws_subnet\" \"public\" {\n count = 2\n vpc_id = aws_vpc.main.id\n cidr_block = \"10.0.${count.index + 1}.0/24\"\n availability_zone = data.aws_availability_zones.available.names[count.index]\n\n tags = {\n Name = \"public-subnet-${count.index + 1}\"\n }\n}\n\n```\n\n### 3\\. AWS Cloud Development Kit (CDK)\n\nLicense: Apache 2.0 \nBest For: AWS-focused teams who prefer programming languages over templates\n\nAWS CDK allows you to define AWS infrastructure using familiar programming languages, synthesizing CloudFormation templates for deployment while providing higher-level abstractions. CDK addresses many limitations of traditional template-based approaches by enabling general-purpose programming languages.\n\nKey Features:\n\n- **General-purpose programming languages**: TypeScript, Python, Java, C#, JavaScript support with full IDE integration (Go available in Developer Preview)\n- **AWS-optimized constructs**: High-level components encapsulating AWS best practices\n- **Type safety**: Compile-time checking and IntelliSense support\n- **CloudFormation reliability**: Built on AWS’s proven deployment engine\n\nNotable Limitations:\n\n- **AWS-only ecosystem**: Locked into single cloud provider, limiting multi-cloud strategies\n- **CloudFormation constraints**: Inherits template size limits and deployment restrictions\n- **Vendor lock-in**: Deep AWS integration makes migration to other clouds challenging\n- **Limited cross-cloud consistency**: Teams need different tools and approaches for multi-cloud deployments\n\nCDK represents a significant improvement over CloudFormation templates but constrains organizations to AWS-only infrastructure strategies.\n\nCode Example:\n\n```typescript\nimport * as cdk from 'aws-cdk-lib';\nimport * as ec2 from 'aws-cdk-lib/aws-ec2';\nimport * as ecs from 'aws-cdk-lib/aws-ecs';\nimport { Construct } from 'constructs';\n\nexport class MyStack extends cdk.Stack {\n constructor(scope: Construct, id: string, props?: cdk.StackProps) {\n super(scope, id, props);\n\n const vpc = new ec2.Vpc(this, 'MyVpc', {\n maxAzs: 2\n });\n\n const cluster = new ecs.Cluster(this, 'MyCluster', {\n vpc: vpc\n });\n\n const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', {\n memoryLimitMiB: 512,\n cpu: 256\n });\n\n taskDefinition.addContainer('web', {\n image: ecs.ContainerImage.fromRegistry('nginx:latest'),\n portMappings: [{ containerPort: 80 }]\n });\n\n new ecs.FargateService(this, 'MyService', {\n cluster: cluster,\n taskDefinition: taskDefinition\n });\n }\n}\n\n```\n\n### 4\\. AWS CloudFormation\n\nLicense: Proprietary (AWS Service) \nBest For: AWS-only deployments requiring deep service integration\n\nAWS CloudFormation provides the foundation for infrastructure as code on AWS, offering native integration with all AWS services and deep platform-specific features.\n\nPulumi Integration: Pulumi provides [native AWS providers](https://www.pulumi.com/docs/clouds/aws/) that offer the same comprehensive AWS service coverage as CloudFormation, with the added benefit of using general-purpose programming languages. You can also [import existing CloudFormation stacks](https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/import/) into Pulumi for gradual migration or hybrid management approaches.\n\nKey Features:\n\n- **AWS-native**: First-party support for all AWS services\n- **JSON/YAML templates**: Declarative resource definitions\n- **Stack management**: Organized resource grouping and lifecycle management\n- **Change sets**: Preview infrastructure changes before deployment\n- **Service integration**: Deep integration with other AWS services\n\nCode Example:\n\n```yaml\nAWSTemplateFormatVersion: '2010-09-09'\nResources:\n MyVPC:\n Type: AWS::EC2::VPC\n Properties:\n CidrBlock: 10.0.0.0/16\n EnableDnsHostnames: true\n Tags:\n - Key: Name\n Value: MyVPC\n\n MySubnet:\n Type: AWS::EC2::Subnet\n Properties:\n VpcId: !Ref MyVPC\n CidrBlock: 10.0.1.0/24\n AvailabilityZone: !Select [0, !GetAZs '']\n\n```\n\n### 5\\. Azure Resource Manager (ARM)\n\nLicense: Proprietary (Microsoft Service) \nBest For: Azure-native deployments requiring comprehensive platform integration\n\nAzure Resource Manager provides the foundational infrastructure as code solution for Microsoft Azure, offering complete support for Azure services through JSON-based ARM templates. As Azure’s native IaC solution, ARM templates provide the most comprehensive coverage of Azure services and features.\n\nPulumi Integration: Pulumi’s [native Azure providers](https://www.pulumi.com/docs/clouds/azure/) offer equivalent comprehensive Azure service coverage with general-purpose programming languages. ARM templates can be [imported into Pulumi](https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/import/), and you can reference ARM deployments from Pulumi programs for hybrid scenarios.\n\nKey Features:\n\n- **Azure-native**: Complete Azure service coverage with first-party support\n- **JSON templates**: Declarative resource definitions in JSON format\n- **Resource groups**: Logical organization of related resources\n- **Deployment modes**: Complete or incremental deployment options\n- **Comprehensive integration**: Deep integration with Azure services and features\n\nCode Example:\n\n```json\n{\n \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\",\n \"contentVersion\": \"1.0.0.0\",\n \"resources\": [\n {\n \"type\": \"Microsoft.Storage/storageAccounts\",\n \"apiVersion\": \"2023-01-01\",\n \"name\": \"mystorageaccount\",\n \"location\": \"[resourceGroup().location]\",\n \"sku\": {\n \"name\": \"Standard_LRS\"\n },\n \"kind\": \"StorageV2\"\n }\n ]\n}\n\n```\n\n### 6\\. Azure Bicep\n\nLicense: MIT \nBest For: Azure deployments requiring improved readability and developer experience\n\nAzure Bicep is a domain-specific language (DSL) that simplifies Azure Resource Manager template authoring. Bicep files compile transparently to ARM templates, providing all the capabilities of ARM with significantly improved syntax and developer experience.\n\nKey Features:\n\n- **Simplified syntax**: Clean, readable syntax compared to JSON ARM templates\n- **ARM compilation**: Compiles to ARM templates for deployment, ensuring full compatibility\n- **Type safety**: Strong typing and IntelliSense support in development environments\n- **Modular design**: Support for modules and code reuse across projects\n- **Azure-native**: Complete Azure service coverage through ARM template compilation\n\nCode Example:\n\n```bicep\n@description('Storage Account type')\n@allowed([\n 'Standard_LRS'\n 'Standard_GRS'\n 'Standard_ZRS'\n 'Premium_LRS'\n])\nparam storageAccountType string = 'Standard_LRS'\n\n@description('Location for the storage account.')\nparam location string = resourceGroup().location\n\nresource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {\n name: 'mystorageaccount'\n location: location\n sku: {\n name: storageAccountType\n }\n kind: 'StorageV2'\n properties: {}\n}\n\n```\n\n### 7\\. Google Cloud Infrastructure Manager\n\nLicense: Proprietary (Google Service) \nBest For: Google Cloud Platform deployments using Terraform\n\nGoogle Cloud Infrastructure Manager automates the deployment and management of Google Cloud infrastructure resources using Terraform configurations, representing Google’s modern approach to infrastructure as code. Infrastructure Manager replaces Google Cloud Deployment Manager, which reached end of support on December 31, 2025.\n\nKey Features:\n\n- **Terraform-based**: Uses standard Terraform configurations declaratively\n- **Automated workflows**: Handles Terraform init, validate, and apply operations\n- **Version control integration**: Supports Git repositories and Cloud Storage\n- **Deployment tracking**: Comprehensive metadata storage and logging\n- **Multiple Terraform versions**: Flexibility in Terraform version selection\n- **Cloud Build integration**: Leverages Google Cloud Build for execution environment\n- **Migration path**: Provides upgrade path from legacy Cloud Deployment Manager\n\nCode Example:\n\n```hcl\n# main.tf - Terraform configuration for Infrastructure Manager\nresource \"google_compute_instance\" \"vm_instance\" {\n name = \"my-vm\"\n machine_type = \"e2-medium\"\n zone = \"us-central1-a\"\n\n boot_disk {\n initialize_params {\n image = \"debian-cloud/debian-11\"\n }\n }\n\n network_interface {\n network = \"default\"\n access_config {\n // Ephemeral public IP\n }\n }\n\n metadata = {\n startup-script = \"echo Hello from Infrastructure Manager!\"\n }\n}\n\noutput \"instance_ip\" {\n value = google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip\n}\n\n```\n\n### 8\\. Kubernetes YAML\n\nLicense: Apache 2.0 \nBest For: Teams managing container-native applications and cloud-native infrastructure\n\nKubernetes YAML manifests represent one of the most widely adopted forms of infrastructure as code, enabling teams to define, version, and manage containerized applications and their supporting infrastructure through declarative configuration files.\n\nKey Features:\n\n- **Declarative configuration**: Define desired state through human-readable YAML files\n- **Native Kubernetes integration**: Direct integration with Kubernetes API without additional tools\n- **GitOps compatibility**: Version control YAML files for automated deployment workflows\n- **Resource relationships**: Define dependencies and relationships between Kubernetes resources\n- **Extensive ecosystem**: Rich ecosystem of operators and custom resources extending functionality\n\nCode Example:\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: web-app\n labels:\n app: web-app\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: web-app\n template:\n metadata:\n labels:\n app: web-app\n spec:\n containers:\n - name: web-app\n image: nginx:1.21\n ports:\n - containerPort: 80\n resources:\n requests:\n memory: \"64Mi\"\n cpu: \"250m\"\n limits:\n memory: \"128Mi\"\n cpu: \"500m\"\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: web-app-service\nspec:\n selector:\n app: web-app\n ports:\n - port: 80\n targetPort: 80\n type: LoadBalancer\n\n```\n\n### 9\\. Crossplane\n\nLicense: Apache 2.0 \nBest For: Kubernetes-first organizations managing multi-cloud infrastructure\n\nCrossplane is a Cloud-Native Framework for Platform Engineering that extends Kubernetes to help organizations build custom infrastructure management platforms, allowing teams to provision and manage cloud resources using Kubernetes APIs and patterns.\n\nPulumi Integration: Pulumi offers the [Pulumi Kubernetes Operator (PKO)](https://www.pulumi.com/docs/using-pulumi/continuous-delivery/pulumi-kubernetes-operator/) that provides similar Kubernetes-native infrastructure management capabilities, plus support for YAML-based definitions. Teams can also use Pulumi programs to provision the underlying infrastructure that Crossplane manages, creating layered infrastructure management approaches.\n\nKey Features:\n\n- **Kubernetes-native**: Uses CRDs and standard Kubernetes patterns\n- **Composite resources**: Create higher-level infrastructure abstractions\n- **GitOps compatibility**: Seamless integration with GitOps workflows\n- **Multi-cloud support**: Provision resources across cloud providers\n- **Policy integration**: Leverage Kubernetes RBAC and admission controllers\n\nCode Example:\n\n```yaml\napiVersion: ec2.aws.crossplane.io/v1alpha1\nkind: VPC\nmetadata:\n name: sample-vpc\nspec:\n cidrBlock: 10.0.0.0/16\n region: us-east-1\n tags:\n Name: sample-vpc\n providerConfigRef:\n name: aws-provider-config\n\n```\n\n### 10\\. OpenTofu\n\nLicense: Mozilla Public License 2.0 \nBest For: Teams seeking an open-source Terraform alternative with community governance\n\nOpenTofu emerged as a fork of Terraform v1.5.x following HashiCorp’s license change, maintained by the Linux Foundation. It provides [full compatibility with Terraform](https://www.pulumi.com/docs/iac/concepts/vs/opentofu/) while ensuring long-term open-source availability under MPL 2.0 licensing.\n\nKey Features:\n\n- **True open source**: MPL 2.0 license with community governance via Linux Foundation ensuring long-term accessibility\n- **Terraform compatibility**: Drop-in replacement maintaining existing workflows, modules, and provider ecosystem\n- **Community-driven development**: Transparent roadmap, open contribution process, and vendor-neutral governance\n- **License certainty**: Removes concerns about future licensing restrictions for commercial use\n\nWhen OpenTofu Makes Sense:\n\n- Organizations requiring guaranteed open-source licensing for compliance or philosophical reasons\n- Teams with significant Terraform investments wanting to avoid vendor lock-in\n- Environments where community governance and transparency are priorities\n- Projects needing long-term license stability\n\nArchitectural Considerations: As a Terraform fork, OpenTofu inherits the same architectural approach, which means teams evaluating it should consider whether HCL-based infrastructure definition meets their long-term needs for testing, IDE integration, and developer productivity, or whether a programming language-based approach might better serve complex scenarios.\n\nCode Example:\n\n```hcl\nresource \"aws_instance\" \"web\" {\n ami = \"ami-0c55b159cbfafe1d0\"\n instance_type = \"t3.micro\"\n\n tags = {\n Name = \"HelloWorld\"\n }\n}\n\noutput \"instance_ip\" {\n value = aws_instance.web.public_ip\n}\n\n```\n\n### Ansible\n\nLicense: GPL v3 \nBest For: Configuration management with some infrastructure provisioning capabilities\n\nAnsible is primarily a configuration management tool, not a pure Infrastructure as Code tool. While Ansible can provision some cloud resources, its core strength lies in configuring and managing software on existing systems rather than comprehensive infrastructure provisioning.\n\nAnsible provides configuration management and limited infrastructure provisioning through its agentless architecture and simple YAML-based playbooks.\n\nPulumi Integration: Rather than competing with Ansible, Pulumi complements it perfectly. Use Pulumi for infrastructure provisioning and Ansible for configuration management. Pulumi’s Command provider can execute Ansible playbooks as part of your infrastructure deployment, and many Pulumi customers use both tools together for comprehensive infrastructure automation. [See example: Deploy WordPress to AWS using Pulumi and Ansible](https://www.pulumi.com/blog/deploy-wordpress-aws-pulumi-ansible/).\n\nKey Features:\n\n- **Agentless architecture**: No software installation required on target systems\n- **YAML playbooks**: Human-readable automation definitions\n- **Idempotent operations**: Safe to run multiple times\n- **Large module library**: Extensive built-in functionality for various systems\n- **Push-based execution**: Centralized control and execution\n\nCode Example:\n\n```yaml\n---\n- name: Provision AWS infrastructure\n hosts: localhost\n tasks:\n - name: Create VPC\n amazon.aws.ec2_vpc_net:\n name: ansible-vpc\n cidr_block: 10.0.0.0/16\n region: us-east-1\n tags:\n Environment: production\n register: vpc\n\n - name: Create subnet\n amazon.aws.ec2_vpc_subnet:\n vpc_id: \"{{ vpc.vpc.id }}\"\n cidr: 10.0.1.0/24\n region: us-east-1\n tags:\n Name: ansible-subnet\n\n```\n\n### Chef\n\nLicense: Apache 2.0 \nBest For: Complex configuration management scenarios requiring programmable logic\n\nChef is a configuration management tool, not an Infrastructure as Code tool. Chef focuses on configuring and maintaining software, services, and system settings on existing infrastructure rather than provisioning cloud resources.\n\nChef provides configuration management and system automation using Ruby-based recipes and cookbooks, offering powerful programmability for complex configuration scenarios.\n\nKey Features:\n\n- **Ruby DSL**: Full programming language for configuration logic\n- **Agent-based architecture**: Continuous compliance and drift detection\n- **Cookbook ecosystem**: Reusable configuration patterns and community recipes\n- **Test Kitchen**: Infrastructure testing and validation framework\n- **Enterprise features**: Advanced reporting and compliance capabilities\n\nCode Example:\n\n```ruby\n# cookbook/recipes/default.rb\npackage 'nginx' do\n action :install\nend\n\nservice 'nginx' do\n action [:enable, :start]\nend\n\ntemplate '/etc/nginx/sites-available/default' do\n source 'default.erb'\n owner 'root'\n group 'root'\n mode '0644'\n notifies :restart, 'service[nginx]'\nend\n\n```\n\n### Puppet\n\nLicense: Apache 2.0 \nBest For: Enterprise environments requiring strong governance and compliance\n\nPuppet is a configuration management tool, not an Infrastructure as Code tool. Puppet specializes in maintaining desired configuration state on existing systems and ensuring compliance, rather than provisioning cloud infrastructure.\n\nPuppet offers enterprise-grade configuration management with a focus on compliance, governance, and declarative system state management.\n\nKey Features:\n\n- **Declarative language**: Puppet DSL for describing desired system state\n- **Compliance reporting**: Built-in governance and audit capabilities\n- **Forge marketplace**: Community modules and enterprise content\n- **Enterprise support**: Professional services and enterprise features\n- **Continuous enforcement**: Ongoing configuration compliance monitoring\n\nCode Example:\n\n```puppet\n# manifests/webserver.pp\nclass webserver {\n package { 'nginx':\n ensure => installed,\n }\n\n service { 'nginx':\n ensure => running,\n enable => true,\n require => Package['nginx'],\n }\n\n file { '/var/www/html/index.html':\n ensure => file,\n content => '

Hello from Puppet!

',\n owner => 'www-data',\n group => 'www-data',\n mode => '0644',\n }\n}\n\n```\n\n### Salt\n\nLicense: Apache 2.0 \nBest For: Python-oriented teams requiring high-performance configuration management\n\nSalt is primarily a configuration management and remote execution tool, not a pure Infrastructure as Code tool. While Salt can manage some infrastructure components, its primary focus is on configuring systems and executing commands across large infrastructures.\n\nSalt provides fast, scalable configuration management and remote execution using Python, designed for high-performance system automation at scale.\n\nKey Features:\n\n- **Python-based**: Leverage the Python ecosystem and libraries\n- **High performance**: Fast execution across large infrastructures\n- **Event-driven automation**: Reactive automation and orchestration\n- **Pillar data system**: Secure, hierarchical data management\n- **Flexible communication**: Support for various communication patterns\n\nCode Example:\n\n```yaml\n# /srv/salt/webserver.sls\nnginx:\n pkg.installed: []\n service.running:\n - enable: True\n - require:\n - pkg: nginx\n\n/var/www/html/index.html:\n file.managed:\n - source: salt://files/index.html\n - user: www-data\n - group: www-data\n - mode: 644\n\n```\n\n## Infrastructure as Code Tools\n\n### Kubernetes - Container Orchestration Platform\n\nLicense: Apache 2.0 \nBest For: Container-native infrastructure and application management\n\nWhile primarily a [container orchestration](https://www.pulumi.com/topics/containers/) platform, Kubernetes itself serves as an infrastructure as code tool through its declarative YAML manifests and API-driven resource management.\n\nKey Features:\n\n- **Declarative configuration**: YAML-based resource definitions\n- **API-driven**: RESTful API for all resource operations\n- **Self-healing**: Automatic recovery and reconciliation\n- **Extensible**: Custom resources and controllers\n- **GitOps compatible**: Works seamlessly with Git-based workflows\n\nCode Example:\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: nginx-deployment\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx\n template:\n metadata:\n labels:\n app: nginx\n spec:\n containers:\n - name: nginx\n image: nginx:1.21\n ports:\n - containerPort: 80\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: nginx-service\nspec:\n selector:\n app: nginx\n ports:\n - port: 80\n targetPort: 80\n type: LoadBalancer\n\n```\n\n## Infrastructure as Code Security and Compliance Tools\n\nWhile the tools above focus on provisioning and managing infrastructure, a complete IaC ecosystem includes security scanning and compliance tools. These tools complement your primary IaC tool by providing security analysis, policy enforcement, and compliance checking:\n\n### Security Scanning Tools\n\nSnyk - License: Proprietary \nLeading developer security platform that includes comprehensive infrastructure as code scanning alongside container and application security. Provides real-time vulnerability detection, compliance checking, and automated remediation guidance. Integrates with popular development tools and CI/CD pipelines with extensive enterprise adoption.\n\nWiz - License: Proprietary \nComprehensive cloud security platform that includes infrastructure as code scanning capabilities. Provides vulnerability management, compliance monitoring, and security posture assessment across cloud environments. Offers integration with development workflows and supports multiple IaC formats with strong enterprise presence.\n\nCheckov - License: Apache 2.0 \nPopular open-source static analysis tool for infrastructure as code that scans cloud infrastructure configurations for security and compliance issues. Supports Terraform, CloudFormation, Kubernetes, Helm, ARM templates, and more. Integrates with CI/CD pipelines and provides over 1000+ built-in policies covering CIS benchmarks, PCI DSS, and GDPR compliance.\n\n### Linting and Validation Tools\n\nTFLint - License: MPL 2.0 \nTerraform linter focused on possible errors, best practices, and security issues in Terraform configurations. Provides pluggable rule sets for cloud providers (AWS, Azure, GCP) and helps enforce coding standards, detect deprecated syntax, and prevent common configuration errors.\n\nThese security tools integrate into CI/CD pipelines alongside your chosen IaC tool to provide comprehensive security coverage throughout the infrastructure lifecycle.\n\n### Pulumi ESC\n\nLicense: Apache 2.0 (Open Source) / Proprietary (SaaS) \nBest For: Teams needing centralized configuration and secrets management across environments and tools\n\nPulumi ESC (Environments, Secrets, and Configuration) is a comprehensive platform for managing configuration data, secrets, and environment variables across your entire infrastructure and application stack. ESC provides a single source of truth for configuration that works with any infrastructure tool, not just Pulumi.\n\nKey Features:\n\n- **Universal configuration management**: Works with any infrastructure tool, CI/CD system, or application\n- **Hierarchical environments**: Compose configuration from multiple sources with inheritance and overrides\n- **Dynamic secrets**: Integration with cloud providers for short-lived credentials and just-in-time access\n- **Policy-based access control**: Fine-grained permissions and audit logging for configuration access\n- **Multiple consumption methods**: CLI, REST API, SDK integration, and direct cloud provider integration\n- **GitOps workflows**: Version control integration with pull request-based configuration management\n\nCode Example:\n\n```yaml\n# Production environment configuration\nvalues:\n app:\n name: myapp\n version: ${fn.fromJSON(aws.ecr.getAuthorizationToken).password}\n database:\n connectionString: ${pulumi.database.connectionString}\nimports:\n - shared/common\n - aws/production\n\n```\n\n### Pulumi Insights\n\nLicense: Proprietary (SaaS) \nBest For: Organizations needing comprehensive cloud resource visibility, search, and compliance monitoring\n\nPulumi Insights provides cloud resource search, analytics, and compliance capabilities across your entire multi-cloud infrastructure, regardless of how resources were provisioned. It offers a unified view of your cloud resources with powerful search, cost analysis, and policy enforcement.\n\nKey Features:\n\n- **Universal cloud inventory**: Discover and catalog resources across AWS, Azure, Google Cloud, and Kubernetes\n- **Advanced search and analytics**: Query resources by tags, properties, relationships, and compliance status\n- **Cost optimization insights**: Resource cost analysis, trends, and optimization recommendations\n- **Compliance monitoring**: Continuous policy evaluation and drift detection across all cloud resources\n- **Resource relationships**: Understand dependencies and relationships between cloud resources\n- **Integration with any IaC tool**: Works with resources created by Pulumi, Terraform, CloudFormation, or manually\n\nUse Cases:\n\n- **Cloud governance**: Ensure compliance with organizational policies and industry standards\n- **Cost management**: Identify unused resources and optimization opportunities\n- **Security auditing**: Track resource configurations and detect security misconfigurations\n- **Multi-cloud visibility**: Single pane of glass for resources across different cloud providers\n\n## Infrastructure Automation and Management Platforms\n\nWhile the above tools focus on defining and provisioning infrastructure, several platforms provide automation, orchestration, and management capabilities that work with Infrastructure as Code tools. Important: These are not IaC tools themselves, but rather automation platforms that rely on underlying IaC tools.\n\n### IaC Automation Platforms\n\nPulumi Cloud Best For: Teams using Pulumi IaC who need enterprise-grade collaboration, security, and governance\n\nPulumi Cloud is the smartest and easiest way to automate, secure, and manage everything you run in the cloud. It serves as the managed service companion to Pulumi’s open-source infrastructure as code tool, providing enterprise capabilities that extend beyond basic IaC functionality.\n\nThe relationship between Pulumi IaC and Pulumi Cloud follows a Git/GitHub model: Pulumi IaC is like Git (fully open source and functional on its own), while Pulumi Cloud is like GitHub (a managed service that makes the open-source tool much easier to use securely at scale with teams).\n\nKey Features:\n\n- **Managed state backend**: Secure, scalable state management with transactional protocols\n- **Team collaboration**: Full audit logs, RBAC, and identity provider integration\n- **Centralized secrets management**: Pulumi ESC for configuration and secrets across environments\n- **Cloud inventory and insights**: Pulumi Insights for search, compliance, and drift detection\n- **Remote deployments**: CI/CD integrations and automated workflows\n- **Policy enforcement**: Built-in security and compliance policy as code\n- **Multi-product platform**: Integrated IaC, secrets management, and cloud insights\n\nPulumi IaC works with or without Pulumi Cloud - you can use DIY backends (S3, Azure Blob, etc.) or the managed service. However, Pulumi Cloud becomes the default experience when you install the Pulumi CLI, providing instant collaboration capabilities without the overhead of building and maintaining your own infrastructure management platform.\n\nHashiCorp Cloud Platform (HCP) - License: Proprietary (SaaS) \nBest For: Organizations standardizing on HashiCorp tools across infrastructure and security lifecycle management\n\nHashiCorp Cloud Platform (HCP) is an enterprise-grade SaaS platform that provides unified lifecycle management for infrastructure and security operations. HCP Terraform (formerly Terraform Cloud) serves as the managed service for Terraform/OpenTofu workflows, while the broader platform integrates multiple HashiCorp tools.\n\nKey Features:\n\n- **HCP Terraform management**: Workspace organization, remote execution, and state management for Terraform\n- **Infrastructure lifecycle automation**: Continuous validation, drift detection, and module lifecycle management\n- **Private VCS access**: Secure integration with private version control repositories\n- **Policy enforcement**: Sentinel policy-as-code framework for compliance and governance\n- **Integrated security services**: HCP Vault for secrets management, HCP Consul for service networking\n- **Enterprise access controls**: RBAC, SAML SSO integration, and fine-grained permissions\n- **Module and image management**: HCP Packer for automated machine/container image creation\n\nHCP focuses specifically on HashiCorp tool integration and provides a comprehensive platform for organizations that have standardized on the HashiCorp ecosystem for infrastructure and security operations.\n\nSpacelift - Spacelift is not an Infrastructure as Code tool—it’s an automation and workflow platform that relies on other IaC tools like Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Spacelift provides CI/CD pipelines, policy enforcement, and collaboration features for teams using these underlying IaC tools.\n\nEnv0 - Env0 is not an Infrastructure as Code tool—it’s an automation platform that provides workflow management, governance, and collaboration features for existing IaC tools like Terraform, OpenTofu, and Terragrunt. It adds CI/CD pipelines, cost management, and policy enforcement on top of these tools.\n\nAtlantis - An open-source tool that provides GitOps-style workflows for Terraform and OpenTofu by automatically running terraform plan and apply operations via pull request automation.\n\n### Development Environment Tools\n\nVagrant - Vagrant is not an Infrastructure as Code tool—it’s a development environment management tool that creates and configures lightweight, reproducible virtual development environments. While it can provision VMs, its focus is on local development environments rather than cloud infrastructure provisioning.\n\nDocker Compose - While not an IaC tool, Docker Compose defines multi-container applications and can be used alongside IaC tools for application deployment after infrastructure provisioning.\n\nThese platforms and tools serve important roles in the infrastructure automation ecosystem but should not be confused with Infrastructure as Code tools themselves. They enhance and orchestrate the work of actual IaC tools rather than replacing them.\n\n## The Future of Infrastructure as Code\n\nThe infrastructure as code landscape is rapidly evolving toward software engineering maturity, with several transformative trends reshaping how organizations approach infrastructure:\n\nSoftware Engineering Convergence: The most significant trend is the convergence of infrastructure and software engineering practices. Organizations are moving away from limited DSLs toward full programming languages that enable testing, debugging, refactoring, and other software engineering best practices. This shift enables infrastructure teams to leverage the same tools, skills, and methodologies that have proven successful in application development.\n\nReal-Time Cloud Integration: Native cloud provider SDK integration is becoming the standard, replacing community-maintained providers that lag behind new cloud features. Organizations expect same-day access to new cloud services without waiting weeks or months for provider updates.\n\nComprehensive Testing Paradigms: Infrastructure testing is evolving beyond basic integration tests to include unit testing, property-based testing, and continuous validation. Teams are applying test-driven development principles to infrastructure, catching issues before deployment rather than discovering them in production.\n\nInternal Developer Platform Evolution: Organizations are building sophisticated Internal Developer Platforms that provide self-service infrastructure capabilities while maintaining governance and compliance. These platforms leverage infrastructure as code tools to create standardized, reusable components that accelerate development velocity.\n\nAI-Enhanced Development: Integration of AI tools to help generate, optimize, and troubleshoot infrastructure code, with particular strength in environments that use familiar programming languages where AI assistance is most mature. Emerging technologies like Model Context Protocol (MCP) and AI prompt templates are beginning to enable more sophisticated AI-infrastructure interactions.\n\nThese trends favor tools that embrace software engineering principles from the ground up, rather than attempting to retrofit programming capabilities onto template-based or DSL-limited approaches.\n\nBring software engineering to IaC\n\nDefine infrastructure across AWS, Azure, Google Cloud, and Kubernetes in the language your team already knows, with testing, IDE support, and reusable components.\n\n[Get started](https://app.pulumi.com/signup)\n\n## Migration and Adoption Strategies\n\nOrganizations don’t need to choose between maintaining existing infrastructure and adopting modern IaC approaches. Proven migration strategies enable gradual adoption while preserving operational stability.\n\n### Incremental Adoption Approaches\n\nTeam-by-Team Migration: Start with new projects or specific teams, allowing gradual skill development and process refinement. Teams can maintain existing infrastructure while building new capabilities with modern tools.\n\nProject-by-Project Transition: Migrate individual applications or services incrementally, enabling teams to learn and optimize approaches before expanding scope.\n\nHybrid Operations: Use state integration and import tools to reference existing infrastructure while building new components with modern IaC tools.\n\n### Proven Migration Timelines\n\nReal-world migrations demonstrate that adoption can be remarkably fast with proper tooling:\n\n- **Atlassian Bitbucket**: Complete Terraform to Pulumi migration in 2 days using automated conversion tools. This rapid migration was enabled by existing Python expertise on the team, well-structured Terraform code, and straightforward infrastructure patterns that converted cleanly.\n- **Enterprise migrations**: Typical team migrations complete in weeks, not months, depending on infrastructure complexity and team preparation\n- **Learning curve**: Teams with programming experience adapt to language-based IaC approaches within days, while those new to programming may require additional training time\n\n### Migration Tools and Resources\n\nAutomated Conversion: Tools like tf2pulumi and pulumi convert automatically translate existing infrastructure definitions, preserving logic and structure while upgrading to modern approaches.\n\nState Integration: Import existing cloud resources and reference Terraform state during transition periods, enabling zero-downtime migrations.\n\nTraining and Support: Comprehensive documentation, tutorials, and community resources accelerate team onboarding and reduce migration risks.\n\n### Best Practices for Successful Adoption\n\n1. **Start with pilot projects** to build confidence and establish patterns\n2. **Leverage automated migration tools** to reduce manual conversion effort\n3. **Maintain state integration** during transition periods for operational continuity\n4. **Invest in team training** to maximize productivity gains from modern approaches\n5. **Establish testing practices** early to realize reliability and quality benefits\n\nThe key insight: migration to modern IaC approaches is a technical upgrade, not a complete rebuild. Organizations can preserve existing investments while gaining access to superior tooling and practices.\n\n## Frequently Asked Questions\n\n### Which IaC tool should I choose for AWS?\n\nFor teams wanting programming languages: Pulumi IaC and AWS CDK both offer excellent developer experiences with general-purpose programming languages. Pulumi provides multi-cloud flexibility, while CDK offers deep AWS-native integration.\n\nFor AWS-only deployments: CloudFormation provides the deepest native AWS service support and direct integration with AWS services.\n\nFor Terraform ecosystem users: OpenTofu provides open-source licensing with Terraform compatibility, while Terraform offers extensive community resources and established workflows.\n\n### Is Terraform still worth learning in 2026?\n\nTerraform remains a valuable skill and viable choice for many scenarios, though teams should consider their specific needs and long-term goals:\n\nWhen Terraform Makes Sense:\n\n- Teams building on existing Terraform infrastructure and expertise\n- Organizations with successful Terraform workflows and established processes\n- Projects that benefit from Terraform’s extensive module ecosystem\n- Teams comfortable with HCL and template-based approaches\n\nWhen to Consider Alternatives:\n\n- Teams wanting comprehensive testing capabilities (unit, property, integration testing)\n- Organizations requiring full IDE support with debugging and refactoring\n- Projects needing complex programmatic logic or extensive code reuse\n- Teams with strong programming backgrounds who prefer familiar languages\n\nKey Considerations:\n\n- **Licensing**: Terraform’s Business Source License may create restrictions for some commercial scenarios\n- **Ecosystem**: Terraform has the largest provider ecosystem and community resources\n- **Learning investment**: Consider whether learning HCL aligns with your team’s skill development goals\n- **Migration options**: Tools exist for migrating between different IaC platforms when needs change\n\nThe choice often depends on team background, infrastructure complexity, and development workflow preferences rather than one approach being universally superior.\n\n### How do I get started with infrastructure as code?\n\nChoose Based on Your Team Profile:\n\n1. **Programming-oriented teams**: Consider Pulumi IaC for familiar languages with full IDE support, testing frameworks, and multi-cloud flexibility\n2. **Template-oriented teams**: OpenTofu or Terraform offer extensive community resources, established workflows, and broad ecosystem support\n3. **Cloud-specific teams**: Native tools (AWS CDK/CloudFormation, Azure ARM/Bicep, Google Cloud Infrastructure Manager) provide deep platform integration\n4. **Kubernetes-focused teams**: Consider Crossplane or Pulumi Kubernetes Operator for container-native approaches\n\nGetting Started Steps:\n\n1. **Start small**: Begin with simple projects like deploying a single application or basic infrastructure\n2. **Use examples**: Leverage existing templates, tutorials, and community examples to accelerate learning\n3. **Plan for growth**: Consider how your tool choice will scale with team size and infrastructure complexity\n4. **Experiment**: Most tools offer free tiers or trials - try multiple approaches with simple projects to find what fits your team best\n\n### What’s the difference between configuration management and infrastructure provisioning?\n\n- Infrastructure provisioning (Pulumi IaC, Terraform, CloudFormation) creates and manages cloud resources like VMs, networks, and databases\n- Configuration management (Ansible, Chef, Puppet) configures and maintains software on existing systems\n- Many modern tools do both, with Pulumi IaC and Ansible offering comprehensive capabilities across both domains\n\n### Can I use multiple IaC tools together?\n\nAbsolutely! Many organizations use complementary tools for different aspects of infrastructure management:\n\nPulumi + Configuration Management:\n\n- Pulumi + Ansible: Infrastructure provisioning + server configuration ([example](https://www.pulumi.com/blog/deploy-wordpress-aws-pulumi-ansible/))\n- Pulumi + Chef/Puppet: [Cloud resources](https://www.pulumi.com/docs/get-started/) + complex configuration management\n\nPulumi + Native Cloud Tools:\n\n- Reference existing CloudFormation/ARM deployments from Pulumi programs\n- Import CloudFormation/ARM resources into Pulumi for gradual migration\n- Use Pulumi alongside CDK for different parts of AWS infrastructure\n\nPulumi + Kubernetes:\n\n- [Pulumi Kubernetes Operator (PKO)](https://www.pulumi.com/docs/using-pulumi/continuous-delivery/pulumi-kubernetes-operator/) for GitOps workflows\n- Pulumi + Crossplane for layered infrastructure management\n- Pulumi + security scanners like Checkov or Terrascan for compliance\n\nTerraform + Pulumi Coexistence:\n\n- Use Terraform for base infrastructure and Pulumi for Internal Developer Platforms (IDPs)\n- Reference existing Terraform state from Pulumi programs during gradual migration\n- Manage different infrastructure layers with different tools based on team expertise\n\nPulumi IaC is designed for heterogeneous environments where multiple tools may be in use. For example, you can manage existing Terraform or CloudFormation resources with Pulumi, either using both tools in tandem or for temporary management while migrating to native Pulumi IaC code. Other Pulumi tools, like Pulumi IDP, also enable you to manage IaC self-service workflows like other tools on this list. See what’s possible when [migrating to Pulumi](https://www.pulumi.com/docs/iac/adopting-pulumi/migrating-to-pulumi/).\n\n### Which tool has the best learning resources?\n\n- Pulumi: Excellent documentation with examples in multiple languages, comprehensive tutorials\n- Terraform/OpenTofu: Extensive community content, many courses and books available\n- AWS CDK: Outstanding official documentation with workshops and examples\n- Kubernetes: Vast ecosystem but steeper learning curve\n\n### How important is open-source licensing for IaC tools?\n\nVery important for long-term strategy:\n\n- Apache 2.0 (Pulumi, CDK) offers maximum flexibility\n- MPL 2.0 (OpenTofu) ensures open-source availability\n- BSL (Terraform) restricts commercial competitors\n- Proprietary (CloudFormation, ARM) ties you to specific vendors\n\nChoose open-source tools like Pulumi or OpenTofu to avoid vendor lock-in.\n\n### What about security and compliance?\n\nAll major IaC tools support security best practices:\n\n- Built-in policy engines: Pulumi CrossGuard, AWS Config, Azure Policy\n- Third-party scanners: Checkov, KICS, Terrascan work with all tools\n- Compliance frameworks: Most tools support SOC 2, PCI DSS, CIS benchmarks\n- Secret management: Integration with Vault, AWS Secrets Manager, Azure Key Vault\n\nPulumi offers the most comprehensive built-in security features with CrossGuard policy as code.\n\n### Can I migrate from one IaC tool to another?\n\nYes, and many organizations are successfully migrating to overcome limitations in their current tools. Migration tools and proven approaches exist:\n\nProven Migration Success Stories:\n\n- **Atlassian Bitbucket**: Completed migration from Terraform to Pulumi’s Python-based IaC in just 2 days using migration tools\n- **Starburst**: Achieved 112x faster deployments after incrementally migrating from Terraform\n- **Multiple organizations**: Report 80-90% deployment time reductions after moving to programming language-based approaches\n\nAvailable Migration Tools:\n\n- **Pulumi**: Offers [`pulumi convert`](https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/migrating-to-pulumi/#conversion) for importing from Terraform, ARM, and CloudFormation with state integration\n- **Terraformer**: Can import existing cloud resources into Terraform/OpenTofu\n- **CDK Migrate**: Helps move from CloudFormation to CDK\n- **Manual migration**: Always possible by recreating resources in the new tool\n\nMigration Strategies:\n\n- **Incremental adoption**: Migrate team-by-team or project-by-project without disruption\n- **State integration**: Reference existing infrastructure during transition periods\n- **Zero downtime**: Tools like Pulumi enable seamless migration without service interruption\n\nThe key is choosing tools that provide comprehensive migration support and incremental adoption paths rather than requiring “rip and replace” approaches.\n\n## Conclusion: The Evolution of Infrastructure as Code\n\nThe infrastructure as code landscape in 2026 reflects a maturing field where different approaches serve different organizational needs and team preferences. The evolution from manual processes to automated infrastructure has branched into multiple viable paths, each with distinct advantages.\n\nThe Spectrum of Approaches:\n\nTemplate-based tools like Terraform and OpenTofu continue to serve teams effectively, particularly those comfortable with declarative configuration and established HCL workflows. Cloud-native solutions provide deep platform integration for single-cloud strategies. Programming language-based approaches offer familiar development experiences for teams seeking comprehensive testing, IDE integration, and code reusability.\n\nEvidence of Success Across Approaches:\n\nOrganizations achieve significant improvements regardless of their chosen path—the key is selecting tools that align with team expertise and infrastructure requirements. Understanding [what DevOps is](https://www.pulumi.com/what-is/what-is-devops/) and [platform engineering concepts](https://www.pulumi.com/what-is/what-is-platform-engineering/) helps inform these decisions. Success stories span the entire ecosystem, from Terraform’s widespread enterprise adoption to programming language approaches enabling dramatic productivity gains at companies like Unity, Snowflake, and Starburst.\n\nChoosing Your Path:\n\nThe most successful organizations focus on key decision criteria:\n\n- **Team background**: Match tools to existing skills and preferred development approaches\n- **Infrastructure complexity**: Consider testing, abstraction, and maintainability needs\n- **Organizational constraints**: Factor in licensing, governance, and compliance requirements\n- **Growth trajectory**: Plan for how needs may evolve with scale and team expansion\n- **Integration requirements**: Ensure compatibility with existing workflows and toolchains\n\nThe Future of Infrastructure:\n\nThe industry continues evolving toward treating infrastructure as software, but this transformation takes many forms. Organizations exploring [serverless architectures](https://www.pulumi.com/serverless/) and container strategies particularly benefit from programmable infrastructure approaches. Whether through enhanced DSLs, visual design tools, programming languages, or hybrid approaches, the goal remains consistent: enabling teams to manage infrastructure with the same reliability, collaboration, and velocity they expect from modern software development.\n\nFor teams ready to embrace programming language-based infrastructure as code, [get started with Pulumi for free](https://www.pulumi.com/docs/install/) to experience how familiar languages and software engineering practices can transform infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support. Want to see where infrastructure is headed next? [Explore Pulumi Neo](https://www.pulumi.com/product/neo/), the AI agent that proposes changes, runs previews, and opens PRs alongside your team.","publishedAt":"2026-07-05T00:00:00.000Z","fetchedAt":"2026-07-16T21:20:02.353Z","url":"https://www.pulumi.com/blog/infrastructure-as-code-tools/","media":[{"type":"image","url":"https://www.pulumi.com/images/generated/blog/infrastructure-as-code-tools/index.png","r2Key":"releases/d5455ea11e6772d1c1ed5a2ea9633b1b572554543345fbf822726de982acee11.png","r2Url":"https://media.releases.sh/releases/d5455ea11e6772d1c1ed5a2ea9633b1b572554543345fbf822726de982acee11.png"}],"coverageCount":0},{"id":"rel_4jEIZIyc_QcKbYquNX7nV","version":null,"type":"feature","title":"How to Test Infrastructure as Code","summary":"![](https://www.pulumi.com/blog/how-to-test-infrastructure-as-code/meta.png)\n\nIaC testing means validating your infrastructure code the same way you t...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/how-to-test-infrastructure-as-code/meta.png)\n\nIaC testing means validating your infrastructure code the same way you test application software—unit tests with mocked cloud providers that run in milliseconds, integration tests that deploy and inspect real resources, and policy checks that enforce compliance rules on every preview and deploy. Together, these layers catch misconfigurations before they reach production.\n\nUntested infrastructure code is a liability. A missing tag in a security group rule, an S3 bucket with public read access, a misconfigured IAM policy—any of these can slip through code review and land in production. Infrastructure bugs are often harder to debug than application bugs, because the feedback loop is slow (deploy, observe, destroy) and the blast radius is large (an outage, a security incident, a surprise AWS bill).\n\nThe good news: Pulumi is built on general-purpose programming languages, which means you can test infrastructure code with the exact same tools and frameworks you already use to test application code. No new language to learn. No separate toolchain. Just pytest, Mocha, or `go test`—pointing at your infrastructure program.\n\nThis guide walks through all three testing layers with complete, runnable examples.\n\n## Why should you test infrastructure as code?\n\nThe case for testing application code is well-established. The case for testing IaC is just as strong—arguably stronger, because the consequences of an undetected bug are more severe.\n\n**Catch misconfigurations before they deploy.** A unit test that checks whether a security group allows SSH from 0.0.0.0/0 will catch that misconfiguration in milliseconds, before any cloud API call is made. The same test in CI catches it before the code is merged.\n\n**Prevent drift and outages.** Integration tests that deploy to a staging environment and validate runtime behavior—does the HTTP endpoint return 200? does the database accept connections?—give you confidence that an infrastructure change doesn’t silently break a dependent service.\n\n**Refactor safely.** Well-tested infrastructure code can be restructured, modularized, and upgraded without fear. When all your properties, tags, and security rules are asserted in tests, you know immediately if a refactor breaks a constraint.\n\n**Enforce security and compliance automatically.** Policy as code lets you encode your organization’s security rules as executable tests. Mandatory policies block non-compliant deployments entirely; advisory policies surface warnings for human review. These rules run on every `pulumi preview` and `pulumi up`—not just at audit time.\n\n**Ship infrastructure at software speed.** Teams that test IaC ship changes faster, with less fear. The CI pipeline becomes a confidence engine rather than a deployment gate.\n\nThe annual [DORA State of DevOps research](https://cloud.google.com/devops/state-of-devops) is consistently associated with a pattern among elite-performing engineering teams—those that deploy frequently and recover quickly from failures: comprehensive automated testing across the stack. Infrastructure is no longer exempt from that standard.\n\n## What types of IaC tests are there?\n\nIaC testing mirrors the classic software test pyramid: a wide base of fast, cheap unit tests, a smaller layer of integration tests against real infrastructure, and policy checks that enforce rules throughout.\n\nLayer\n\nWhat it tests\n\nSpeed\n\nCost\n\nCloud credentials?\n\n**Unit tests**\n\nResource properties, tags, security rules, naming conventions\n\nMilliseconds\n\nFree\n\nNo\n\n**Integration tests**\n\nFull stack lifecycle, runtime behavior, cross-resource dependencies\n\nMinutes\n\nReal cloud spend\n\nYes\n\n**Policy as code**\n\nCompliance rules, security baselines, organizational standards\n\nMilliseconds\n\nFree\n\nNo (runs at preview time)\n\n```\ngraph TD\nA[\"🔒 Policy as Code
Compliance & guardrails
Runs at preview time
Milliseconds · Free\"] --> B\nB[\"🧪 Integration Tests
Real cloud deployments
Full lifecycle validation
Minutes · Cloud spend\"] --> C\nC[\"⚡ Unit Tests
Mocked providers
Property assertions
Milliseconds · Free\"]\nstyle A fill:#8A3FFC,color:#fff,stroke:#6B2FD4\nstyle B fill:#0EA5E9,color:#fff,stroke:#0284C7\nstyle C fill:#10B981,color:#fff,stroke:#059669\n```\n\nStart with unit tests—they’re free, fast, and catch the most common mistakes. Add integration tests for critical paths (the deployment pipeline, data infrastructure, security-sensitive resources). Layer in policy as code for compliance requirements that must never regress.\n\n## How do you write unit tests for Pulumi?\n\nPulumi unit tests replace the communication channel between the Pulumi program and the cloud provider with **mocks**. When the program registers a resource (e.g., `aws.ec2.SecurityGroup(...)`), the mock intercepts the call, returns dummy state, and never makes a real cloud API call. Tests run in the same process, in the same language, using the same test runner you already use.\n\n### Setting up mocks\n\n**The import-order rule:** You must set up mocks *before* importing your Pulumi program. If you import the program first, the Pulumi runtime initializes without mocks and will attempt real cloud calls.\n\n```python\n# test_infra.py\nimport unittest\nimport pulumi\n\nclass MyMocks(pulumi.runtime.Mocks):\n def new_resource(self, args: pulumi.runtime.MockResourceArgs):\n # Return [id, state]. State keys must be camelCase.\n return [args.name + \"_id\", args.inputs]\n\n def call(self, args: pulumi.runtime.MockCallArgs):\n return {}\n\n# Set mocks BEFORE importing the program\npulumi.runtime.set_mocks(MyMocks())\nimport infra # import program AFTER setting mocks\n\nclass TestInfra(unittest.TestCase):\n\n @pulumi.runtime.test\n def test_no_public_ssh(self):\n \"\"\"Security group must not expose SSH to the public internet.\"\"\"\n def check_security_group(args):\n ingress_rules = args[0]\n for rule in (ingress_rules or []):\n for cidr in (rule.get(\"cidrBlocks\") or []):\n self.assertNotEqual(\n cidr, \"0.0.0.0/0\",\n \"Security group must not expose port 22 to the internet.\"\n )\n return pulumi.Output.all(infra.group.ingress).apply(check_security_group)\n\n @pulumi.runtime.test\n def test_server_has_tags(self):\n \"\"\"EC2 instance must have required tags.\"\"\"\n def check_tags(args):\n tags = args[0]\n self.assertIn(\"Environment\", tags, \"Missing 'Environment' tag\")\n self.assertIn(\"Name\", tags, \"Missing 'Name' tag\")\n return pulumi.Output.all(infra.server.tags).apply(check_tags)\n\nif __name__ == \"__main__\":\n unittest.main()\n\n```\n\nRun with: `python -m unittest discover -v`\n\n```typescript\n// infra.test.ts\nimport * as pulumi from \"@pulumi/pulumi\";\nimport { expect } from \"chai\";\n\n// Set mocks BEFORE dynamic import of the program\npulumi.runtime.setMocks(\n {\n newResource: (args: pulumi.runtime.MockResourceArgs): { id: string; state: any } => {\n // State keys must be camelCase\n return { id: `${args.name}-id`, state: args.inputs };\n },\n call: (args: pulumi.runtime.MockCallArgs) => ({ ...args.inputs }),\n },\n \"my-project\",\n \"test\",\n false // preview = false\n);\n\ndescribe(\"Infrastructure\", function () {\n let infra: typeof import(\"./index\");\n\n before(async function () {\n // Dynamic import AFTER setting mocks\n infra = await import(\"./index\");\n });\n\n it(\"must not expose SSH to the internet\", function (done) {\n pulumi.all([infra.group.ingress]).apply(([ingress]) => {\n for (const rule of ingress ?? []) {\n for (const cidr of rule.cidrBlocks ?? []) {\n expect(cidr).to.not.equal(\n \"0.0.0.0/0\",\n \"Security group must not expose port 22 to the internet\"\n );\n }\n }\n done();\n });\n });\n\n it(\"must have required tags\", function (done) {\n pulumi.all([infra.server.tags]).apply(([tags]) => {\n expect(tags).to.include.keys(\"Environment\", \"Name\");\n done();\n });\n });\n});\n\n```\n\nRun with: `mocha -r ts-node/register infra.test.ts`\n\n```go\n// infra_test.go\npackage infra_test\n\nimport (\n \"testing\"\n\n \"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2\"\n \"github.com/pulumi/pulumi/sdk/v3/go/pulumi\"\n \"github.com/stretchr/testify/assert\"\n)\n\n// MockResourceMonitor implements pulumi.ResourceMonitor for unit tests.\nfunc TestNoPublicSSH(t *testing.T) {\n err := pulumi.RunErr(func(ctx *pulumi.Context) error {\n infra, err := NewInfra(ctx)\n assert.NoError(t, err)\n\n infra.Group.Ingress.ApplyT(func(rules []ec2.SecurityGroupIngress) error {\n for _, rule := range rules {\n for _, cidr := range rule.CidrBlocks {\n assert.NotEqual(t, \"0.0.0.0/0\", cidr,\n \"Security group must not expose port 22 to the internet\")\n }\n }\n return nil\n })\n return nil\n }, pulumi.WithMocks(\"my-project\", \"test\", mocks{}))\n assert.NoError(t, err)\n}\n\ntype mocks struct{}\n\nfunc (mocks) NewResource(args pulumi.MockResourceArgs) (string, map[string]interface{}, error) {\n return args.Name + \"_id\", args.Inputs, nil\n}\nfunc (mocks) Call(args pulumi.MockCallArgs) (map[string]interface{}, error) {\n return args.Args, nil\n}\n\n```\n\nRun with: `go test ./... -v`\n\n```csharp\n// InfraTests.cs\nusing System.Collections.Generic;\nusing System.Linq;\nusing System.Threading.Tasks;\nusing Pulumi;\nusing Pulumi.Testing;\nusing Xunit;\n\npublic class InfraTests\n{\n [Fact]\n public async Task NoPublicSSH()\n {\n var resources = await Testing.RunAsync<MyStack>();\n\n var sg = resources.OfType<Pulumi.Aws.Ec2.SecurityGroup>().First();\n var ingress = await sg.Ingress.GetValueAsync();\n\n foreach (var rule in ingress)\n {\n foreach (var cidr in rule.CidrBlocks)\n {\n Assert.NotEqual(\"0.0.0.0/0\", cidr);\n }\n }\n }\n\n [Fact]\n public async Task ServerHasRequiredTags()\n {\n var resources = await Testing.RunAsync<MyStack>();\n\n var server = resources.OfType<Pulumi.Aws.Ec2.Instance>().First();\n var tags = await server.Tags.GetValueAsync();\n\n Assert.True(tags.ContainsKey(\"Environment\"), \"Missing 'Environment' tag\");\n Assert.True(tags.ContainsKey(\"Name\"), \"Missing 'Name' tag\");\n }\n}\n\n```\n\nRun with: `dotnet test`\n\n```java\n// InfraTest.java\npackage myproject;\n\nimport com.pulumi.aws.ec2.Instance;\nimport com.pulumi.aws.ec2.SecurityGroup;\nimport com.pulumi.test.Mocks;\nimport com.pulumi.test.Mocks.CallArgs;\nimport com.pulumi.test.Mocks.ResourceArgs;\nimport com.pulumi.test.Mocks.ResourceResult;\nimport com.pulumi.test.PulumiTest;\nimport com.pulumi.test.TestOptions;\nimport org.junit.jupiter.api.AfterEach;\nimport org.junit.jupiter.api.Test;\nimport java.util.HashMap;\nimport java.util.Map;\nimport java.util.Optional;\nimport java.util.concurrent.CompletableFuture;\nimport static org.junit.jupiter.api.Assertions.*;\n\nclass InfraTest {\n\n // Implement Mocks to intercept resource creation. State keys must be camelCase.\n static class MyMocks implements Mocks {\n @Override\n public CompletableFuture<ResourceResult> newResourceAsync(ResourceArgs args) {\n var state = new HashMap<>(args.inputs);\n return CompletableFuture.completedFuture(\n ResourceResult.of(Optional.of(args.name + \"_id\"), state));\n }\n\n @Override\n public CompletableFuture<Map<String, Object>> callAsync(CallArgs args) {\n return CompletableFuture.completedFuture(Map.of());\n }\n }\n\n // PulumiTest.cleanup() must run after every test to reset the runtime state.\n @AfterEach\n void cleanup() {\n PulumiTest.cleanup();\n }\n\n @Test\n void serverHasRequiredTags() {\n var result = PulumiTest\n .withMocks(new MyMocks())\n .withOptions(TestOptions.builder()\n .projectName(\"project\").stackName(\"stack\").preview(false)\n .build())\n .runTest(ctx -> new Infra());\n\n var instance = result.resources().stream()\n .filter(r -> r instanceof Instance)\n .map(r -> (Instance) r)\n .findFirst()\n .orElseThrow(() -> new AssertionError(\"EC2 instance not found\"));\n\n var tags = PulumiTest.extractValue(instance.tags())\n .orElseThrow(() -> new AssertionError(\"Tags must not be null\"));\n assertTrue(tags.containsKey(\"Environment\"), \"Missing 'Environment' tag\");\n assertTrue(tags.containsKey(\"Name\"), \"Missing 'Name' tag\");\n }\n\n @Test\n void noPublicSshExposed() {\n var result = PulumiTest\n .withMocks(new MyMocks())\n .withOptions(TestOptions.builder()\n .projectName(\"project\").stackName(\"stack\").preview(false)\n .build())\n .runTest(ctx -> new Infra());\n\n var group = result.resources().stream()\n .filter(r -> r instanceof SecurityGroup)\n .map(r -> (SecurityGroup) r)\n .findFirst()\n .orElseThrow(() -> new AssertionError(\"Security group not found\"));\n\n var rules = PulumiTest.extractValue(group.ingress());\n for (var rule : rules) {\n for (var cidr : rule.cidrBlocks()) {\n assertNotEquals(\"0.0.0.0/0\", cidr,\n \"Security group must not expose SSH to the internet\");\n }\n }\n }\n}\n\n```\n\nRun with: `mvn test` (JUnit 5)\n\n### The program under test\n\nBoth examples above test this program:\n\n```python\n# infra.py\nimport pulumi\nfrom pulumi_aws import ec2\n\ngroup = ec2.SecurityGroup(\"web-secgrp\",\n ingress=[{\n \"protocol\": \"tcp\",\n \"from_port\": 80,\n \"to_port\": 80,\n \"cidrBlocks\": [\"0.0.0.0/0\"],\n }],\n)\n\nserver = ec2.Instance(\"web-server\",\n instance_type=\"t2.micro\",\n ami=\"ami-0b0ea68c435eb488d\",\n vpc_security_group_ids=[group.id],\n tags={\"Name\": \"web-server\", \"Environment\": \"dev\"},\n)\n\n```\n\n```typescript\n// index.ts\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as aws from \"@pulumi/aws\";\n\nexport const group = new aws.ec2.SecurityGroup(\"web-secgrp\", {\n ingress: [{\n protocol: \"tcp\",\n fromPort: 80,\n toPort: 80,\n cidrBlocks: [\"0.0.0.0/0\"],\n }],\n});\n\nexport const server = new aws.ec2.Instance(\"web-server\", {\n instanceType: \"t2.micro\",\n ami: \"ami-0b0ea68c435eb488d\",\n vpcSecurityGroupIds: [group.id],\n tags: { Name: \"web-server\", Environment: \"dev\" },\n});\n\n```\n\n```go\n// main.go\npackage infra_test\n\nimport (\n \"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2\"\n \"github.com/pulumi/pulumi/sdk/v3/go/pulumi\"\n)\n\ntype Infra struct {\n Group *ec2.SecurityGroup\n Server *ec2.Instance\n}\n\nfunc NewInfra(ctx *pulumi.Context) (*Infra, error) {\n group, err := ec2.NewSecurityGroup(ctx, \"web-secgrp\", &ec2.SecurityGroupArgs{\n Ingress: ec2.SecurityGroupIngressArray{\n ec2.SecurityGroupIngressArgs{\n Protocol: pulumi.String(\"tcp\"),\n FromPort: pulumi.Int(80),\n ToPort: pulumi.Int(80),\n CidrBlocks: pulumi.StringArray{pulumi.String(\"0.0.0.0/0\")},\n },\n },\n })\n if err != nil {\n return nil, err\n }\n\n server, err := ec2.NewInstance(ctx, \"web-server\", &ec2.InstanceArgs{\n InstanceType: pulumi.String(\"t2.micro\"),\n Ami: pulumi.String(\"ami-0b0ea68c435eb488d\"),\n VpcSecurityGroupIds: pulumi.StringArray{group.ID()},\n Tags: pulumi.StringMap{\n \"Name\": pulumi.String(\"web-server\"),\n \"Environment\": pulumi.String(\"dev\"),\n },\n })\n if err != nil {\n return nil, err\n }\n\n return &Infra{Group: group, Server: server}, nil\n}\n\n```\n\n```csharp\n// MyStack.cs\nusing Pulumi;\nusing Pulumi.Aws.Ec2;\nusing Pulumi.Aws.Ec2.Inputs;\n\npublic class MyStack : Stack\n{\n public MyStack()\n {\n var group = new SecurityGroup(\"web-secgrp\", new SecurityGroupArgs\n {\n Ingress = new[]\n {\n new SecurityGroupIngressArgs\n {\n Protocol = \"tcp\", FromPort = 80, ToPort = 80,\n CidrBlocks = new[] { \"0.0.0.0/0\" },\n },\n },\n });\n\n var server = new Instance(\"web-server\", new InstanceArgs\n {\n InstanceType = \"t2.micro\",\n Ami = \"ami-0b0ea68c435eb488d\",\n VpcSecurityGroupIds = new[] { group.Id },\n Tags = new InputMap<string>\n {\n { \"Name\", \"web-server\" },\n { \"Environment\", \"dev\" },\n },\n });\n }\n}\n\n```\n\n```java\n// Infra.java\npackage myproject;\n\nimport com.pulumi.Context;\nimport com.pulumi.Pulumi;\nimport com.pulumi.aws.ec2.SecurityGroup;\nimport com.pulumi.aws.ec2.SecurityGroupArgs;\nimport com.pulumi.aws.ec2.Instance;\nimport com.pulumi.aws.ec2.InstanceArgs;\nimport com.pulumi.aws.ec2.inputs.SecurityGroupIngressArgs;\nimport java.util.List;\nimport java.util.Map;\n\npublic class Infra {\n public final SecurityGroup group;\n public final Instance server;\n\n public Infra() {\n this.group = new SecurityGroup(\"web-secgrp\",\n SecurityGroupArgs.builder()\n .ingress(SecurityGroupIngressArgs.builder()\n .protocol(\"tcp\")\n .fromPort(80)\n .toPort(80)\n .cidrBlocks(\"0.0.0.0/0\")\n .build())\n .build());\n\n this.server = new Instance(\"web-server\",\n InstanceArgs.builder()\n .instanceType(\"t2.micro\")\n .ami(\"ami-0b0ea68c435eb488d\")\n .vpcSecurityGroupIds(group.id().applyValue(List::of))\n .tags(Map.of(\"Name\", \"web-server\", \"Environment\", \"dev\"))\n .build());\n }\n}\n\n```\n\n> **Key detail:** State property keys in the mock’s `new_resource`/`newResource` return value must be **camelCase** (`cidrBlocks`, not `cidr_blocks`), regardless of the language you’re writing in. This is how Pulumi serializes properties internally.\n\n## How do you run integration tests against real cloud resources?\n\nUnit tests tell you whether your resource definitions are correct. Integration tests tell you whether your infrastructure actually works. Integration tests deploy real cloud resources, run assertions against them, and then destroy everything—giving you end-to-end confidence at the cost of actual cloud spend and time.\n\n### Using the Automation API\n\nThe [Pulumi Automation API](https://www.pulumi.com/docs/iac/concepts/automation-api/) lets you drive `pulumi up`, `pulumi destroy`, and every other Pulumi CLI operation programmatically, from within a test. You define the stack inline (using a function that runs your Pulumi program) or point it at an existing project directory.\n\n```python\n# test_integration.py\nimport pytest\nimport pulumi\nimport pulumi_aws as aws\nfrom pulumi import automation as auto\n\ndef create_bucket_program():\n \"\"\"The Pulumi program to deploy during the test.\"\"\"\n bucket = aws.s3.Bucket(\"test-bucket\",\n tags={\"Environment\": \"test\", \"ManagedBy\": \"pulumi\"},\n )\n pulumi.export(\"bucket_name\", bucket.id)\n pulumi.export(\"bucket_arn\", bucket.arn)\n\n@pytest.fixture(scope=\"module\")\ndef deployed_stack():\n \"\"\"Deploy the stack for the test module and destroy it when done.\"\"\"\n stack = auto.create_or_select_stack(\n stack_name=\"integration-test\",\n project_name=\"bucket-test\",\n program=create_bucket_program,\n )\n stack.set_config(\"aws:region\", auto.ConfigValue(value=\"us-west-2\"))\n\n # Install provider plugins\n stack.workspace.install_plugin(\"aws\", \"v7.34.0\")\n\n # Deploy\n up_result = stack.up(on_output=print)\n\n yield up_result.outputs\n\n # Teardown: destroy everything after the test module completes\n stack.destroy(on_output=print)\n stack.workspace.remove_stack(\"integration-test\")\n\ndef test_bucket_was_created(deployed_stack):\n \"\"\"The S3 bucket should have been created with the expected name prefix.\"\"\"\n bucket_name = deployed_stack[\"bucket_name\"].value\n assert bucket_name.startswith(\"test-bucket\"), f\"Unexpected bucket name: {bucket_name}\"\n\ndef test_bucket_has_tags(deployed_stack):\n \"\"\"Verify the bucket was created with required tags (via AWS SDK).\"\"\"\n import boto3\n s3 = boto3.client(\"s3\", region_name=\"us-west-2\")\n bucket_name = deployed_stack[\"bucket_name\"].value\n tagging = s3.get_bucket_tagging(Bucket=bucket_name)\n tag_map = {t[\"Key\"]: t[\"Value\"] for t in tagging[\"TagSet\"]}\n assert tag_map.get(\"Environment\") == \"test\"\n assert tag_map.get(\"ManagedBy\") == \"pulumi\"\n\n```\n\nRun with: `pytest test_integration.py -v`\n\n```typescript\n// integration.test.ts\nimport { LocalWorkspace, ConfigValue, UpResult } from \"@pulumi/pulumi/automation\";\nimport * as aws from \"@pulumi/aws\";\nimport * as pulumi from \"@pulumi/pulumi\";\nimport { expect } from \"chai\";\n\ndescribe(\"S3 Bucket Integration\", function () {\n this.timeout(300_000); // 5 min — real deploys take time\n\n let outputs: UpResult[\"outputs\"];\n let stackName = \"integration-test-ts\";\n\n before(async function () {\n const stack = await LocalWorkspace.createOrSelectStack({\n stackName,\n projectName: \"bucket-test\",\n program: async () => {\n const bucket = new aws.s3.Bucket(\"test-bucket\", {\n tags: { Environment: \"test\", ManagedBy: \"pulumi\" },\n });\n return {\n bucketName: bucket.id,\n bucketArn: bucket.arn,\n };\n },\n });\n\n await stack.setConfig(\"aws:region\", { value: \"us-west-2\" });\n await stack.workspace.installPlugin(\"aws\", \"v7.34.0\");\n\n const upResult = await stack.up({ onOutput: console.log });\n outputs = upResult.outputs;\n });\n\n after(async function () {\n const stack = await LocalWorkspace.selectStack({ stackName, projectName: \"bucket-test\", program: async () => {} });\n await stack.destroy({ onOutput: console.log });\n await stack.workspace.removeStack(stackName);\n });\n\n it(\"creates a bucket with the right name prefix\", function () {\n const name = outputs[\"bucketName\"].value as string;\n expect(name).to.match(/^test-bucket/);\n });\n});\n\n```\n\nRun with: `mocha -r ts-node/register integration.test.ts`\n\n```go\n// integration_test.go\npackage integration_test\n\nimport (\n \"context\"\n \"fmt\"\n \"os\"\n \"testing\"\n\n \"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/s3\"\n \"github.com/pulumi/pulumi/sdk/v3/go/auto\"\n \"github.com/pulumi/pulumi/sdk/v3/go/auto/optup\"\n \"github.com/pulumi/pulumi/sdk/v3/go/pulumi\"\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc TestBucketIntegration(t *testing.T) {\n ctx := context.Background()\n\n stack, err := auto.NewStackInlineSource(ctx, \"integration-test\", \"bucket-test\",\n func(ctx *pulumi.Context) error {\n bucket, err := s3.NewBucket(ctx, \"test-bucket\", &s3.BucketArgs{\n Tags: pulumi.StringMap{\n \"Environment\": pulumi.String(\"test\"),\n \"ManagedBy\": pulumi.String(\"pulumi\"),\n },\n })\n if err != nil {\n return err\n }\n ctx.Export(\"bucketName\", bucket.ID())\n return nil\n },\n )\n assert.NoError(t, err)\n\n _ = stack.SetConfig(ctx, \"aws:region\", auto.ConfigValue{Value: \"us-west-2\"})\n upResult, err := stack.Up(ctx, optup.ProgressStreams(os.Stdout))\n assert.NoError(t, err)\n\n t.Cleanup(func() {\n _, _ = stack.Destroy(ctx)\n _ = stack.Workspace().RemoveStack(ctx, \"integration-test\")\n })\n\n name := fmt.Sprintf(\"%v\", upResult.Outputs[\"bucketName\"].Value)\n assert.Contains(t, name, \"test-bucket\")\n}\n\n```\n\nRun with: `go test ./... -v -timeout 10m`\n\n```csharp\n// IntegrationTests.cs\nusing System;\nusing System.Threading.Tasks;\nusing Pulumi.Automation;\nusing Xunit;\n\npublic class IntegrationTests : IAsyncLifetime\n{\n private WorkspaceStack _stack = null!;\n private UpResult _upResult = null!;\n\n public async Task InitializeAsync()\n {\n var program = PulumiFn.Create(() =>\n {\n var bucket = new Pulumi.Aws.S3.Bucket(\"test-bucket\", new()\n {\n Tags = new() { [\"Environment\"] = \"test\", [\"ManagedBy\"] = \"pulumi\" },\n });\n return new System.Collections.Generic.Dictionary<string, object?>\n {\n [\"bucketName\"] = bucket.Id,\n };\n });\n\n _stack = await LocalWorkspace.CreateOrSelectStackAsync(new InlineProgramArgs(\n projectName: \"bucket-test\",\n stackName: \"integration-test\",\n program: program\n ));\n\n await _stack.SetConfigAsync(\"aws:region\", new ConfigValue(\"us-west-2\"));\n _upResult = await _stack.UpAsync(new UpOptions { OnStandardOutput = Console.WriteLine });\n }\n\n public async Task DisposeAsync()\n {\n await _stack.DestroyAsync(new DestroyOptions { OnStandardOutput = Console.WriteLine });\n await _stack.Workspace.RemoveStackAsync(\"integration-test\");\n }\n\n [Fact]\n public void BucketNameHasExpectedPrefix()\n {\n var name = _upResult.Outputs[\"bucketName\"].Value.ToString();\n Assert.StartsWith(\"test-bucket\", name);\n }\n}\n\n```\n\nRun with: `dotnet test`\n\n```java\n// IntegrationTest.java\npackage myproject;\n\nimport com.pulumi.Context;\nimport com.pulumi.automation.LocalWorkspace;\nimport com.pulumi.automation.UpOptions;\nimport com.pulumi.automation.DestroyOptions;\nimport com.pulumi.automation.ConfigValue;\nimport com.pulumi.automation.WorkspaceStack;\nimport org.junit.jupiter.api.*;\nimport java.util.Map;\nimport static org.junit.jupiter.api.Assertions.*;\n\n@TestInstance(TestInstance.Lifecycle.PER_CLASS)\nclass IntegrationTest {\n\n private static final String PROJECT_NAME = \"bucket_test_project\";\n private static final String STACK_NAME = \"integration-test\";\n\n private WorkspaceStack stack;\n private Map<String, com.pulumi.automation.OutputValue> outputs;\n\n @BeforeAll\n void setUp() throws Exception {\n stack = LocalWorkspace.createOrSelectStack(PROJECT_NAME, STACK_NAME, (Context ctx) -> {\n var bucket = new com.pulumi.aws.s3.Bucket(\"test-bucket\",\n com.pulumi.aws.s3.BucketArgs.builder()\n .tags(Map.of(\"Environment\", \"test\", \"ManagedBy\", \"pulumi\"))\n .build());\n ctx.export(\"bucketName\", bucket.id());\n });\n\n stack.workspace().installPlugin(\"aws\", \"v7.34.0\");\n stack.setConfig(\"aws:region\", new ConfigValue(\"us-west-2\"));\n\n var upResult = stack.up(UpOptions.builder().onStandardOutput(System.out::println).build());\n outputs = upResult.outputs();\n }\n\n @AfterAll\n void tearDown() throws Exception {\n if (stack != null) {\n stack.destroy(DestroyOptions.builder().onStandardOutput(System.out::println).build());\n stack.workspace().removeStack(STACK_NAME);\n }\n }\n\n @Test\n void bucketNameHasExpectedPrefix() {\n var name = (String) outputs.get(\"bucketName\").value();\n assertTrue(name.startsWith(\"test-bucket\"), \"Unexpected bucket name: \" + name);\n }\n}\n\n```\n\nRun with: `mvn test`\n\n### Using the Go integration framework\n\nIf you prefer Go-based integration tests, Pulumi ships a purpose-built Go test framework at `github.com/pulumi/pulumi/pkg/v3/testing/integration`. It handles the full `create → validate → destroy` lifecycle for any Pulumi program (written in any language), with an `ExtraRuntimeValidation` hook for assertions against deployed state.\n\n```go\nfunc TestS3Website(t *testing.T) {\n integration.ProgramTest(t, &integration.ProgramTestOptions{\n Dir: path.Join(\"..\", \"my-s3-website\"),\n Config: map[string]string{\"aws:region\": \"us-west-2\"},\n ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {\n url := stack.Outputs[\"websiteUrl\"].(string)\n resp, _ := http.Get(\"http://\" + url)\n assert.Equal(t, 200, resp.StatusCode)\n },\n })\n}\n\n```\n\n> **Best practice:** Always destroy test stacks in a `finally` block or test teardown fixture. Leaked integration test stacks are a common cause of unexpected cloud spend.\n\n## How does policy as code complement IaC testing?\n\nUnit and integration tests validate what your infrastructure *does*. Policy as code enforces what your infrastructure *must* conform to—security standards, tagging conventions, compliance requirements—and it runs automatically on every `pulumi preview` and `pulumi up`.\n\nPulumi Policies are currently supported in Python and TypeScript. You write policies in the same language as the rest of your stack, without learning a DSL. A `mandatory` policy blocks a deployment entirely when violated; an `advisory` policy surfaces a warning but allows the deploy to proceed.\n\n```python\n# __main__.py in your policy pack directory\nfrom pulumi_policy import (\n EnforcementLevel,\n PolicyPack,\n ReportViolation,\n ResourceValidationArgs,\n ResourceValidationPolicy,\n)\n\nREQUIRED_TAGS = {\"Name\", \"Environment\", \"Owner\"}\n\ndef require_tags(args: ResourceValidationArgs, report_violation: ReportViolation):\n if args.resource_type.startswith(\"aws:\"):\n tags = args.props.get(\"tags\") or {}\n missing = REQUIRED_TAGS - set(tags.keys())\n if missing:\n report_violation(\n f\"Resource is missing required tags: {', '.join(sorted(missing))}\"\n )\n\ndef no_public_s3(args: ResourceValidationArgs, report_violation: ReportViolation):\n if args.resource_type == \"aws:s3/bucket:Bucket\":\n if args.props.get(\"acl\") in (\"public-read\", \"public-read-write\"):\n report_violation(\"S3 buckets must not have a public ACL.\")\n\nPolicyPack(\n name=\"aws-security-baseline\",\n policies=[\n ResourceValidationPolicy(\n name=\"require-tags\",\n description=\"All AWS resources must have Name, Environment, and Owner tags.\",\n enforcement_level=EnforcementLevel.MANDATORY,\n validate=require_tags,\n ),\n ResourceValidationPolicy(\n name=\"no-public-s3\",\n description=\"S3 buckets must not be publicly accessible via ACL.\",\n enforcement_level=EnforcementLevel.MANDATORY,\n validate=no_public_s3,\n ),\n ],\n)\n\n```\n\n```typescript\n// index.ts in your policy pack directory\nimport * as aws from \"@pulumi/aws\";\nimport { PolicyPack, validateResourceOfType } from \"@pulumi/policy\";\n\nnew PolicyPack(\"aws-security-baseline\", {\n policies: [\n {\n name: \"require-tags\",\n description: \"All EC2 instances must have Name, Environment, and Owner tags.\",\n enforcementLevel: \"mandatory\",\n validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {\n const required = [\"Name\", \"Environment\", \"Owner\"];\n const tags = instance.tags || {};\n for (const tag of required) {\n if (!tags[tag]) {\n reportViolation(`Missing required tag: ${tag}`);\n }\n }\n }),\n },\n {\n name: \"no-public-s3\",\n description: \"S3 buckets must not have a public ACL.\",\n enforcementLevel: \"mandatory\",\n validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {\n if (bucket.acl === \"public-read\" || bucket.acl === \"public-read-write\") {\n reportViolation(\"S3 bucket must not have a public ACL.\");\n }\n }),\n },\n ],\n});\n\n```\n\n**Running a policy pack**\n\n```bash\n# Scaffold a new policy pack from a template\nmkdir my-policies && cd my-policies\npulumi policy new aws-typescript\n\n# Run policy checks against a stack\npulumi preview --policy-pack ./my-policies\npulumi up --policy-pack ./my-policies\n\n# Or publish to Pulumi Cloud and enforce organization-wide\npulumi policy publish\n\n```\n\n> As Joe Duffy, Pulumi CEO, [puts it](https://www.pulumi.com/blog/the-agentic-infrastructure-era/): “The smartest agent in the world still needs guardrails, audit trails, and policy enforcement to be trusted with production systems at scale.”\n\nPolicy checks complement unit tests: unit tests verify your intent (“I wrote tags into this resource”), while policies enforce your standards (“all resources must have these tags, regardless of what any one developer intended”). For complex compliance environments, [publish policies to Pulumi Cloud](https://www.pulumi.com/docs/insights/policy/) and assign them via policy groups to enforce them across the stacks or accounts you choose—including organization-wide.\n\n## How is testing IaC in Pulumi different from Terraform?\n\nThe fundamental difference is **language cohesion**. With Pulumi, you write infrastructure, tests, and policies all in the same general-purpose language. With Terraform, your infrastructure is HCL but your tests must be something else—either Go (Terratest) or a constrained HCL DSL (`terraform test`).\n\nPulumi\n\nTerratest\n\n`terraform test` (≥ 1.6)\n\n**Language for tests**\n\nSame language as infra (Python, TypeScript, Go, C#, Java); YAML programs tested via Automation API from any of those languages\n\nAlways Go (regardless of infra language)\n\nHCL DSL (`.tftest.hcl`)\n\n**Unit tests with mocks**\n\nYes — `pulumi.runtime.set_mocks()`, no cloud credentials needed\n\nNo — no mock layer for cloud providers\n\nLimited — `mock_provider` (v1.7+) is HCL-declarative, no programmatic logic\n\n**Integration testing**\n\nAutomation API (any language) or Go framework\n\nFull-featured but Go-only\n\nYes, via `command = apply` run blocks\n\n**Policy / guardrails**\n\nPulumi Policies: Python or TypeScript, runs at preview time\n\nExternal tools (checkov, tfsec, OPA/Rego — separate toolchain)\n\nSentinel (enterprise) or external\n\n**Execution speed**\n\nUnit: milliseconds; integration: depends on cloud\n\nMinutes (real deployments by default)\n\nPlan-only: fast; apply: minutes\n\n**Learning curve**\n\nUse existing language skills and test frameworks\n\nRequires Go knowledge and understanding of `go test`\n\nLow if you know HCL; limited expressiveness\n\nTerratest is battle-tested and widely adopted, particularly for Terraform module testing. It offers deep integrations with AWS, GCP, Azure, and Kubernetes. Its limitation is that it has no mock layer for cloud providers, so most test suites deploy real infrastructure, which makes them slower and costlier to run on every commit.\n\n`terraform test` has improved significantly in Terraform 1.6 and 1.7. The `command = plan` mode avoids real deployments, and `mock_provider` enables basic unit-like testing. But expressiveness is bounded by HCL’s declarative model—no general-purpose programming, no third-party assertion libraries, and a fixed set of `run`/`assert` test constructs.\n\nWith Pulumi, there’s no context switch. The same developer who writes the infrastructure writes the tests in the same language, using the same IDE, the same debugger, and the same CI pipeline. That cohesion is a productivity multiplier.\n\n## How to set up IaC testing with Pulumi\n\nFollow these steps to add a complete test suite to a Pulumi project. The examples use Python, but the pattern is identical in TypeScript, Go, C#, or Java.\n\n{ \"@context\": \"https://schema.org\", \"@type\": \"HowTo\", \"name\": \"How to Set Up IaC Testing with Pulumi\", \"description\": \"Add unit tests, integration tests, and policy checks to a Pulumi infrastructure project in seven steps.\", \"totalTime\": \"PT30M\", \"step\": \\[ { \"@type\": \"HowToStep\", \"name\": \"Install Pulumi and choose a language SDK\", \"text\": \"Install the Pulumi CLI and initialize a new project with your preferred language. Run 'pulumi new aws-python' (or aws-typescript, aws-go, etc.) to scaffold a project with the right SDK dependencies.\" }, { \"@type\": \"HowToStep\", \"name\": \"Add a test framework\", \"text\": \"Add a language-native test runner: pytest for Python ('pip install pytest'), Mocha + ts-node for TypeScript ('npm install --save-dev mocha ts-node @types/mocha chai'), or the standard testing package for Go (built in).\" }, { \"@type\": \"HowToStep\", \"name\": \"Implement the Mocks class and set mocks before importing your program\", \"text\": \"Create a class that extends pulumi.runtime.Mocks (Python) or implements the setMocks interface (TypeScript). Override new\\_resource to return dummy IDs and pass-through state. Call pulumi.runtime.set\\_mocks() before importing your Pulumi program—this is the critical import-order rule.\" }, { \"@type\": \"HowToStep\", \"name\": \"Write unit tests asserting resource properties\", \"text\": \"Write test functions that access stack outputs (infra.server.tags, infra.group.ingress) via pulumi.Output.all(...).apply(...). Assert security rules, required tags, naming conventions, and other properties. Decorate Python test methods with @pulumi.runtime.test; use done() callbacks in Mocha.\" }, { \"@type\": \"HowToStep\", \"name\": \"Add integration tests using the Automation API with ephemeral stacks\", \"text\": \"Import pulumi.automation (Python) or @pulumi/pulumi/automation (TypeScript). Create an ephemeral stack with create\\_or\\_select\\_stack(), call stack.up() to deploy, run assertions against stack.outputs, then call stack.destroy() in a teardown fixture. Always destroy in a finally block to avoid leaked resources.\" }, { \"@type\": \"HowToStep\", \"name\": \"Enforce guardrails with a Pulumi policy pack\", \"text\": \"Create a policy pack directory and run 'pulumi policy new aws-python' or 'pulumi policy new aws-typescript'. Define ResourceValidationPolicy rules for your compliance requirements. Use EnforcementLevel.MANDATORY to block non-compliant deployments. Run 'pulumi preview --policy-pack ./my-policies' to enforce locally, or publish to Pulumi Cloud for org-wide enforcement.\" }, { \"@type\": \"HowToStep\", \"name\": \"Run all tests in CI on every pull request\", \"text\": \"Add unit tests to your standard CI job (no cloud credentials needed). Add integration tests in a separate CI stage with cloud credentials, using a dedicated test account. Reference the Pulumi GitHub Actions integration or any CI provider—unit tests run on every PR commit; integration tests run on merge to main or on a schedule.\" } \\] }\n\n**Step 1: Install Pulumi and choose a language SDK**\n\n```bash\n# Install Pulumi CLI\ncurl -fsSL https://get.pulumi.com | sh\n\n# Create a new project (or use an existing one)\npulumi new aws-python --name my-project --stack dev\n\n```\n\n**Step 2: Add a test framework**\n\n```bash\n# Python\npip install pytest pytest-asyncio\n\n# TypeScript\nnpm install --save-dev mocha ts-node @types/mocha chai @types/chai\n\n# Go uses the built-in testing package — no additional dependencies\n\n```\n\n**Step 3: Implement the Mocks class**\n\nCreate `mocks.py` (or equivalent) with your `Mocks` subclass. Keep it simple for unit tests: return `[args.name + \"_id\", args.inputs]` from `new_resource`.\n\n**Step 4: Write unit tests**\n\nCreate `test_infra.py` in your project root. Import mocks first, then your program. Write test functions that use `@pulumi.runtime.test` and `pulumi.Output.all(...).apply(...)` to assert resource properties.\n\n**Step 5: Add integration tests**\n\nCreate `test_integration.py` with a `pytest` fixture that creates a stack, calls `stack.up()`, yields outputs for assertions, and calls `stack.destroy()` in teardown. Point this at a dedicated test cloud account.\n\n**Step 6: Create a policy pack**\n\n```bash\nmkdir policies && cd policies\npulumi policy new aws-python\n# Edit __main__.py to add your rules\n\n```\n\n**Step 7: Wire it all into CI**\n\n```yaml\n# .github/workflows/test.yml (GitHub Actions excerpt)\njobs:\n unit-tests:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: pulumi/actions@v6\n - run: pip install -r requirements.txt\n - run: python -m pytest tests/unit/ -v\n\n integration-tests:\n runs-on: ubuntu-latest\n needs: unit-tests\n environment: staging\n steps:\n - uses: actions/checkout@v4\n - uses: pulumi/actions@v6\n - run: pip install -r requirements.txt\n - env:\n PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}\n AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}\n AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n run: python -m pytest tests/integration/ -v --timeout=300\n\n```\n\n## Frequently asked questions\n\n### What is infrastructure as code testing?\n\nInfrastructure as code testing is the practice of writing automated checks that validate your IaC programs before they deploy to production. Just like application testing, it includes unit tests (fast, no cloud credentials, mock the provider), integration tests (real cloud deployments in ephemeral environments), and policy checks (rules that enforce compliance standards on every preview and deploy).\n\n### Can you unit test IaC without deploying to the cloud?\n\nYes. Pulumi’s mocking framework intercepts all cloud API calls and replaces them with in-process stubs. Unit tests run entirely in memory—no cloud credentials, no network calls, no cost. A suite of 50 unit tests runs in under a second. This is the primary reason to write unit tests: fast, free, deterministic feedback on every commit.\n\n### Do you need real cloud credentials to test Pulumi?\n\nOnly for integration tests. Unit tests use Pulumi’s mock runtime and require no cloud credentials at all. Policy checks also run without credentials at `pulumi preview` time. Integration tests that use the Automation API do need credentials—they deploy real resources—so they’re typically run in a CI stage with access to a dedicated test account, not on every PR.\n\n### What’s the difference between unit and integration tests for IaC?\n\nUnit tests validate resource properties, configurations, and relationships using mocked cloud providers—they run in milliseconds with no cloud credentials. Integration tests deploy actual resources to a real cloud environment, validate runtime behavior (does the endpoint respond? does the database accept connections?), and then destroy everything. Unit tests are cheap and frequent; integration tests are slower, cost real cloud spend, and run less often.\n\n### How do you mock cloud resources in Pulumi?\n\nImplement `pulumi.runtime.Mocks` (Python) or call `pulumi.runtime.setMocks()` (TypeScript/JavaScript) before importing your Pulumi program. The `new_resource` method receives every resource registration and returns a fake `[id, state]` pair. The `call` method handles data-source lookups. Set mocks with `pulumi.runtime.set_mocks(MyMocks())` and then import your program—the runtime will route all resource registrations through your mock instead of making real API calls.\n\n### What test frameworks work with Pulumi?\n\nAny language-native test framework works. For Python: **pytest** (recommended) or **unittest**. For TypeScript/JavaScript: **Mocha**, **Jest**, or **Vitest**. For Go: the standard `testing` package. For C#: **NUnit** or **xUnit**. For Java: **JUnit**. The `@pulumi/pulumi/automation` SDK and `pulumi.automation` module integrate naturally with all of them. YAML is Pulumi’s declarative configuration language; because it has no control flow or executable statements, you cannot write test logic in YAML itself. YAML programs are tested by pointing the Automation API from Python, TypeScript, Go, C#, or Java at the project directory and asserting on the stack outputs.\n\n### How do you test Pulumi in CI/CD?\n\nSplit your test suite into two CI stages. Stage 1 (unit tests): runs on every PR commit, no cloud credentials required, fast. Stage 2 (integration tests): runs on merge to main or on a schedule, requires cloud credentials for a dedicated test account, uses the Automation API to deploy ephemeral stacks. The [Pulumi GitHub Actions integration](https://github.com/pulumi/actions) simplifies credential injection and stack management in both stages.\n\n### Is policy as code the same as testing?\n\nPolicy as code is complementary to—but distinct from—testing. Tests validate what your program *produces* (resource A has property B); policies enforce what your resources *must conform to* (all resources must have tag X). Policies run automatically at preview time and block non-compliant deployments at deploy time. Together, they create defense in depth: tests verify intent, policies enforce standards regardless of intent.\n\n### How is Pulumi testing different from Terratest?\n\nTerratest typically deploys real infrastructure—it has no mock layer for cloud providers—so most test runs provision actual cloud resources, incurring real cost and taking 5–30 minutes. Tests must be written in Go regardless of what language your infrastructure uses. Pulumi’s unit testing framework runs in milliseconds with no cloud credentials, uses your existing language and test runner, and provides true mock isolation. For integration testing, Pulumi’s Automation API offers a similar model to Terratest but in any language.\n\n### How do you tear down resources after integration tests?\n\nIn Python pytest, use a module-scoped fixture that yields after `stack.up()` and calls `stack.destroy()` in the teardown. In TypeScript Mocha, call `stack.destroy()` in an `after()` hook. In Go, use `defer stack.Destroy(ctx, ...)`. Always use a `try/finally` pattern (or equivalent in your language) so teardown runs even when a test assertion fails. Pulumi Cloud also has built-in [stack TTL and auto-destroy](https://www.pulumi.com/docs/deployments/concepts/) features for extra safety.\n\n## Where to go next\n\nTesting IaC is not an all-or-nothing investment. Start by adding a handful of unit tests to your most critical stack—the one that manages your production VPC, your IAM roles, or your data infrastructure. Pick three to five properties that, if wrong, would cause an outage or a security incident. Write tests for those. Run them in CI. Expand from there.\n\nWhen you’re ready to go deeper:\n\n- **[Testing overview](https://www.pulumi.com/docs/iac/guides/testing/)** — Pulumi’s full testing documentation\n- **[Unit testing guide](https://www.pulumi.com/docs/iac/guides/testing/unit/)** — detailed mock API reference with Go and C# examples\n- **[Automation API integration testing](https://www.pulumi.com/docs/iac/guides/testing/integration/automation-api/)** — advanced patterns (multi-stack tests, config injection, parallel test execution)\n- **[Policy as code authoring](https://www.pulumi.com/docs/insights/policy/policy-packs/authoring/)** — writing and publishing Pulumi Policies\n- **[Pulumi vs. Terraform](https://www.pulumi.com/docs/iac/comparisons/terraform/)** — a full comparison of the two platforms\n\nIf you’re migrating from Terraform, the [Pulumi conversion tool](https://www.pulumi.com/tf2pulumi/) translates your existing HCL to Python, TypeScript, Go, C#, and more, including your test infrastructure. Your Terratest or `terraform test` suites can be ported to Pulumi’s native test runner—using your existing language—as part of the migration.\n\n**[Get started with Pulumi for free →](https://app.pulumi.com/signup)**","publishedAt":"2026-06-30T21:00:00.000Z","fetchedAt":"2026-07-02T17:02:05.510Z","url":"https://www.pulumi.com/blog/how-to-test-infrastructure-as-code/","media":[{"type":"image","url":"https://www.pulumi.com/blog/how-to-test-infrastructure-as-code/meta.png","r2Key":"releases/aed9f741c1e612c637db2d1fb961b9a81ddd367a6770e341e06f996b858d9bc0.png","r2Url":"https://media.releases.sh/releases/aed9f741c1e612c637db2d1fb961b9a81ddd367a6770e341e06f996b858d9bc0.png"}],"coverageCount":0},{"id":"rel_pcEG_HH32S9JlI4lNmlDS","version":null,"type":"feature","title":"Enforce ISO 27001 Across Your AWS Infrastructure","summary":"New ISO/IEC 27001:2022 policy pack for AWS, available in Pulumi Cloud as iso-27001-aws, includes 238 ready-to-run policies that map the standard's security controls to AWS resource configurations.","titleGenerated":"Pulumi ships pre-built ISO 27001 policy pack for AWS","titleShort":"Pre-built ISO 27001 policy pack for AWS","breaking":"none","importance":null,"content":"![](https://www.pulumi.com/blog/iso-27001-policy-pack-for-aws/meta.png)\n\nISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We’re changing that.\n\nToday we’re shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as `iso-27001-aws`. It encodes the standard’s security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months.\n\n## Why ISO 27001 matters\n\nFor many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it.\n\n## How the pack maps to ISO 27001\n\nThe hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance.\n\nThe pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the [pack reference](https://www.pulumi.com/docs/reference/pre-built-policy-packs/iso-27001/aws/).\n\n## Audit and prevent\n\nThe same pack works two ways, so you can both reach compliance and stay there:\n\n1. **Audit.** Scan your existing AWS estate against the pack, including resources that Pulumi doesn’t manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects.\n2. **Prevent.** Run the same pack as a preventative policy during `pulumi up` to block non-compliant resources before they’re ever created. New infrastructure is born aligned to the standard.\n\nAudit gets you clean. Preventative policies keep you clean.\n\n## A growing library of pre-built packs\n\nISO 27001 joins a growing library of pre-built packs for AWS, each authored and maintained by Pulumi and kept current with its source standard:\n\n- **ISO/IEC 27001:2022**\n- **CIS Controls v8.1**\n- **NIST SP 800-53 Rev. 5**\n- **PCI DSS v4.0**\n- **HITRUST CSF v11.5**\n- **Pulumi Best Practices**\n\nAdopting any pack means you skip the authoring work entirely, inherit framework mappings maintained by Pulumi, and apply a consistent baseline across every stack and account.\n\n## Get started today\n\nThe ISO 27001 pack is available now to every Pulumi Cloud user:\n\n1. Browse the [pack reference](https://www.pulumi.com/docs/reference/pre-built-policy-packs/iso-27001/aws/) to see all 238 policies and how they map to the standard’s controls.\n2. Explore the full [pre-built packs index](https://www.pulumi.com/docs/insights/policy/policy-packs/pre-built-packs/).\n3. Follow the [get-started guide](https://www.pulumi.com/docs/insights/policy/get-started/) to run your first audit.\n\n## Try Pulumi policies\n\nReady to align your AWS infrastructure to ISO 27001? [Sign up for Pulumi Cloud](https://app.pulumi.com/signup) and run the pack against your estate, or read the [policy get-started guide](https://www.pulumi.com/docs/insights/policy/get-started/) to dig in.\n\nNeed a compliance pack for a framework that isn’t listed here? Open a request in [pulumi/pulumi-cloud-requests](https://github.com/pulumi/pulumi-cloud-requests) or come tell us in the [community Slack](https://slack.pulumi.com/). We’re listening.","publishedAt":"2026-06-30T00:00:00.000Z","fetchedAt":"2026-07-01T01:01:16.109Z","url":"https://www.pulumi.com/blog/iso-27001-policy-pack-for-aws/","media":[{"type":"image","url":"https://www.pulumi.com/blog/iso-27001-policy-pack-for-aws/meta.png","r2Key":"releases/92c4119386dfbf9a3d5c179af8cd773b2eb36980e122a59f89845c12d5d1a124.png","r2Url":"https://media.releases.sh/releases/92c4119386dfbf9a3d5c179af8cd773b2eb36980e122a59f89845c12d5d1a124.png"}],"coverageCount":0},{"id":"rel_xd7KcXSqiUCd3yPiGscuJ","version":null,"type":"feature","title":"Fully Automated AI Inference on AWS, Azure, and Google Cloud with Pulumi","summary":"![](https://www.pulumi.com/blog/fully-automated-ai-inference-aws-azure-gcp-pulumi/meta.png)\n\nPutting [Ollama](https://ollama.com/) on a cloud GPU is s...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/fully-automated-ai-inference-aws-azure-gcp-pulumi/meta.png)\n\nPutting [Ollama](https://ollama.com/) on a cloud GPU is something I keep coming back to. A while ago I wrote up [running open-source LLMs on an AWS EC2 box with Ollama and Pulumi](https://www.pulumi.com/blog/run-deepseek-on-aws-ec2-using-pulumi/), and the shape never really changes: a GPU instance, a model server, and a firewall rule in front. Infrastructure as code earned its place by making that kind of setup predictable and repeatable, and AI infrastructure is no exception. A GPU box serving a model is still a VM, a disk, and a firewall rule, and it should be declared like one.\n\n[Thorsten Hans](https://www.linkedin.com/in/thorstenhans/) made exactly that case in his Akamai post, [Fully Automated AI Infrastructures with Terraform and Akamai Cloud](https://developers.akamai.com/blog/fully-automated-ai-infrastructure-with-terraform-and-akamai-cloud), which stands up a single GPU instance on Linode, installs the drivers, runs Ollama, and pulls a model, with no manual steps after `terraform apply`.\n\nI liked the shape of it, so this post ports the same idea to Pulumi and runs it across AWS, Azure, and Google Cloud instead of one. The result is one program shape per cloud: a single `pulumi up` brings up a GPU box that installs its own driver, runs Ollama, and pulls a model with no manual steps, and a single `pulumi destroy` takes it back down. Along the way it drops the two imperative bits the Terraform version leans on: a static access token sitting in an environment variable, and a `null_resource` running a shell loop to wait for the model. The first becomes an OIDC login from a Pulumi ESC environment, so no long-lived key lives anywhere. The second turns out not to be a resource at all.\n\n## What you are building\n\nStrip away the per-cloud naming and every version of this is the same three things: a GPU virtual machine, a firewall in front of it, and a cloud-init script that turns a bare Ubuntu box into a running inference server. The model serving runs on [Ollama](https://ollama.com/), which exposes an HTTP API on port `11434` and keeps the model resident in GPU memory between requests.\n\n```\nflowchart LR\nDev([Your machine / curl]) -->|\"HTTP :11434\"| FW[\"Firewall / security group
(allow 11434, optional 22)\"]\nFW --> VM[\"GPU VM (Ubuntu 24.04)
NVIDIA driver + Ollama\"]\nVM -->|\"resident in GPU memory\"| Model[\"qwen2.5:14b\"]\nESC[\"Pulumi ESC
pulumi-idp/auth\"] -.->|\"OIDC login (short-lived creds)\"| Pulumi[\"pulumi up\"]\nPulumi -.->|\"AWS / Azure / GCP\"| VM\n```\n\nComponent\n\nPort\n\nDescription\n\nGPU VM\n\n\\-\n\nUbuntu 24.04 with an NVIDIA T4-class GPU. Installs the driver and Ollama from cloud-init, then pulls the model.\n\n[Ollama](https://ollama.com/)\n\n11434\n\nServes the model over an HTTP API and keeps it in GPU memory between calls.\n\nFirewall / security group\n\n\\-\n\nAllows inbound `11434` (and `22` when you ask for it). Open to the world for a demo; lock the CIDR down for anything real.\n\n`pulumi-idp/auth` (ESC)\n\n\\-\n\nOne environment that brokers an OIDC login into AWS, Azure, and GCP. No static keys in code or CI.\n\nOne detail here is worth pausing on, and it explains why the Pulumi version comes out shorter than the Terraform one. The Akamai project ends with a `null_resource` that runs a `curl` loop in `local-exec` to block `terraform apply` until the model finishes downloading. That is not infrastructure but a runtime check wearing a resource costume. Pulumi has a [Command provider](https://www.pulumi.com/registry/packages/command/) that would let you reproduce it line for line, and this post deliberately does not. The program provisions the box, the box pulls the model on its own, and the program prints the endpoint. Whether the model has finished downloading yet is a question you answer with a `curl`, not a question your IaC tool should be holding a deployment open to ask.\n\n## Prerequisites\n\nBefore getting started, ensure you have:\n\n- [Pulumi CLI](https://www.pulumi.com/docs/iac/download-install/) installed and configured\n- A [Pulumi Cloud account](https://app.pulumi.com/signup) (ESC and OIDC live here)\n- An account on at least one of [AWS](https://aws.amazon.com/), [Azure](https://azure.microsoft.com/), or [Google Cloud](https://cloud.google.com/), with an OIDC trust set up for Pulumi (covered below)\n- Enough GPU quota in your target region for one T4-class instance; a fresh account often starts at zero, which is the most common reason a first deploy fails, so check it before you run `pulumi up`\n- Node.js 18+ for the TypeScript program\n- `curl` to talk to the inference endpoint once it comes up\n\nThis post serves the `qwen2.5:14b` model, the same one the Akamai article uses, because the 4-bit quant fits comfortably on a single 16 GB T4. The model is one config value (`model`), so swap in anything [Ollama supports](https://ollama.com/library); match the GPU to the model’s memory footprint, because a model that overflows VRAM still runs but spills onto the CPU and crawls.\n\n## Credentials without the copy-paste\n\nThe Terraform version authenticates the only way a single-cloud demo can: you mint a personal access token, export it as `LINODE_TOKEN`, and the provider reads it from the environment. It works, but that token is long-lived, it sits in your shell history and your CI secrets, and you mint one per cloud. Across three clouds that is three static keys to rotate and worry about.\n\nPulumi [ESC (Environments, Secrets, and Configuration)](https://www.pulumi.com/docs/esc/) replaces it all with an OIDC login. The idea: instead of storing a cloud key, you store a *trust relationship*. At deploy time, ESC presents a short-lived OIDC token to AWS, Azure, or Google Cloud, and each one hands back temporary credentials scoped to a role you control. Nothing long-lived is ever written down.\n\nI keep that wiring in one environment, `pulumi-idp/auth`, and every stack imports it. Here is the whole thing:\n\n```yaml\n# pulumi-idp/auth: one ESC environment that brokers an OIDC login into all three\n# clouds. Every stack imports it. No static cloud key lives here or anywhere else.\nvalues:\n aws:\n login:\n fn::open::aws-login:\n oidc:\n roleArn: arn:aws:iam::123456789012:role/pulumi-esc\n sessionName: pulumi-esc\n azure:\n login:\n fn::open::azure-login:\n clientId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee\n tenantId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee\n subscriptionId: /subscriptions/00000000-0000-0000-0000-000000000000\n oidc: true\n gcp:\n login:\n fn::open::gcp-login:\n project: 123456789012 # numeric project number, not the project ID\n oidc:\n workloadPoolId: pulumi-esc\n providerId: pulumi-esc\n serviceAccount: pulumi-esc@my-project.iam.gserviceaccount.com\n environmentVariables:\n # AWS: read by the Pulumi AWS provider, the AWS SDKs, and the aws CLI\n AWS_ACCESS_KEY_ID: ${aws.login.accessKeyId}\n AWS_SECRET_ACCESS_KEY: ${aws.login.secretAccessKey}\n AWS_SESSION_TOKEN: ${aws.login.sessionToken}\n # Azure: read by the azure-native provider\n ARM_USE_OIDC: \"true\"\n ARM_CLIENT_ID: ${azure.login.clientId}\n ARM_TENANT_ID: ${azure.login.tenantId}\n ARM_SUBSCRIPTION_ID: ${azure.login.subscriptionId}\n ARM_OIDC_TOKEN: ${azure.login.oidc.token}\n # Google Cloud: read by the Pulumi Google Cloud provider\n GOOGLE_CLOUD_PROJECT: ${gcp.login.project}\n GOOGLE_OAUTH_ACCESS_TOKEN: ${gcp.login.accessToken}\n\n```\n\nYou only need the blocks for the clouds you actually deploy to. Opening this environment makes ESC perform a live OIDC login for each cloud listed, so trim it to the one you use, or keep all three if, like me, you bounce between them.\n\nEach cloud needs a one-time trust setup so this login is allowed at all: an [IAM OIDC identity provider and role on AWS](https://www.pulumi.com/docs/esc/guides/configuring-oidc/aws/), a [federated credential on an Azure app registration](https://www.pulumi.com/docs/esc/guides/configuring-oidc/azure/), and a [Workload Identity Pool on Google Cloud](https://www.pulumi.com/docs/esc/guides/configuring-oidc/gcp/). You do that once; after that, `pulumi-idp/auth` is the only thing any stack references for credentials.\n\nA stack opts into it with one block in its stack config. The AWS stack’s `Pulumi.aws.yaml`:\n\n```yaml\n# Pulumi.aws.yaml\nenvironment:\n - pulumi-idp/auth\n\n```\n\nThat is the entire credential story. No keys in the program, no keys in CI, nothing to rotate. The program below never mentions a secret; it only creates resources, and the ambient credentials from `pulumi-idp/auth` carry the request.\n\n## One cloud-init, three clouds\n\nThe part that turns a bare Ubuntu box into an inference server is identical on every cloud, so it lives in one file, `cloud-init.yaml`, that all three programs read. It follows the Akamai cloud-config closely, with a couple of robustness tweaks for a multi-cloud run, and it runs in a deliberate order because the GPU driver needs a reboot before Ollama can see the card:\n\n1. Update packages and install the kernel headers and `ubuntu-drivers`.\n2. Install the NVIDIA driver, then reboot so the kernel loads it.\n3. On the next boot, a one-shot systemd service installs Ollama, binds it to `0.0.0.0:11434`, and pulls the model.\n4. The service disables itself, so it never runs again.\n\n```yaml\n#cloud-config\n# Zero-touch Ollama GPU box. Cloud-agnostic: no provider metadata, no static creds.\n# The Pulumi program substitutes the model name on the `ollama pull` line below\n# before this is passed as user-data (AWS/GCP) or custom-data (Azure).\n\nwrite_files:\n # Make Ollama listen on every interface and never unload the model from VRAM.\n - path: /etc/systemd/system/ollama.service.d/override.conf\n content: |\n [Service]\n Environment=\"OLLAMA_HOST=0.0.0.0:11434\"\n Environment=\"OLLAMA_KEEP_ALIVE=-1\"\n\n # Runs once on the post-reboot boot, after the GPU driver is loaded.\n - path: /usr/local/bin/ollama-setup.sh\n permissions: '0755'\n content: |\n #!/usr/bin/env bash\n set -euxo pipefail\n\n # Install Ollama; the installer creates and starts the ollama systemd unit.\n curl -fsSL https://ollama.com/install.sh | sh\n\n # Pick up the OLLAMA_HOST / OLLAMA_KEEP_ALIVE override written above.\n systemctl daemon-reload\n systemctl enable ollama.service\n systemctl restart ollama.service\n\n # Wait for the daemon to bind its socket before pulling. This is the box\n # waiting on its OWN local daemon, not an external readiness gate.\n until curl -fsS http://127.0.0.1:11434/api/tags >/dev/null 2>&1; do\n sleep 2\n done\n\n # Pre-pull the model so the endpoint answers on the very first request.\n ollama pull __MODEL__\n\n # One-shot: never run again on future boots.\n systemctl disable ollama-setup.service\n\n - path: /etc/systemd/system/ollama-setup.service\n content: |\n [Unit]\n Description=One-time Ollama install and model pull\n After=network-online.target\n Wants=network-online.target\n\n [Service]\n Type=oneshot\n ExecStart=/usr/local/bin/ollama-setup.sh\n RemainAfterExit=true\n # The model pull runs for several minutes; without this, systemd's default\n # 90s start timeout kills the service mid-download and the model never lands.\n TimeoutStartSec=0\n\n [Install]\n WantedBy=multi-user.target\n\nruncmd:\n - apt-get update\n - DEBIAN_FRONTEND=noninteractive apt-get -y upgrade\n # linux-headers-generic also covers the kernel the upgrade above may have pulled\n # in, so DKMS builds the NVIDIA module for the kernel that boots next.\n - DEBIAN_FRONTEND=noninteractive apt-get install -y \"linux-headers-$(uname -r)\" linux-headers-generic ubuntu-drivers-common\n # --gpgpu selects the headless server driver branch, the right one for a compute\n # GPU like the T4; bare `ubuntu-drivers install` would pull the desktop stack.\n - ubuntu-drivers install --gpgpu\n - systemctl enable ollama-setup.service\n\npower_state:\n mode: reboot\n message: Rebooting to load the NVIDIA driver before Ollama setup\n condition: true\n\n```\n\nThe model name is the literal token `__MODEL__`. The Pulumi program reads this file at deploy time and substitutes your `model` config value before handing it to the instance. Two environment settings are doing quiet but important work: `OLLAMA_HOST=0.0.0.0:11434` makes Ollama listen on every interface instead of localhost alone, and `OLLAMA_KEEP_ALIVE=-1` keeps the model pinned in GPU memory so only the first request pays the load cost.\n\n## The programs\n\nEvery program has the same five beats: read the config, template the `cloud-init.yaml`, open the inbound ports, launch the GPU instance with that cloud-init as its user data, and export the endpoint. What differs is only the dialect each cloud speaks for “GPU instance” and “firewall rule.”\n\nThe shared contract keeps the three listings legible side by side: the same `model` and `allowSsh` config keys, the same `cloud-init.yaml`, and the same four exports (`publicIp`, `ollamaEndpoint`, `generateEndpoint`, `tagsEndpoint`). Pick your cloud:\n\n```typescript\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as aws from \"@pulumi/aws\";\nimport * as fs from \"fs\";\n\nconst cfg = new pulumi.Config();\nconst model = cfg.get(\"model\") ?? \"qwen2.5:14b\";\nconst allowSsh = cfg.getBoolean(\"allowSsh\") ?? false;\nconst region = (cfg.get(\"region\") ?? \"us-east-1\") as aws.Region;\n\n// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).\nconst userData = fs.readFileSync(\"cloud-init.yaml\", \"utf8\").replace(/__MODEL__/g, model);\n\n// Region comes from config; credentials arrive ambiently from pulumi-idp/auth.\nconst provider = new aws.Provider(\"aws\", { region });\n\n// Most recent Ubuntu 24.04 LTS (amd64, hvm, gp3) published by Canonical.\nconst ubuntu = aws.ec2.getAmi({\n mostRecent: true,\n owners: [\"099720109477\"],\n filters: [\n { name: \"name\", values: [\"ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*\"] },\n { name: \"virtualization-type\", values: [\"hvm\"] },\n ],\n}, { provider });\n\nconst ingress: aws.types.input.ec2.SecurityGroupIngress[] = [{\n description: \"Ollama HTTP API. NOTE: restrict cidrBlocks to your own range in production.\",\n fromPort: 11434,\n toPort: 11434,\n protocol: \"tcp\",\n cidrBlocks: [\"0.0.0.0/0\"],\n}];\n\nif (allowSsh) {\n ingress.push({\n description: \"SSH\",\n fromPort: 22,\n toPort: 22,\n protocol: \"tcp\",\n cidrBlocks: [\"0.0.0.0/0\"],\n });\n}\n\nconst sg = new aws.ec2.SecurityGroup(\"ollama\", {\n description: \"Ollama inferencing access\",\n ingress,\n egress: [{\n description: \"Allow all outbound\",\n fromPort: 0,\n toPort: 0,\n protocol: \"-1\",\n cidrBlocks: [\"0.0.0.0/0\"],\n }],\n}, {\n provider,\n});\n\nconst server = new aws.ec2.Instance(\"ollama\", {\n ami: ubuntu.then(a => a.id),\n instanceType: \"g4dn.xlarge\", // 1x NVIDIA T4\n vpcSecurityGroupIds: [sg.id],\n associatePublicIpAddress: true,\n userData, // plain text; the AWS provider base64-encodes it for you\n rootBlockDevice: {\n volumeSize: 40,\n volumeType: \"gp3\",\n },\n tags: { Name: \"ollama\" },\n}, {\n provider,\n});\n\nexport const publicIp = server.publicIp;\nexport const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;\nexport const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;\nexport const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;\n\n```\n\n```typescript\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as gcp from \"@pulumi/gcp\";\nimport * as fs from \"fs\";\n\nconst cfg = new pulumi.Config();\nconst model = cfg.get(\"model\") ?? \"qwen2.5:14b\";\nconst allowSsh = cfg.getBoolean(\"allowSsh\") ?? false;\nconst project = cfg.get(\"project\");\nconst zone = cfg.get(\"zone\") ?? \"us-central1-a\";\n\n// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).\nconst userData = fs.readFileSync(\"cloud-init.yaml\", \"utf8\").replace(/__MODEL__/g, model);\n\n// Latest Ubuntu 24.04 LTS amd64 image.\nconst ubuntu = gcp.compute.getImage({\n family: \"ubuntu-2404-lts-amd64\",\n project: \"ubuntu-os-cloud\",\n});\n\n// Network tag binds the firewall rule to this instance.\nconst networkTag = \"ollama\";\n\nconst firewall = new gcp.compute.Firewall(\"ollama-fw\", {\n network: \"default\",\n project: project,\n // Inbound to Ollama from anywhere; restrict this CIDR for production.\n allows: allowSsh\n ? [{ protocol: \"tcp\", ports: [\"11434\"] }, { protocol: \"tcp\", ports: [\"22\"] }]\n : [{ protocol: \"tcp\", ports: [\"11434\"] }],\n sourceRanges: [\"0.0.0.0/0\"],\n targetTags: [networkTag],\n});\n\nconst instance = new gcp.compute.Instance(\"ollama\", {\n machineType: \"n1-standard-4\",\n zone: zone,\n project: project,\n tags: [networkTag],\n bootDisk: {\n initializeParams: {\n image: ubuntu.then(i => i.selfLink),\n size: 40,\n },\n },\n guestAccelerators: [{\n type: \"nvidia-tesla-t4\",\n count: 1,\n }],\n // GPUs cannot live-migrate, so host maintenance must terminate (and restart) the VM.\n scheduling: {\n onHostMaintenance: \"TERMINATE\",\n automaticRestart: true,\n },\n networkInterfaces: [{\n network: \"default\",\n accessConfigs: [{}], // an empty config requests an ephemeral public IP\n }],\n metadata: {\n \"user-data\": userData, // Ubuntu cloud-init reads this key, not startup-script\n },\n}, {\n dependsOn: firewall,\n});\n\nexport const publicIp = instance.networkInterfaces.apply(nics => nics[0].accessConfigs![0].natIp);\nexport const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;\nexport const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;\nexport const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;\n\n```\n\n```typescript\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as resources from \"@pulumi/azure-native/resources\";\nimport * as network from \"@pulumi/azure-native/network\";\nimport * as compute from \"@pulumi/azure-native/compute\";\nimport * as random from \"@pulumi/random\";\nimport * as fs from \"fs\";\n\nconst cfg = new pulumi.Config();\nconst model = cfg.get(\"model\") ?? \"qwen2.5:14b\";\nconst allowSsh = cfg.getBoolean(\"allowSsh\") ?? false;\nconst location = cfg.get(\"location\") ?? \"eastus\";\n\n// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).\nconst userData = fs.readFileSync(\"cloud-init.yaml\", \"utf8\").replace(/__MODEL__/g, model);\n\nconst resourceGroup = new resources.ResourceGroup(\"ollama-rg\", {\n location,\n});\n\nconst vnet = new network.VirtualNetwork(\"ollama-vnet\", {\n resourceGroupName: resourceGroup.name,\n addressSpace: { addressPrefixes: [\"10.0.0.0/16\"] },\n});\n\nconst subnet = new network.Subnet(\"ollama-subnet\", {\n resourceGroupName: resourceGroup.name,\n virtualNetworkName: vnet.name,\n addressPrefix: \"10.0.1.0/24\",\n});\n\n// Standard SKU public IPs use static allocation.\nconst publicIpAddress = new network.PublicIPAddress(\"ollama-pip\", {\n resourceGroupName: resourceGroup.name,\n sku: { name: network.PublicIPAddressSkuName.Standard },\n publicIPAllocationMethod: network.IPAllocationMethod.Static,\n});\n\n// Azure permits all outbound by default, so only inbound rules are needed.\nconst nsg = new network.NetworkSecurityGroup(\"ollama-nsg\", {\n resourceGroupName: resourceGroup.name,\n securityRules: [\n {\n name: \"allow-ollama\",\n priority: 1000,\n direction: network.SecurityRuleDirection.Inbound,\n access: network.SecurityRuleAccess.Allow,\n protocol: network.SecurityRuleProtocol.Tcp,\n sourcePortRange: \"*\",\n destinationPortRange: \"11434\",\n sourceAddressPrefix: \"0.0.0.0/0\", // prod: restrict to your client CIDR\n destinationAddressPrefix: \"*\",\n },\n ...(allowSsh ? [{\n name: \"allow-ssh\",\n priority: 1001,\n direction: network.SecurityRuleDirection.Inbound,\n access: network.SecurityRuleAccess.Allow,\n protocol: network.SecurityRuleProtocol.Tcp,\n sourcePortRange: \"*\",\n destinationPortRange: \"22\",\n sourceAddressPrefix: \"0.0.0.0/0\",\n destinationAddressPrefix: \"*\",\n }] : []),\n ],\n});\n\nconst nic = new network.NetworkInterface(\"ollama-nic\", {\n resourceGroupName: resourceGroup.name,\n networkSecurityGroup: { id: nsg.id },\n ipConfigurations: [{\n name: \"ipconfig1\",\n subnet: { id: subnet.id },\n publicIPAddress: { id: publicIpAddress.id },\n privateIPAllocationMethod: network.IPAllocationMethod.Dynamic,\n primary: true,\n }],\n});\n\n// Azure requires an admin credential even though we never log in. Generate one\n// instead of hard-coding it; it stays a Pulumi secret and is never exported.\nconst adminPassword = new random.RandomPassword(\"ollama-admin-password\", {\n length: 24,\n special: true,\n overrideSpecial: \"!#$%*\",\n minLower: 1,\n minUpper: 1,\n minNumeric: 1,\n minSpecial: 1, // Azure requires 3 of 4 character classes\n});\n\nconst vm = new compute.VirtualMachine(\"ollama-vm\", {\n resourceGroupName: resourceGroup.name,\n hardwareProfile: { vmSize: \"Standard_NC4as_T4_v3\" }, // 1x NVIDIA T4\n networkProfile: {\n networkInterfaces: [{ id: nic.id, primary: true }],\n },\n osProfile: {\n computerName: \"ollama\",\n adminUsername: \"azureuser\",\n adminPassword: adminPassword.result,\n customData: Buffer.from(userData).toString(\"base64\"), // Azure wants base64\n linuxConfiguration: {\n disablePasswordAuthentication: false,\n },\n },\n storageProfile: {\n imageReference: {\n publisher: \"Canonical\",\n offer: \"ubuntu-24_04-lts\",\n sku: \"server\", // Gen2; NC4as_T4_v3 is a Gen2 size\n version: \"latest\",\n },\n osDisk: {\n name: \"ollama-osdisk\",\n createOption: \"FromImage\",\n diskSizeGB: 40,\n managedDisk: { storageAccountType: \"StandardSSD_LRS\" },\n },\n },\n});\n\n// A Standard/Static public IP is reserved at creation, so its address is known\n// once the resource exists; no separate lookup needed.\nexport const publicIp = publicIpAddress.ipAddress.apply(ip => ip!);\nexport const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;\nexport const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;\nexport const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;\n\n```\n\nA few per-cloud details are worth calling out, since they are the places the “same program” abstraction leaks:\n\n- **AWS** is the shortest program, because the GPU comes with the instance shape: a `g4dn.xlarge` *is* a T4 box, so there is no separate accelerator to attach. The one thing to do before you deploy is raise the **Running On-Demand G and VT instances** vCPU quota in your region; a fresh account starts at zero, and `pulumi up` fails with `VcpuLimitExceeded` until you do.\n- **Google Cloud** attaches the GPU explicitly with `guestAccelerators`, and that brings the rule that trips people up: a GPU instance cannot live-migrate, so `scheduling.onHostMaintenance` must be `\"TERMINATE\"` or the apply is rejected. The cloud-init also has to ride on the `user-data` metadata key, not `startup-script`, and the empty `accessConfigs: [{}]` is what hands the box a public IP. T4 quota is also zero on a new project.\n- **Azure** is the longest listing, because the network is à la carte: the resource group, virtual network, subnet, public IP, security group, and NIC are each their own resource before you reach the VM. One detail surprises people: a Linux VM requires an admin credential even when you never log in, so the program generates a throwaway password with `random.RandomPassword` rather than committing one. The `NC4as_T4_v3` is a compute GPU, so the standard server (CUDA) driver from the cloud-init is the right choice here; the GRID driver is only needed for GPU-accelerated visualization workloads.\n\nThe full programs, all three `Pulumi..yaml` files, and the shared `cloud-init.yaml` are in the companion repo:\n\n[![GitHub repository: dirien/fully-automated-ai-inference-pulumi](https://opengraph.githubassets.com/1/dirien/fully-automated-ai-inference-pulumi)\n\ngithub.com/dirien/fully-automated-ai-inference-pulumi\n\n](https://github.com/dirien/fully-automated-ai-inference-pulumi)\n\n## Deploying\n\nCreate a project, install the provider for your cloud, point the stack at `pulumi-idp/auth`, and deploy. For AWS:\n\n```bash\nmkdir ai-inference && cd ai-inference\npulumi new typescript\nnpm install @pulumi/aws\n\n```\n\nDrop the AWS listing into `index.ts`, copy the `cloud-init.yaml` shown earlier into the same directory (or grab it from the companion repo), point the stack at the auth environment, and set your region:\n\n```bash\npulumi stack init aws\n# add `environment: [pulumi-idp/auth]` to Pulumi.aws.yaml (shown above)\npulumi config set region us-east-1\npulumi config set model qwen2.5:14b\npulumi up\n\n```\n\nThe other two clouds are the same flow with a different provider package and a couple of config keys: `npm install @pulumi/gcp` with `pulumi config set project ` and `pulumi config set zone us-central1-a`, or `npm install @pulumi/azure-native @pulumi/random` with `pulumi config set location eastus`.\n\nThe slow part is the GPU box: it boots, installs the driver, reboots, installs Ollama, and pulls the model, all without you. Depending on the instance, the region, and the model size, plan on roughly 10 to 15 minutes before the endpoint answers. When `pulumi up` finishes you get the endpoints straight back as stack outputs:\n\n```bash\nOutputs:\n generateEndpoint: \"http://:11434/api/generate\"\n ollamaEndpoint : \"http://:11434\"\n publicIp : \"\"\n tagsEndpoint : \"http://:11434/api/tags\"\n\n```\n\n## Testing the inference server\n\n`pulumi up` returns as soon as the infrastructure exists, which is before the model has finished downloading. This is exactly where Terraform reached for that `null_resource` loop, and where Pulumi hands you a URL instead. To check whether the model is ready, ask Ollama what it has loaded:\n\n```bash\ncurl -s $(pulumi stack output tagsEndpoint) | grep -q \"qwen2.5:14b\" && echo \"ready\" || echo \"still pulling\"\n\n```\n\nOnce it reports ready, send it a prompt. This is the same request the Akamai post makes, pointed at your `generateEndpoint` output:\n\n```bash\ncurl -s $(pulumi stack output generateEndpoint) -d '{\n \"model\": \"qwen2.5:14b\",\n \"system\": \"Answer every question with a three-line poem.\",\n \"prompt\": \"Why is the sky blue?\",\n \"stream\": false\n}'\n\n```\n\nThe first call is slower, because Ollama loads the model into GPU memory before it answers. Every call after that is fast, since `OLLAMA_KEEP_ALIVE=-1` keeps it resident:\n\n```json\n{\n \"model\": \"qwen2.5:14b\",\n \"response\": \"Sunlight scatters, short waves fly,\\nBlue light paints the open sky,\\nViolet fades as day drifts by.\",\n \"done\": true\n}\n\n```\n\nWhen you are done, take it all down with one command, so the GPU stops billing:\n\n```bash\npulumi destroy\n\n```\n\n## Cost\n\nA GPU instance is the whole bill, and you pay by the hour whether the model is busy or idle. The numbers below are rough on-demand rates for a single T4-class box left running 24/7; in practice you spin it up, use it, and `pulumi destroy` it, so what you actually pay tracks the hours it stays up.\n\nCloud\n\nInstance\n\nGPU\n\n~Hourly\n\n~Monthly (24/7)\n\nAWS\n\n`g4dn.xlarge`\n\n1× T4 (16 GB)\n\n~$0.53\n\n~$384\n\nAzure\n\n`Standard_NC4as_T4_v3`\n\n1× T4 (16 GB)\n\n~$0.53\n\n~$384\n\nGoogle Cloud\n\n`n1-standard-4` + 1× T4\n\n1× T4 (16 GB)\n\n~$0.54\n\n~$394\n\nThese are on-demand Linux rates in a cheap US region (`us-east-1`, `eastus`, `us-central1`) as of mid-2026, and the GPU dominates the bill. Spot or preemptible capacity cuts it sharply if your workload tolerates interruption (often 60 to 70 percent off), Google Cloud’s sustained-use discount trims an always-on instance on its own, and the 40 GB disk adds only a few dollars a month.\n\nA GPU box left running overnight is the expensive mistake here. Because the whole stack is declarative, the safe habit is cheap: `pulumi destroy` when you stop using it, `pulumi up` when you need it back. The state and config are version-controlled, so standing it up again is one command, not a rebuild.\n\n## Security considerations\n\nThe architecture in this post matches the Akamai original on purpose, which means it carries the same caveat: Ollama is exposed over plain HTTP on a port open to the entire internet. That is fine for a demo on a box you tear down the same day. It is not fine for anything that outlives the afternoon, and self-hosted AI endpoints get found fast: scanners like [Shodan](https://www.shodan.io/) enumerate a freshly exposed one within hours, and an open Ollama instance is free compute for whoever finds it first.\n\nThe credential side, though, is genuinely better than a static-token setup, and that is the part worth keeping. There is no long-lived cloud key in the program, in your shell, or in CI; every deploy gets short-lived credentials minted through `pulumi-idp/auth` and thrown away when it finishes.\n\nConcern\n\nAkamai/Terraform demo\n\nThis deployment\n\nCloud credentials\n\nStatic PAT in an env var\n\nOIDC login, short-lived, via `pulumi-idp/auth`\n\nInbound exposure\n\nPort 11434 open to `0.0.0.0/0`\n\nSame by default; one config flag scopes the CIDR\n\nTransport\n\nPlain HTTP\n\nPlain HTTP (front with TLS for real use)\n\nReadiness wait\n\n`null_resource` + `local-exec` shell loop\n\nA runtime `curl`, no resource\n\nMy recommendations for taking this past a demo:\n\n- Scope the inbound rule to your own CIDR instead of `0.0.0.0/0`; the `allowSsh` flag in the program is the pattern to copy for the Ollama port\n- Put a reverse proxy with TLS in front of Ollama, or keep the box off the public internet entirely and reach it over a private network or a [Tailscale tailnet](https://www.pulumi.com/blog/deploy-a-hermes-agent-with-pulumi/), the way I did for the Hermes agent\n- Keep credentials on OIDC through ESC; never fall back to a static key to “just get it working”\n- Treat the box as disposable, and `pulumi destroy` it when you are not using it, which shrinks both the bill and the attack window\n\n## What’s next?\n\nThe program is a foundation, and the interesting work is what you layer on once a model is a `pulumi up` away:\n\n- **Lock it down.** Scope the firewall, add TLS, or move the box behind a private network so the endpoint is not on the public internet at all.\n- **Scale the model to the GPU.** `qwen2.5:14b` on a T4 is the entry point. Bigger models want more memory, which means an A10G, an L4, or an A100, and the only change in the program is the instance type and the `model` value.\n- **Swap the serving engine.** Ollama is the simplest thing that works. For higher throughput, the same shape holds with [vLLM](https://github.com/vllm-project/vllm) in place of Ollama in the cloud-init.\n- **Generate the next one.** [Pulumi Neo](https://www.pulumi.com/product/neo/) can take a target like “a GPU inference box on Azure behind a private endpoint” and produce a first draft of the program, which you then review in a PR like any other change.\n\n## Conclusion\n\nDeclaring an AI inference server as code buys you the same thing it buys for any other infrastructure: you can reproduce it on any of the three clouds, version-control it, and tear it down with a single `pulumi destroy`. Porting the Akamai project made the contrast sharp. The credentials moved from a static token to an OIDC login that leaves nothing behind, and the readiness wait disappeared entirely once you stop treating a runtime check as a resource.\n\nThat is the line worth carrying to the next thing you deploy. Not every step in a runbook is a resource. A GPU box and a firewall rule are; waiting for a download to finish is not. Draw that line first, and the program gets shorter on its own.\n\nIf you run into issues or have questions, drop by the [Pulumi Community Slack](https://slack.pulumi.com/) or [GitHub Discussions](https://github.com/pulumi/pulumi/discussions). New to Pulumi? [Get started here](https://www.pulumi.com/docs/get-started/).","publishedAt":"2026-06-30T00:00:00.000Z","fetchedAt":"2026-06-30T13:01:14.379Z","url":"https://www.pulumi.com/blog/fully-automated-ai-inference-aws-azure-gcp-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/blog/fully-automated-ai-inference-aws-azure-gcp-pulumi/meta.png","r2Key":"releases/42e0632d3c251f96d5f83e2c51905b5b68d270a4346417479fdd4fa953ff360f.png","r2Url":"https://media.releases.sh/releases/42e0632d3c251f96d5f83e2c51905b5b68d270a4346417479fdd4fa953ff360f.png"},{"type":"image","url":"https://opengraph.githubassets.com/1/dirien/fully-automated-ai-inference-pulumi","alt":"GitHub repository: dirien/fully-automated-ai-inference-pulumi","r2Key":"releases/8adb904797283a71b969ac6ebe5f7ad12da318c08afd2612252603438b60a722.png","r2Url":"https://media.releases.sh/releases/8adb904797283a71b969ac6ebe5f7ad12da318c08afd2612252603438b60a722.png"}],"coverageCount":0},{"id":"rel_xxHQVxhu8DcXSPvEhkgHT","version":null,"type":"feature","title":"Introducing ESC Secret Rotation Webhooks","summary":"Pulumi ESC now supports webhooks that trigger when an environment’s secrets are rotated, notifying on success or failure. Configure them via the Pulumi Cloud Console, the Pulumi Service Provider, or the CLI.","titleGenerated":"Pulumi ESC introduces webhooks for secret rotation completion","titleShort":"Secret rotation webhooks notify on success or failure","breaking":"none","importance":null,"content":"![](https://www.pulumi.com/blog/introducing-esc-secret-rotation-webhooks/meta.png)\n\n[Pulumi ESC](https://www.pulumi.com/docs/esc/) centralizes your secrets and configuration, and it can [automatically rotate secrets](https://www.pulumi.com/docs/esc/concepts/rotators/) on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on it know it happened. ESC secret rotation webhooks close that gap by notifying you the moment a secret rotates.\n\n## Introducing secret rotation webhooks\n\nWith [ESC webhooks](https://www.pulumi.com/docs/esc/concepts/webhooks/), you can react to rotations automatically. When ESC rotates an environment’s secrets, a webhook can be configured to trigger on either success or failure. Use it to notify your team in Slack, refresh services that hold the old credential, or catch a failed rotation before it causes an outage.\n\n## How to configure\n\n### Pulumi Cloud Console\n\nUsing the Pulumi Cloud Console, you can now configure webhooks for “Environment rotation succeeded” and “Environment rotation failed” in your ESC Environment’s Settings page (under **Settings** -> **Notifications**).\n\n![ESC webhook trigger settings with “Environment rotation succeeded” and “Environment rotation failed” selected](./rotation-webhook-triggers.png)\n\n### Pulumi Service Provider\n\nYou can use the Pulumi Service Provider in your Pulumi program to configure webhooks. Here is an example in TypeScript:\n\n```typescript\nconst environmentWebhook = new service.Webhook(\"env-webhook\", {\n active: true,\n displayName: \"env-webhook\",\n organizationName: \"my-org\",\n projectName: environment.project,\n environmentName: environment.name,\n payloadUrl: \"https://example.com\",\n filters: [WebhookFilters.EnvironmentRotationSucceeded, WebhookFilters.EnvironmentRotationFailed],\n})\n\n```\n\n### Pulumi CLI\n\nYou can also use the Pulumi CLI to configure the webhook:\n\n```\npulumi env webhook new my-org/project/env env-webhook \\\n--url https://example.com \\\n--event environment_rotation_succeeded \\\n--event environment_rotation_failed\n```\n\n## Get started\n\nSecret rotation webhooks are available now for all Pulumi ESC environments. See the [webhooks documentation](https://www.pulumi.com/docs/esc/concepts/webhooks/) to get started, and share your feedback on our [GitHub repository](https://github.com/pulumi/esc).","publishedAt":"2026-06-26T00:00:00.000Z","fetchedAt":"2026-06-26T18:00:56.602Z","url":"https://www.pulumi.com/blog/introducing-esc-secret-rotation-webhooks/","media":[{"type":"image","url":"https://www.pulumi.com/blog/introducing-esc-secret-rotation-webhooks/meta.png","r2Key":"releases/6327df9addd20501f5fc6fc139f5210235eb8548dd94f165c09c1040fa385ec2.png","r2Url":"https://media.releases.sh/releases/6327df9addd20501f5fc6fc139f5210235eb8548dd94f165c09c1040fa385ec2.png"}],"coverageCount":0},{"id":"rel_Uh3IhexIK55Ya2RqSgzbP","version":null,"type":"feature","title":"Build a Governed Databricks Workspace with Pulumi","summary":"New guide covers provisioning a governed Databricks workspace baseline with Pulumi, including cluster policies, notebooks, secret scopes, permissions, and automated jobs.","titleGenerated":"Pulumi publishes guide to building governed Databricks workspaces","titleShort":"Governed Databricks workspace guide for platform teams","breaking":"none","importance":null,"content":"![](https://www.pulumi.com/blog/end-to-end-databricks-with-pulumi/meta.png)\n\nPlatform teams responsible for [Databricks](https://www.databricks.com/) often find themselves manually configuring clusters and notebooks for every new data science team. This manual overhead leads to inconsistent cluster policies, runaway costs from oversized instances, and security gaps in workspace operations. Without a standardized way to provision workspace-local resources, data platforms become a fragmented collection of bespoke environments that are impossible to govern at scale.\n\nAs Databricks usage grows across the enterprise, the lack of a governed workspace baseline becomes a major operational risk. Inconsistent policies lead to unpredictable billing and audit failures. Standardizing your Databricks environment with Pulumi ensures that every workspace starts with the correct cost controls, cluster policies, notebooks, and automated jobs, allowing your data teams to move faster without compromising governance.\n\n## What you’ll build\n\nIn this post, you will learn how to provision a governed Databricks workspace baseline using Pulumi. You will build:\n\n1. **Cluster policies** to enforce instance types and cost controls.\n2. **Workspace notebooks** to standardize workload locations.\n3. **Secret scopes and permissions** to make access reviewable.\n4. **Automated jobs** that run on policy-constrained compute.\n\nBy the end, you will have a reproducible workspace configuration that you can deploy to any new Databricks environment.\n\n## The Databricks management boundary\n\nWhen managing Databricks with Pulumi, understand the boundary between account-level and workspace-level resources.\n\n1. **Account-level**: Creating cloud prerequisites such as VPCs, subnets, IAM roles, and Azure resource groups uses the cloud provider for your target platform. On AWS and GCP, Databricks workspace creation and account-level identity use the Databricks provider’s account APIs, such as `databricks.MwsWorkspaces`; on Azure, the workspace itself is commonly managed with `azure-native`.\n2. **Workspace-level**: Managing clusters, jobs, notebooks, permissions, and secret scopes within a specific workspace. This example uses the `@pulumi/databricks` provider against an Azure Databricks workspace URL, and the same workspace-resource pattern applies once your provider is configured for the target workspace.\n\nFor this tutorial, we’ll assume you have an existing Databricks workspace and want to manage the resources within it.\n\n## Configuring credentials with Pulumi ESC\n\nBefore writing code, we need to configure our credentials. [Pulumi ESC](https://www.pulumi.com/docs/esc/) (Environments, Secrets, and Configuration) manages these securely.\n\nYou can create an environment that maps Databricks credentials into Pulumi configuration for the Databricks provider:\n\n```yaml\nvalues:\n databricks:\n host: \"https://adb-123456789.0.azuredatabricks.net\"\n token:\n fn::secret: databricks-token\n pulumiConfig:\n databricks:host: ${databricks.host}\n databricks:token: ${databricks.token}\n\n```\n\nOnce configured, import this environment into your Pulumi stack. The Databricks provider reads configuration values such as [`databricks:host` and `databricks:token`](https://www.pulumi.com/registry/packages/databricks/installation-configuration/) without requiring static secrets in stack config.\n\n## Defining your data infrastructure\n\nThe following Pulumi program in TypeScript sets up separate cluster policies for interactive and job compute, a governed shared cluster, a secret scope, explicit permissions, a notebook, and a scheduled job that runs on policy-constrained compute.\n\n```typescript\nimport * as databricks from \"@pulumi/databricks\";\n\nconst interactivePolicy = new databricks.ClusterPolicy(\"interactive-fair-use\", {\n name: \"Interactive Fair Use Policy\",\n definition: JSON.stringify({\n \"dbus_per_hour\": {\n \"type\": \"range\",\n \"maxValue\": 10,\n },\n \"autotermination_minutes\": {\n \"type\": \"fixed\",\n \"value\": 20,\n \"hidden\": true,\n },\n }),\n});\n\nconst jobPolicy = new databricks.ClusterPolicy(\"job-fair-use\", {\n name: \"Job Fair Use Policy\",\n definition: JSON.stringify({\n \"dbus_per_hour\": {\n \"type\": \"range\",\n \"maxValue\": 10,\n },\n }),\n});\n\nconst sharedCluster = new databricks.Cluster(\"shared-cluster\", {\n clusterName: \"Shared Engineering Cluster\",\n sparkVersion: \"17.3.x-scala2.13\",\n nodeTypeId: \"Standard_DS3_v2\",\n autoterminationMinutes: 20,\n numWorkers: 2,\n policyId: interactivePolicy.id,\n});\n\nconst clusterPermissions = new databricks.Permissions(\"shared-cluster-permissions\", {\n clusterId: sharedCluster.id,\n accessControls: [{\n groupName: \"data-engineers\",\n permissionLevel: \"CAN_RESTART\",\n }, {\n groupName: \"analysts\",\n permissionLevel: \"CAN_ATTACH_TO\",\n }],\n});\n\nconst secretScope = new databricks.SecretScope(\"etl-secrets\", {\n name: \"etl-secrets\",\n});\n\nconst secretScopeAcl = new databricks.SecretAcl(\"etl-secrets-readers\", {\n scope: secretScope.name,\n principal: \"data-engineers\",\n permission: \"READ\",\n});\n\nconst etlNotebook = new databricks.Notebook(\"etl-notebook\", {\n path: \"/Shared/ETL/NightlyProcess\",\n language: \"PYTHON\",\n contentBase64: Buffer.from(\"print('Running ETL process...')\").toString(\"base64\"),\n});\n\nconst job = new databricks.Job(\"nightly-etl\", {\n name: \"Nightly ETL Job\",\n tasks: [{\n taskKey: \"etl-task\",\n newCluster: {\n numWorkers: 2,\n sparkVersion: \"17.3.x-scala2.13\",\n nodeTypeId: \"Standard_DS3_v2\",\n policyId: jobPolicy.id,\n },\n notebookTask: {\n notebookPath: etlNotebook.path,\n },\n }],\n schedule: {\n quartzCronExpression: \"0 0 2 * * ?\",\n timezoneId: \"UTC\",\n },\n});\n\n```\n\nThis baseline covers the resources a platform team needs to standardize first:\n\n1. **Interactive cluster policy**: caps DBU consumption and enforces auto-termination for shared interactive compute.\n2. **Job cluster policy**: caps DBU consumption for ephemeral job compute without applying interactive auto-termination settings.\n3. **Shared cluster**: gives teams a governed interactive compute target.\n4. **Secret scope and ACL**: makes ETL secret access reviewable.\n5. **Cluster permissions**: assigns group-level access to the shared cluster.\n6. **Notebook**: stores the workload artifact in the workspace.\n7. **Job**: schedules the notebook on policy-constrained compute.\n\n## Validation\n\nAfter running `pulumi up`, you can validate your Databricks baseline:\n\n1. **Databricks UI**: Navigate to the “Compute” section and verify that the interactive and job fair-use policies exist, with auto-termination fixed only on the interactive policy.\n2. **Cluster check**: Confirm that the shared cluster references the interactive policy and uses the expected node type.\n3. **Permission check**: Confirm that cluster and secret-scope permissions match the intended Databricks groups.\n4. **Notebook check**: Confirm that `/Shared/ETL/NightlyProcess` exists in the workspace.\n5. **Job check**: Go to the “Workflows” section and confirm that the “Nightly ETL Job” is scheduled and references the notebook.\n\nManaging your Databricks workspace as code gives every team a governed, cost-aware baseline. Use Pulumi stacks to deploy the same cluster policies, permissions, secret scope, notebook, and job pattern to multiple workspaces with environment-specific configuration.\n\n```bash\n# Deploy to development\npulumi stack select dev\npulumi up\n\n# Promote to production\npulumi stack select prod\npulumi up\n\n```\n\nThis keeps production ETL jobs, cluster policies, secret scopes, and permission assignments aligned with development while still letting each stack bind to its own Databricks workspace and ESC environment.\n\n## Conclusion\n\nNext, connect this workspace baseline to your CI/CD pipeline and promote it through Pulumi stacks so Databricks jobs, cluster policies, and permissions move through the same review path as application code. Start with the [Databricks provider docs](https://www.pulumi.com/registry/packages/databricks/) and [Pulumi ESC](https://www.pulumi.com/docs/esc/) for credential handling.","publishedAt":"2026-06-25T00:00:00.000Z","fetchedAt":"2026-06-25T02:01:16.960Z","url":"https://www.pulumi.com/blog/end-to-end-databricks-with-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/blog/end-to-end-databricks-with-pulumi/meta.png","r2Key":"releases/d1690fcb87c4a301c1cc7e8f741a24ca6118fd91f3df56e6abdc931e527fb95c.png","r2Url":"https://media.releases.sh/releases/d1690fcb87c4a301c1cc7e8f741a24ca6118fd91f3df56e6abdc931e527fb95c.png"}],"coverageCount":0},{"id":"rel_TQhWtRV11XSTrsdZ8yY7m","version":null,"type":"feature","title":"Deploy a Private Hermes Agent on Render Securely with Pulumi, Modal, and Tailscale","summary":"![](https://www.pulumi.com/blog/deploy-a-hermes-agent-with-pulumi/meta.png)\n\nPersonal AI agents had their breakout this year. [OpenClaw](https://www.p...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/deploy-a-hermes-agent-with-pulumi/meta.png)\n\nPersonal AI agents had their breakout this year. [OpenClaw](https://www.pulumi.com/blog/deploy-openclaw-aws-hetzner/) crossed 100,000 GitHub stars within months of launching, and self-hosting your own assistant went from a hobbyist trick to something a lot of developers actually do. I wrote up how to deploy that lobster to AWS or Hetzner back when it was everywhere.\n\nThe one people are switching to now is [Hermes](https://hermes-agent.nousresearch.com/), the open-source runtime from [Nous Research](https://nousresearch.com/), and it caught on just as quickly. The reason shows up in every “I ditched OpenClaw for Hermes” thread: it actually learns, building up memory and writing its own skills as it goes instead of running off a static, human-written list.\n\nHere is the part the launch videos skip. Hermes writes and runs its own code, with no human approving the commands. A model that can write code will eventually write a bad one, and the only thing between that command and your credentials is the sandbox it runs in. That is the box you do not want on the public internet. Researchers found [175,000 exposed Ollama servers](https://thehackernews.com/2026/01/researchers-find-175000-publicly.html) sitting open in early 2026, and attackers hijack the ones they find for compute. The fix is not a better lock on the front door. It is to have no front door at all.\n\nSo this post deploys a private Hermes agent as one Pulumi program across Render, Modal, and Tailscale. The agent and its chat UI run as Render private services with no public URL, Tailscale puts the UI on your tailnet, and Modal runs the agent’s code in throwaway sandboxes. One `pulumi up` to stand it up, one `pulumi destroy` to tear it down, around $50 a month. No Makefile, no CLI escape hatches, and an honest look at the few places “nothing on the public internet” still leaks.\n\n## What is Hermes?\n\nHermes is the open-source, MIT-licensed agent runtime from [Nous Research](https://hermes-agent.nousresearch.com/hermes-agent). It runs continuously on a server rather than living in a browser tab, and you talk to it through a chat UI or a messaging platform like Telegram, Discord, Slack, or Signal. A few things make it more than a chatbot:\n\n- **It is model-agnostic.** You point it at any provider. This deployment uses [OpenRouter](https://openrouter.ai/), one key that fronts [400-plus models](https://openrouter.ai/docs/guides/overview/models) across providers, with automatic failover when one is down.\n- **It remembers across restarts.** Memory persists on disk, so it builds up context over time instead of resetting every session.\n- **It writes its own skills.** When it works through a task, it can save that approach as a reusable skill and reach for it next time.\n- **It schedules itself.** A built-in [cron](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron) runs automations on a schedule, driven in plain language.\n- **It runs code in a sandbox.** When the agent needs to execute code, it hands that off to an isolated, ephemeral container instead of running it next to its own process.\n\nThe difference from a cloud-hosted assistant is the usual self-hosting trade: it runs on your infrastructure with your keys, and your conversation history and memory stay on your disk.\n\n“Hermes” here is the agent runtime from Nous Research, not the Hermes family of language models that share the name. The agent is model-agnostic, and the model it talks to is a separate choice you make through OpenRouter.\n\n## Prerequisites\n\nBefore getting started, ensure you have:\n\n- [Pulumi CLI](https://www.pulumi.com/docs/iac/download-install/) installed and configured\n- A [Pulumi Cloud account](https://app.pulumi.com/signup)\n- A [Render](https://render.com/) account, an API key, and your workspace owner ID\n- A [Modal](https://modal.com/) account and a token pair (token ID and secret)\n- An [OpenRouter](https://openrouter.ai/) API key with credit on the account\n- A container registry you can push to; this post uses GitHub Container Registry (a GHCR username and token)\n- Docker running locally (the image build rides on a local buildx engine), or a Docker-enabled CI runner\n- A [Tailscale](https://tailscale.com/) account with [HTTPS enabled](https://tailscale.com/kb/1153/enabling-https) and a reusable auth key\n- Node.js 18+ (for TypeScript) or Python 3.9+ (for Python), depending on the language you pick\n\nThis guide routes models through OpenRouter, but Hermes works with other providers too. The model is just a routing string you pass (`gpt-5.5` here), so any model OpenRouter supports works by changing that one value.\n\n## Understanding the Hermes architecture\n\nStrip away the dashboard clicks and the architecture is four pieces. One rule governs all of them: what the public internet is allowed to touch.\n\n```\nflowchart LR\nUser([Your devices]) -->|\"tailnet (WireGuard)\"| TS[\"Tailscale
private mesh\"]\nTS -->|\"open-webui..ts.net\"| WebUI[\"Open WebUI
(Render private service,
joined to your tailnet)\"]\nWebUI -->|\"private network
:8642\"| Hermes[\"Hermes gateway
(Render private service)\"]\nHermes -->|\"Modal SDK at runtime\"| Modal[\"Modal sandbox
isolated code execution\"]\nHermes -->|model calls| OR[\"OpenRouter\"]\n```\n\nComponent\n\nPort\n\nDescription\n\nHermes gateway\n\n8642\n\nHolds secrets and memory, talks to the model, creates Modal sandboxes. The most dangerous box, so it has no public URL.\n\n[Open WebUI](https://github.com/open-webui/open-webui)\n\n8080\n\nThe chat front end. Joins your tailnet and reaches Hermes over Render’s private network.\n\nModal sandbox\n\n\\-\n\nIsolated, ephemeral container for running the agent’s code.\n\nTailscale\n\n\\-\n\nA private [WireGuard mesh](https://tailscale.com/blog/how-tailscale-works) that makes the UI reachable to your devices only.\n\nThe agent that can run code and read secrets is never routable from the internet, and neither is the UI in front of it. There is no inbound ingress on any box (the outbound calls to the model, to Modal, and to the image registry still cross the internet, as they have to). Expressing “which box can reach which” in code is what makes the boundary auditable: the rule lives in the program rather than in a dashboard.\n\nThe four pieces split cleanly in two: two you declare as resources, and two you hand a credential and let run.\n\nLayer\n\nHow you provision it\n\nStatus\n\nRender services, disks, secrets\n\nofficial `render-oss` Terraform provider, bridged\n\nDeclarative, via one `pulumi package add`.\n\nContainer images\n\n`@pulumi/docker-build`\n\nBuilt and pushed during `pulumi up`. No `docker` CLI.\n\nModal sandboxes\n\nnothing\n\nNo Terraform provider exists. A runtime credential.\n\nTailnet access (Tailscale)\n\nnothing\n\nNo provider needed. A runtime credential, like Modal.\n\nTwo of these four layers are credentials, not resources. That distinction often gets missed, and it is worth getting right: a provider can only manage what it can provision, and spinning up a Modal sandbox is a runtime act, not a provisioned resource. We come back to it at each layer.\n\n## Setting up ESC for secrets management\n\nDeploying Hermes means handling a pile of credentials: a Render API key, registry credentials, the OpenRouter key, the Modal token pair, and the Tailscale auth key. You don’t want these hardcoded or scattered across environment variables. [Pulumi ESC (Environments, Secrets, and Configuration)](https://www.pulumi.com/docs/esc/) stores them securely and passes them directly to your Pulumi program.\n\nCreate a new ESC environment:\n\n```bash\npulumi env init /hermes-secrets\n\n```\n\nAdd your secrets to the environment:\n\n```yaml\nvalues:\n renderApiKey:\n fn::secret: \"rnd_xxxxx\"\n renderOwnerId: \"tea-xxxxx\"\n ghcrUser: \"your-github-username\"\n ghcrToken:\n fn::secret: \"ghp_xxxxx\"\n openrouterApiKey:\n fn::secret: \"sk-or-xxxxx\"\n modalTokenId:\n fn::secret: \"ak-xxxxx\"\n modalTokenSecret:\n fn::secret: \"as-xxxxx\"\n tailscaleAuthKey:\n fn::secret: \"tskey-auth-xxxxx\"\n tailnetDnsName: \"tailxxxxx.ts.net\"\n pulumiConfig:\n renderApiKey: ${renderApiKey}\n ownerId: ${renderOwnerId}\n ghcrUser: ${ghcrUser}\n ghcrToken: ${ghcrToken}\n openrouterApiKey: ${openrouterApiKey}\n modalTokenId: ${modalTokenId}\n modalTokenSecret: ${modalTokenSecret}\n tailscaleAuthKey: ${tailscaleAuthKey}\n tailnetDnsName: ${tailnetDnsName}\n\n```\n\nTo find your tailnet DNS name, go to the [Tailscale admin console](https://login.tailscale.com/admin/dns), look under the **DNS** section, and find your tailnet name (e.g., `tailxxxxx.ts.net`). This is the domain suffix used for all machines in your Tailscale network.\n\nThen create a `Pulumi.dev.yaml` file in your project to reference the environment:\n\n```yaml\nenvironment:\n - /hermes-secrets\n\n```\n\nThis keeps your secrets out of your codebase and hands them to the program at deploy time. The Modal token pair and the Tailscale auth key never become resources; they ride straight through as encrypted env vars on the services that need them.\n\n## Generating the Render SDK\n\nRender has no first-party Pulumi provider. What it has is an official, maintained [Terraform provider](https://github.com/render-oss/terraform-provider-render), and Pulumi can turn any Terraform provider into a typed local SDK with [Any Terraform Provider](https://www.pulumi.com/docs/iac/concepts/providers/any-terraform-provider/):\n\n```bash\npulumi package add terraform-provider render-oss/render 1.8.0\n\n```\n\nThat one command generates a `render` SDK you import like any other package, in whatever language your stack is written in. There is no published `@pulumi/render` package and no vendor to wait on.\n\nThis is also where the provider map shows its edges. The bridge wraps a Terraform provider that already exists, so it works for Render. But Modal has no Terraform provider anywhere, so `pulumi package add terraform-provider modal-labs/modal` has nothing to fetch. That is not a gap to work around. Modal is not a provisioned resource here; Hermes creates sandboxes at runtime through the Modal SDK, and Pulumi’s only job is to hold the token pair and hand it over. Tailscale lands in the same bucket: a Tailscale provider exists, but it manages your tailnet’s settings, not the act of putting a container on the network, which is a runtime job done inside the image.\n\n## Securing with Tailscale\n\nThe usual way to make a self-hosted UI reachable is to give it a public hostname and put an identity gate in front: an SSO provider, an access policy, a public DNS record, and a certificate to keep renewing. Tailscale collapses all of it into nothing you declare. There is no gate to bolt in front of a public URL, because there is no public URL. Open WebUI joins your tailnet and answers only to your own devices.\n\nThis is a stronger position than a public UI behind a login. Because there is no public URL, there is no login to harden and no certificate to renew, and Open WebUI answers only to your own devices.\n\nTailscale lives in the Open WebUI image rather than the Pulumi program. The image adds Tailscale and an entrypoint that brings up `tailscaled` in [userspace mode](https://tailscale.com/kb/1112/userspace-networking) (a container has no `/dev/net/tun`), joins your tailnet, and runs [`tailscale serve`](https://tailscale.com/kb/1312/serve) to expose Open WebUI on it. `serve` publishes over HTTPS to authenticated members of your tailnet only, where its sibling [`tailscale funnel`](https://tailscale.com/kb/1223/funnel) would put the same port on the public internet, the one thing this design avoids.\n\n```dockerfile\nFROM ghcr.io/open-webui/open-webui:main-slim\nRUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates \\\n && curl -fsSL https://tailscale.com/install.sh | sh\nCOPY entrypoint.sh /usr/local/bin/ts-entrypoint\nENTRYPOINT [\"/usr/local/bin/ts-entrypoint\"]\n\n```\n\n```bash\n#!/usr/bin/env bash\nset -e\nPORT=\"${PORT:-8080}\"\nmkdir -p /app/backend/data/tailscale\n# Userspace networking: a container has no /dev/net/tun. Keep node state on the disk\n# so it survives restarts, and accept-dns=false so Render's DNS still resolves the\n# private Hermes hostname.\ntailscaled --tun=userspace-networking --statedir=/app/backend/data/tailscale &\nn=0\nuntil tailscale up --authkey=\"${TS_AUTHKEY}\" --hostname=\"${TS_HOSTNAME}\" --accept-dns=false; do\n n=$((n + 1)); [ \"${n}\" -ge 30 ] && { echo \"tailnet join failed; check TS_AUTHKEY\"; exit 1; }\n sleep 2\ndone\ntailscale serve --bg \"${PORT}\" # serve Open WebUI on the tailnet over HTTPS\ncd /app/backend && exec bash start.sh\n\n```\n\nThe `TS_AUTHKEY` env var on the service, pulled from ESC, is the only thing Pulumi contributes; everything else is the image doing its own networking.\n\nThere is one prerequisite, the same one any Tailscale node needs for `serve`: enable HTTPS for your tailnet once in the admin console so it can get a certificate. Use a **reusable** auth key, since the service re-authenticates on every redeploy, and the join loop has a ceiling so a dead key fails the deploy in a minute instead of hanging it.\n\nTo generate the reusable auth key:\n\n1. Go to the [Tailscale admin console](https://login.tailscale.com/admin/settings/keys).\n2. Click **Generate auth key**.\n3. Enable **Reusable**, since the service re-authenticates on every redeploy.\n4. Copy the key into your ESC environment as `tailscaleAuthKey`.\n\n## Deploying the agent\n\nThis is the part a Makefile usually handles. Two private services, two disks, every secret an encrypted env var, and both images built and pushed during the same `pulumi up` that creates the services. No CLI runs anywhere, though the build still rides on a local Docker engine through [buildx](https://docs.docker.com/build/concepts/overview/): the `docker` call is gone, the daemon it talks to is not, so `pulumi up` needs Docker running.\n\nCreate a new Pulumi project (pick the language you prefer; the companion repo has all three):\n\n```bash\nmkdir hermes-agent-pulumi && cd hermes-agent-pulumi\npulumi new typescript\n\n```\n\nInstall the dependencies and generate the Render SDK:\n\n```bash\nnpm install @pulumi/docker-build @pulumi/random\npulumi package add terraform-provider render-oss/render 1.8.0\n\n```\n\nBoth services need the 2 GB Standard plan. The gateway and Open WebUI each exhaust memory on the 512 MB Starter and OOM on boot.\n\nTwo facts make this clean. Render env var values are encrypted at rest, so a secret is only an env var, with no separate resource. And [`@pulumi/docker-build`](https://www.pulumi.com/registry/packages/docker-build/) builds and pushes an image through an embedded buildx during `pulumi up`, so the image pipeline is declarative too. Render then pulls the pushed image by digest.\n\n### The complete program\n\nHermes comes first: a private Render service with no public URL, a disk for its memory, and every secret as an encrypted env var. The shared bearer key is generated in state with [`random.RandomBytes`](https://www.pulumi.com/registry/packages/random/api-docs/randombytes/), the clean replacement for `openssl rand -base64 32`; the Modal token pair and the OpenRouter key come from [config](https://www.pulumi.com/docs/iac/concepts/config/) or [Pulumi ESC](https://www.pulumi.com/docs/esc/). Render has no port field, so Hermes binds `0.0.0.0:8642` and Open WebUI reaches it at the service’s read-only `slug`. Open WebUI is almost the mirror image, private too, except its image joins your tailnet (the `tailscaled` entrypoint from the previous section) and it carries the operational env vars that keep it lean: no local embedding models, and `ENABLE_PERSISTENT_CONFIG=false` so your config always wins over a stale copy in its database. One [`render.Provider`](https://www.pulumi.com/docs/iac/concepts/resources/providers/) carries your `renderApiKey` and `ownerId` into every Render resource.\n\nHere is the whole program, copy-paste ready as your `index.ts` (or `__main__.py`, or `Pulumi.yaml`):\n\n```typescript\nimport * as pulumi from \"@pulumi/pulumi\";\nimport * as dockerbuild from \"@pulumi/docker-build\";\nimport * as random from \"@pulumi/random\";\n// Local SDK generated by: pulumi package add terraform-provider render-oss/render 1.8.0\n// (no @pulumi/render is published; the SDK is bridged from the official Render provider).\nimport * as render from \"@pulumi/render\";\n\nconst cfg = new pulumi.Config();\n\n// ---------------------------------------------------------------------------\n// Configuration. Non-secret values via `pulumi config set`, secrets via\n// `pulumi config set --secret` or a Pulumi ESC environment (see README).\n// The Render provider reads renderApiKey/renderOwnerId (or RENDER_API_KEY/RENDER_OWNER_ID).\n// ---------------------------------------------------------------------------\nconst region = cfg.get(\"renderRegion\") ?? \"oregon\";\nconst modelDefault = cfg.get(\"modelDefault\") ?? \"gpt-5.5\";\n\n// Container registry the images are pushed to and Render pulls from (GHCR here).\nconst ghcrUser = cfg.require(\"ghcrUser\");\nconst ghcrToken = cfg.requireSecret(\"ghcrToken\"); // GHCR PAT with write:packages\n\n// Long-lived secrets supplied by you (dashboard-minted). Hold in config or ESC.\nconst modalTokenId = cfg.requireSecret(\"modalTokenId\");\nconst modalTokenSecret = cfg.requireSecret(\"modalTokenSecret\");\nconst openrouterApiKey = cfg.requireSecret(\"openrouterApiKey\");\n\n// Tailscale: the only \"gateway\". Open WebUI joins your tailnet and is reachable\n// at https://..ts.net by your devices only — never public.\n// Both values are already in your ESC. Enable HTTPS once in the Tailscale admin console.\nconst tailscaleAuthKey = cfg.requireSecret(\"tailscaleAuthKey\");\nconst tailnetDnsName = cfg.require(\"tailnetDnsName\"); // e.g. tailc6fb4e.ts.net\nconst webuiHostname = \"open-webui\";\nconst webuiTailnetUrl = `https://${webuiHostname}.${tailnetDnsName}`;\n\n// Render provider auth (from ESC: pulumiConfig.renderApiKey / pulumiConfig.renderOwnerId).\nconst renderProvider = new render.Provider(\"render\", {\n apiKey: cfg.requireSecret(\"renderApiKey\"),\n ownerId: cfg.require(\"renderOwnerId\"),\n});\n\n// ---------------------------------------------------------------------------\n// Secrets generated in state (the in-IaC replacement for `openssl rand -base64 32`).\n// The shared bearer authenticates Open WebUI -> Hermes; it lands on both services.\n// ---------------------------------------------------------------------------\nconst sharedKey = new random.RandomBytes(\"hermes-shared-key\", { length: 32 });\nconst webuiSecretKey = new random.RandomBytes(\"webui-secret-key\", { length: 32 });\n\n// ---------------------------------------------------------------------------\n// Build and push both images during `pulumi up` (no docker CLI; the provider\n// embeds buildx). Render then pulls them by their digest-pinned ref.\n// ---------------------------------------------------------------------------\nconst registryAuth = [{ address: \"ghcr.io\", username: ghcrUser, password: ghcrToken }];\n\nconst hermesImage = new dockerbuild.Image(\"hermes-image\", {\n context: { location: \"./hermes\" },\n dockerfile: { location: \"./hermes/Dockerfile\" },\n platforms: [\"linux/amd64\"],\n tags: [pulumi.interpolate`ghcr.io/${ghcrUser}/hermes-agent:latest`],\n push: true,\n registries: registryAuth,\n});\n\nconst webuiImage = new dockerbuild.Image(\"webui-image\", {\n context: { location: \"./openwebui\" },\n dockerfile: { location: \"./openwebui/Dockerfile\" },\n platforms: [\"linux/amd64\"],\n tags: [pulumi.interpolate`ghcr.io/${ghcrUser}/open-webui:latest`],\n push: true,\n registries: registryAuth,\n});\n\n// Credential Render uses to pull the private GHCR images.\nconst ghcrCredential = new render.RegistryCredential(\"ghcr\", {\n name: \"ghcr\",\n registry: \"GITHUB\",\n username: ghcrUser,\n authToken: ghcrToken,\n}, { provider: renderProvider });\n\n// ---------------------------------------------------------------------------\n// Hermes: a PRIVATE Render service. No public URL; reachable only over Render's\n// private network. A disk holds its memory and workspace. Env values are\n// encrypted at rest, which is how secrets ride on Render (no separate flag).\n// ---------------------------------------------------------------------------\nconst hermes = new render.PrivateService(\"hermes-agent\", {\n name: \"hermes-agent\",\n plan: \"standard\", // 2 GB; the gateway OOMs on starter's 512 MB\n region: region,\n runtimeSource: {\n // Render wants the bare repo in imageUrl; the tag/digest go in their own field.\n image: {\n imageUrl: pulumi.interpolate`ghcr.io/${ghcrUser}/hermes-agent`,\n digest: hermesImage.digest,\n registryCredentialId: ghcrCredential.id,\n },\n },\n disk: { name: \"hermes-data\", mountPath: \"/opt/data\", sizeGb: 5 },\n envVars: {\n PORT: { value: \"8642\" },\n API_SERVER_ENABLED: { value: \"true\" },\n API_SERVER_HOST: { value: \"0.0.0.0\" },\n API_SERVER_PORT: { value: \"8642\" },\n API_SERVER_MODEL_NAME: { value: modelDefault },\n // Auto-approve the agent's shell/terminal hooks (no TTY in a container),\n // so it can run code in the Modal sandbox without an interactive prompt.\n HERMES_ACCEPT_HOOKS: { value: \"1\" },\n // Secrets (encrypted at rest on Render):\n API_SERVER_KEY: { value: sharedKey.base64 },\n OPENROUTER_API_KEY: { value: openrouterApiKey },\n // Modal is a runtime credential, not a provisioned resource: Hermes creates\n // sandboxes at runtime with this token pair. No Modal provider, no Modal CLI.\n MODAL_TOKEN_ID: { value: modalTokenId },\n MODAL_TOKEN_SECRET: { value: modalTokenSecret },\n },\n}, { provider: renderProvider });\n\n// Open WebUI reaches Hermes at its Render-assigned internal hostname (the read-only\n// slug), not the bare service name. Same region + same workspace share the network.\nconst hermesApiBaseUrl = pulumi.interpolate`http://${hermes.slug}:8642/v1`;\n\n// ---------------------------------------------------------------------------\n// Open WebUI: also a PRIVATE Render service, but the container joins your tailnet\n// (tailscaled in userspace + `tailscale serve`), so you reach it at\n// https://open-webui..ts.net from your devices. Never public; the gate\n// is tailnet membership. It still reaches Hermes over Render's private network.\n// ---------------------------------------------------------------------------\nconst webui = new render.PrivateService(\"open-webui\", {\n name: \"open-webui\",\n plan: \"standard\", // 2 GB; Open WebUI OOMs on starter's 512 MB\n region: region, // must match Hermes for private networking\n runtimeSource: {\n image: {\n imageUrl: pulumi.interpolate`ghcr.io/${ghcrUser}/open-webui`,\n digest: webuiImage.digest,\n registryCredentialId: ghcrCredential.id,\n },\n },\n disk: { name: \"openwebui-data\", mountPath: \"/app/backend/data\", sizeGb: 5 },\n envVars: {\n PORT: { value: \"8080\" }, // tailscale serve points at this; Open WebUI binds it\n OPENAI_API_BASE_URL: { value: hermesApiBaseUrl },\n ENABLE_OPENAI_API: { value: \"true\" },\n ENABLE_OLLAMA_API: { value: \"false\" },\n DEFAULT_MODELS: { value: modelDefault },\n WEBUI_AUTH: { value: \"true\" },\n WEBUI_URL: { value: webuiTailnetUrl },\n // Reached only over the tailnet, so the first sign-up is the admin.\n ENABLE_LOGIN_FORM: { value: \"true\" },\n ENABLE_SIGNUP: { value: \"true\" },\n DEFAULT_USER_ROLE: { value: \"admin\" },\n // Always apply env config; otherwise Open WebUI persists the first run's config\n // to its DB and ignores later changes.\n ENABLE_PERSISTENT_CONFIG: { value: \"false\" },\n // Don't load local embedding/RAG models (a big memory saver; the agent is the brain).\n RAG_EMBEDDING_ENGINE: { value: \"openai\" },\n BYPASS_EMBEDDING_AND_RETRIEVAL: { value: \"true\" },\n OFFLINE_MODE: { value: \"true\" },\n HF_HUB_OFFLINE: { value: \"1\" },\n // Secrets (encrypted at rest):\n OPENAI_API_KEY: { value: sharedKey.base64 }, // shared bearer to call Hermes\n WEBUI_SECRET_KEY: { value: webuiSecretKey.base64 },\n // Tailscale joins this container to your tailnet and serves Open WebUI on it.\n TS_AUTHKEY: { value: tailscaleAuthKey },\n TS_HOSTNAME: { value: webuiHostname },\n },\n}, { dependsOn: hermes, provider: renderProvider });\n\nexport const hermesInternalUrl = hermesApiBaseUrl;\n// Open this from any device on your tailnet:\nexport const openWebUiTailnetUrl = webuiTailnetUrl;\n\n```\n\n```python\nimport pulumi\nimport pulumi_docker_build as docker_build\nimport pulumi_random as random\n\n# Local SDK generated by: pulumi package add terraform-provider render-oss/render 1.8.0\n# (no pulumi_render is published; the SDK is bridged from the official Render provider).\nimport pulumi_render as render\n\ncfg = pulumi.Config()\n\n# ---------------------------------------------------------------------------\n# Configuration. Non-secret values via `pulumi config set`, secrets via\n# `pulumi config set --secret` or a Pulumi ESC environment (see README).\n# The Render provider reads renderApiKey/renderOwnerId (or RENDER_API_KEY/RENDER_OWNER_ID).\n# ---------------------------------------------------------------------------\nregion = cfg.get(\"renderRegion\") or \"oregon\"\nmodel_default = cfg.get(\"modelDefault\") or \"gpt-5.5\"\n\n# Container registry the images are pushed to and Render pulls from (GHCR here).\nghcr_user = cfg.require(\"ghcrUser\")\nghcr_token = cfg.require_secret(\"ghcrToken\") # GHCR PAT with write:packages\n\n# Long-lived secrets supplied by you (dashboard-minted). Hold in config or ESC.\nmodal_token_id = cfg.require_secret(\"modalTokenId\")\nmodal_token_secret = cfg.require_secret(\"modalTokenSecret\")\nopenrouter_api_key = cfg.require_secret(\"openrouterApiKey\")\n\n# Tailscale: the only \"gateway\". Open WebUI joins your tailnet and is reachable\n# at https://..ts.net by your devices only -- never public.\n# Enable HTTPS once in the Tailscale admin console so `tailscale serve` can get a cert.\ntailscale_auth_key = cfg.require_secret(\"tailscaleAuthKey\")\ntailnet_dns_name = cfg.require(\"tailnetDnsName\") # e.g. tailc6fb4e.ts.net\nwebui_hostname = \"open-webui\"\nwebui_tailnet_url = f\"https://{webui_hostname}.{tailnet_dns_name}\"\n\n# Render provider auth (from ESC: pulumiConfig.renderApiKey / pulumiConfig.renderOwnerId).\nrender_provider = render.Provider(\n \"render\",\n api_key=cfg.require_secret(\"renderApiKey\"),\n owner_id=cfg.require(\"renderOwnerId\"),\n)\n\n# ---------------------------------------------------------------------------\n# Secrets generated in state (the in-IaC replacement for `openssl rand -base64 32`).\n# The shared bearer authenticates Open WebUI -> Hermes; it lands on both services.\n# ---------------------------------------------------------------------------\nshared_key = random.RandomBytes(\"hermes-shared-key\", length=32)\nwebui_secret_key = random.RandomBytes(\"webui-secret-key\", length=32)\n\n# ---------------------------------------------------------------------------\n# Build and push both images during `pulumi up` (no docker CLI; the provider\n# embeds buildx). Render then pulls them by their digest-pinned ref.\n# ---------------------------------------------------------------------------\nregistry_auth = [{\"address\": \"ghcr.io\", \"username\": ghcr_user, \"password\": ghcr_token}]\n\nhermes_image = docker_build.Image(\n \"hermes-image\",\n context={\"location\": \"./hermes\"},\n dockerfile={\"location\": \"./hermes/Dockerfile\"},\n platforms=[\"linux/amd64\"],\n tags=[pulumi.Output.concat(\"ghcr.io/\", ghcr_user, \"/hermes-agent:latest\")],\n push=True,\n registries=registry_auth,\n)\n\nwebui_image = docker_build.Image(\n \"webui-image\",\n context={\"location\": \"./openwebui\"},\n dockerfile={\"location\": \"./openwebui/Dockerfile\"},\n platforms=[\"linux/amd64\"],\n tags=[pulumi.Output.concat(\"ghcr.io/\", ghcr_user, \"/open-webui:latest\")],\n push=True,\n registries=registry_auth,\n)\n\n# Credential Render uses to pull the private GHCR images.\nghcr_credential = render.RegistryCredential(\n \"ghcr\",\n name=\"ghcr\",\n registry=\"GITHUB\",\n username=ghcr_user,\n auth_token=ghcr_token,\n opts=pulumi.ResourceOptions(provider=render_provider),\n)\n\n# ---------------------------------------------------------------------------\n# Hermes: a PRIVATE Render service. No public URL; reachable only over Render's\n# private network. A disk holds its memory and workspace. Env values are\n# encrypted at rest, which is how secrets ride on Render (no separate flag).\n# ---------------------------------------------------------------------------\nhermes = render.PrivateService(\n \"hermes-agent\",\n name=\"hermes-agent\",\n plan=\"standard\", # 2 GB; the gateway OOMs on starter's 512 MB\n region=region,\n runtime_source={\n \"image\": {\n \"image_url\": pulumi.Output.concat(\"ghcr.io/\", ghcr_user, \"/hermes-agent\"),\n \"digest\": hermes_image.digest,\n \"registry_credential_id\": ghcr_credential.id,\n },\n },\n disk={\"name\": \"hermes-data\", \"mount_path\": \"/opt/data\", \"size_gb\": 5},\n env_vars={\n \"PORT\": {\"value\": \"8642\"},\n \"API_SERVER_ENABLED\": {\"value\": \"true\"},\n \"API_SERVER_HOST\": {\"value\": \"0.0.0.0\"},\n \"API_SERVER_PORT\": {\"value\": \"8642\"},\n \"API_SERVER_MODEL_NAME\": {\"value\": model_default},\n # Auto-approve the agent's shell/terminal hooks (no TTY in a container).\n \"HERMES_ACCEPT_HOOKS\": {\"value\": \"1\"},\n # Secrets (encrypted at rest on Render):\n \"API_SERVER_KEY\": {\"value\": shared_key.base64},\n \"OPENROUTER_API_KEY\": {\"value\": openrouter_api_key},\n # Modal is a runtime credential: Hermes creates sandboxes at runtime with this pair.\n \"MODAL_TOKEN_ID\": {\"value\": modal_token_id},\n \"MODAL_TOKEN_SECRET\": {\"value\": modal_token_secret},\n },\n opts=pulumi.ResourceOptions(provider=render_provider),\n)\n\n# Open WebUI reaches Hermes at its Render-assigned internal hostname (the read-only slug).\nhermes_api_base_url = pulumi.Output.concat(\"http://\", hermes.slug, \":8642/v1\")\n\n# ---------------------------------------------------------------------------\n# Open WebUI: also a PRIVATE Render service, but the container joins your tailnet\n# (tailscaled in userspace + `tailscale serve`), so you reach it at\n# https://open-webui..ts.net from your devices. Never public.\n# ---------------------------------------------------------------------------\nwebui = render.PrivateService(\n \"open-webui\",\n name=\"open-webui\",\n plan=\"standard\", # 2 GB; Open WebUI OOMs on starter's 512 MB\n region=region, # must match Hermes for private networking\n runtime_source={\n \"image\": {\n \"image_url\": pulumi.Output.concat(\"ghcr.io/\", ghcr_user, \"/open-webui\"),\n \"digest\": webui_image.digest,\n \"registry_credential_id\": ghcr_credential.id,\n },\n },\n disk={\"name\": \"openwebui-data\", \"mount_path\": \"/app/backend/data\", \"size_gb\": 5},\n env_vars={\n \"PORT\": {\"value\": \"8080\"}, # tailscale serve points at this; Open WebUI binds it\n \"OPENAI_API_BASE_URL\": {\"value\": hermes_api_base_url},\n \"ENABLE_OPENAI_API\": {\"value\": \"true\"},\n \"ENABLE_OLLAMA_API\": {\"value\": \"false\"},\n \"DEFAULT_MODELS\": {\"value\": model_default},\n \"WEBUI_AUTH\": {\"value\": \"true\"},\n \"WEBUI_URL\": {\"value\": webui_tailnet_url},\n # Reached only over the tailnet, so the first sign-up is the admin.\n \"ENABLE_LOGIN_FORM\": {\"value\": \"true\"},\n \"ENABLE_SIGNUP\": {\"value\": \"true\"},\n \"DEFAULT_USER_ROLE\": {\"value\": \"admin\"},\n # Always apply env config; otherwise Open WebUI persists the first run's config.\n \"ENABLE_PERSISTENT_CONFIG\": {\"value\": \"false\"},\n # Don't load local embedding/RAG models (a big memory saver; the agent is the brain).\n \"RAG_EMBEDDING_ENGINE\": {\"value\": \"openai\"},\n \"BYPASS_EMBEDDING_AND_RETRIEVAL\": {\"value\": \"true\"},\n \"OFFLINE_MODE\": {\"value\": \"true\"},\n \"HF_HUB_OFFLINE\": {\"value\": \"1\"},\n # Secrets (encrypted at rest):\n \"OPENAI_API_KEY\": {\"value\": shared_key.base64},\n \"WEBUI_SECRET_KEY\": {\"value\": webui_secret_key.base64},\n # Tailscale joins this container to your tailnet and serves Open WebUI on it.\n \"TS_AUTHKEY\": {\"value\": tailscale_auth_key},\n \"TS_HOSTNAME\": {\"value\": webui_hostname},\n },\n opts=pulumi.ResourceOptions(depends_on=[hermes], provider=render_provider),\n)\n\npulumi.export(\"hermesInternalUrl\", hermes_api_base_url)\n# Open this from any device on your tailnet:\npulumi.export(\"openWebUiTailnetUrl\", webui_tailnet_url)\n\n```\n\n```yaml\nname: hermes-agent-pulumi\nruntime: yaml\ndescription: Deploy a Hermes agent (Render + Modal + Tailscale) as one declarative Pulumi program.\n\n# The Render SDK is bridged from the official Terraform provider. Run once:\n# pulumi package add terraform-provider render-oss/render 1.8.0\n# Then `pulumi install` regenerates it on a fresh checkout.\npackages:\n render:\n source: terraform-provider\n version: 1.1.4\n parameters:\n - render-oss/render\n - 1.8.0\n\nconfig:\n renderRegion:\n type: string\n default: oregon\n modelDefault:\n type: string\n default: gpt-5.5\n ghcrUser:\n type: string\n ghcrToken:\n type: string\n secret: true\n modalTokenId:\n type: string\n secret: true\n modalTokenSecret:\n type: string\n secret: true\n openrouterApiKey:\n type: string\n secret: true\n tailscaleAuthKey:\n type: string\n secret: true\n tailnetDnsName:\n type: string\n renderApiKey:\n type: string\n secret: true\n renderOwnerId:\n type: string\n\nvariables:\n registryAuth:\n - address: ghcr.io\n username: ${ghcrUser}\n password: ${ghcrToken}\n # Open WebUI reaches Hermes at its private slug; you reach Open WebUI on the tailnet.\n hermesApiBaseUrl: http://${hermes-agent.slug}:8642/v1\n webuiTailnetUrl: https://open-webui.${tailnetDnsName}\n\nresources:\n # Render provider auth (from config or ESC).\n render:\n type: pulumi:providers:render\n properties:\n apiKey: ${renderApiKey}\n ownerId: ${renderOwnerId}\n\n # Secrets generated in state: the replacement for `openssl rand -base64 32`.\n hermes-shared-key:\n type: random:RandomBytes\n properties:\n length: 32\n webui-secret-key:\n type: random:RandomBytes\n properties:\n length: 32\n\n # Build + push both images during `pulumi up` (no docker CLI).\n hermes-image:\n type: docker-build:Image\n properties:\n context:\n location: ./hermes\n dockerfile:\n location: ./hermes/Dockerfile\n platforms: [linux/amd64]\n tags:\n - ghcr.io/${ghcrUser}/hermes-agent:latest\n push: true\n registries: ${registryAuth}\n webui-image:\n type: docker-build:Image\n properties:\n context:\n location: ./openwebui\n dockerfile:\n location: ./openwebui/Dockerfile\n platforms: [linux/amd64]\n tags:\n - ghcr.io/${ghcrUser}/open-webui:latest\n push: true\n registries: ${registryAuth}\n\n # Credential Render uses to pull the private GHCR images.\n ghcr:\n type: render:RegistryCredential\n properties:\n name: ghcr\n registry: GITHUB\n username: ${ghcrUser}\n authToken: ${ghcrToken}\n options:\n provider: ${render}\n\n # Hermes: a PRIVATE Render service. No public URL; encrypted env vars are the secret mechanism.\n hermes-agent:\n type: render:PrivateService\n properties:\n name: hermes-agent\n plan: standard # 2 GB; the gateway OOMs on starter's 512 MB\n region: ${renderRegion}\n runtimeSource:\n image:\n imageUrl: ghcr.io/${ghcrUser}/hermes-agent\n digest: ${hermes-image.digest}\n registryCredentialId: ${ghcr.id}\n disk:\n name: hermes-data\n mountPath: /opt/data\n sizeGb: 5\n envVars:\n PORT: { value: \"8642\" }\n API_SERVER_ENABLED: { value: \"true\" }\n API_SERVER_HOST: { value: \"0.0.0.0\" }\n API_SERVER_PORT: { value: \"8642\" }\n API_SERVER_MODEL_NAME: { value: \"${modelDefault}\" }\n HERMES_ACCEPT_HOOKS: { value: \"1\" }\n API_SERVER_KEY: { value: \"${hermes-shared-key.base64}\" }\n OPENROUTER_API_KEY: { value: \"${openrouterApiKey}\" }\n MODAL_TOKEN_ID: { value: \"${modalTokenId}\" }\n MODAL_TOKEN_SECRET: { value: \"${modalTokenSecret}\" }\n options:\n provider: ${render}\n\n # Open WebUI: also a PRIVATE Render service, joined to your tailnet by its image.\n open-webui:\n type: render:PrivateService\n properties:\n name: open-webui\n plan: standard # 2 GB; Open WebUI OOMs on starter's 512 MB\n region: ${renderRegion} # must match Hermes for private networking\n runtimeSource:\n image:\n imageUrl: ghcr.io/${ghcrUser}/open-webui\n digest: ${webui-image.digest}\n registryCredentialId: ${ghcr.id}\n disk:\n name: openwebui-data\n mountPath: /app/backend/data\n sizeGb: 5\n envVars:\n PORT: { value: \"8080\" }\n OPENAI_API_BASE_URL: { value: \"${hermesApiBaseUrl}\" }\n ENABLE_OPENAI_API: { value: \"true\" }\n ENABLE_OLLAMA_API: { value: \"false\" }\n DEFAULT_MODELS: { value: \"${modelDefault}\" }\n WEBUI_AUTH: { value: \"true\" }\n WEBUI_URL: { value: \"${webuiTailnetUrl}\" }\n ENABLE_LOGIN_FORM: { value: \"true\" }\n ENABLE_SIGNUP: { value: \"true\" }\n DEFAULT_USER_ROLE: { value: \"admin\" }\n ENABLE_PERSISTENT_CONFIG: { value: \"false\" }\n RAG_EMBEDDING_ENGINE: { value: \"openai\" }\n BYPASS_EMBEDDING_AND_RETRIEVAL: { value: \"true\" }\n OFFLINE_MODE: { value: \"true\" }\n HF_HUB_OFFLINE: { value: \"1\" }\n OPENAI_API_KEY: { value: \"${hermes-shared-key.base64}\" }\n WEBUI_SECRET_KEY: { value: \"${webui-secret-key.base64}\" }\n TS_AUTHKEY: { value: \"${tailscaleAuthKey}\" }\n TS_HOSTNAME: { value: \"open-webui\" }\n options:\n provider: ${render}\n dependsOn:\n - ${hermes-agent}\n\noutputs:\n hermesInternalUrl: ${hermesApiBaseUrl}\n # Open this from any device on your tailnet:\n openWebUiTailnetUrl: ${webuiTailnetUrl}\n\n```\n\nNeither box is published to the internet. The same code, plus the Dockerfiles and the Tailscale entrypoint, is in the companion repo:\n\n[![GitHub repository: dirien/hermes-agent-pulumi](https://opengraph.githubassets.com/1/dirien/hermes-agent-pulumi)\n\ngithub.com/dirien/hermes-agent-pulumi\n\n](https://github.com/dirien/hermes-agent-pulumi)\n\n## Cost\n\nTwo details shape the bill. The host starts on Render’s free [Hobby workspace](https://render.com/pricing), but a private service with a persistent disk runs on paid compute, so you need a card on file the moment you add them. There is no free-tier version of this architecture. Both services also need the 2 GB Standard plan, since the gateway and Open WebUI each OOM on the 512 MB Starter.\n\nHermes gateway\n\nOpen WebUI\n\n**Plan**\n\nStandard (2 GB)\n\nStandard (2 GB)\n\n**Compute**\n\n~$25/mo\n\n~$25/mo\n\n**Disk**\n\n5 GB\n\n5 GB\n\n**Public URL**\n\nnone\n\nnone (tailnet only)\n\nThat lands the host around $50/month, in line with what a comparable managed setup runs. [Modal](https://modal.com/pricing) and [OpenRouter](https://openrouter.ai/) bill by usage on top, so the total tracks how hard the agent works rather than a flat number. Tailscale is free for a personal tailnet, so the private gateway adds nothing to that.\n\nThe [persistent disk](https://render.com/docs/disks) pins each service to a single instance, so there is no autoscaling, and a redeploy drops a few seconds of connectivity while the old instance lets go of the disk. For a single-user agent that is a fine trade, and it is why “stand it up in a second region” is a copy-the-config move and not a live failover.\n\n![OpenRouter dashboard showing model usage and remaining credit](screenshot-openrouter-dashboard.png)\n\n*The OpenRouter Activity dashboard: 56 requests and 738K tokens of `gpt-5.5` usage, all routed through one key.*\n\n## Running the deployment\n\nWith your ESC environment referenced in `Pulumi.dev.yaml`, deploy with:\n\n```bash\npulumi up\n\n```\n\nThis generates the Render SDK’s resources, builds and pushes both images through buildx, and creates the two private services with their disks and encrypted env vars, all in one run, with no `docker` CLI and no secret import hiding in a script. When it finishes, both services show up in the Render dashboard with no public URL.\n\n![Render dashboard showing the hermes-agent and open-webui private services](screenshot-render-services.png)\n\n*The `hermes-agent` and `open-webui` private services in the Render dashboard, both deployed with no public URL.*\n\n### Access the agent\n\nGive it a few minutes after `pulumi up` finishes. The images still have to be pulled and the containers booted, and Open WebUI has to join your tailnet before the URL resolves. Refresh until it loads.\n\nOpen WebUI is reachable only from a device on your tailnet, at `https://open-webui..ts.net`, with no domain to buy, no DNS to point, and no certificate to manage. Open it, sign up so the first account becomes the admin, and ask the agent to run a Python command. It should fire up a Modal sandbox and return the result, with nothing exposed to the public internet at any point.\n\n![Open WebUI answering a code prompt by running it in a Modal sandbox](screenshot-openwebui-test.png)\n\n*Open WebUI on the tailnet URL: the `gpt-5.5` agent runs `sum(i*i for i in range(1, 1001))` in a Modal sandbox and returns `333833500`.*\n\nWhen the agent runs that code, Modal builds a throwaway sandbox specifically for it. There is no Modal resource to declare, no Modal CLI to call, and no Modal provider to bridge. The Hermes service carries `MODAL_TOKEN_ID` and `MODAL_TOKEN_SECRET` as two encrypted env vars, and that is the whole footprint.\n\n![Modal dashboard showing the per-task sandboxes the agent created at runtime](screenshot-modal-sandboxes.png)\n\n*The Modal dashboard: the per-task sandboxes the Hermes agent spun up at runtime to execute code.*\n\n### Verify the deployment (optional)\n\nIf the chat UI does not load, give the services a few minutes to finish their first boot, then check two things:\n\n1. **Render dashboard logs** for the `hermes-agent` and `open-webui` services, to confirm both started and pulled their images.\n2. **Tailscale admin console** ([Machines](https://login.tailscale.com/admin/machines)), to confirm the `open-webui` node joined your tailnet. If it did not, the `TS_AUTHKEY` is likely expired or not reusable.\n\n## Security considerations\n\nSelf-hosted AI servers get found fast: scanners like [Shodan](https://www.shodan.io/) and [Censys](https://censys.io/) enumerate a freshly exposed one within hours to days, and the code-capable ones are already under [active attack](https://www.pillar.security/blog/operation-bizarre-bazaar-first-attributed-llmjacking-campaign-with-commercial-marketplace-monetization). Running an always-on agent on a machine you also use for everything else invites prompt injection on top of that. The answer here is to keep the agent unroutable from the internet and to isolate the code it runs. That defeats the scanner: nobody finds an open port to attack. It does less against the agent being turned against you from the inside, which is the harder problem.\n\nOne detail makes that isolation essential. In a headless container there is no one at the terminal to approve anything, and the same is true of its cron and CI runs, so the deployment runs Hermes with `HERMES_ACCEPT_HOOKS=1` to [auto-accept the shell hooks](https://hermes-agent.nousresearch.com/docs/user-guide/features/hooks) it would otherwise pause on. The practical result is that the agent’s code runs with no human in the loop, which is exactly why the Modal sandbox has to carry the weight: when the model writes a bad command, the throwaway container it runs in is what stands between that command and the gateway’s credentials, not a confirmation prompt.\n\nConcern\n\nTypical self-host\n\nThis deployment\n\nGateway reachability\n\nPublic port, or behind a login\n\nPrivate service, no public URL\n\nChat UI reachability\n\nPublic hostname + auth\n\nTailnet only (`tailscale serve`)\n\nCode execution\n\nRuns next to the gateway\n\nIsolated Modal sandbox, torn down after\n\nCommand approval\n\nHuman approves dangerous commands\n\nHeadless: isolation replaces the prompt\n\nSecrets in transit\n\nExposed if accessed over HTTP\n\nEncrypted env vars; tailnet-encrypted access\n\nThis is private, which is not the same as fully trusted. A few places the boundary still leaks:\n\n- **The shared bearer never rotates.** Hermes is unroutable from the internet, but it is wide open to Open WebUI, and the two share one static bearer key. Whoever owns the front end owns the gateway behind it. Rotate it periodically.\n- **The tailnet policy is click-ops.** The ACLs, the node’s tags, and the one-time HTTPS toggle live in the Tailscale admin console, not in `pulumi up`, and the reusable key has no tag scoping its blast radius. The Tailscale provider can manage that policy declaratively if you want it in code.\n- **Signup defaults to admin.** Fine on a single-user tailnet, the first thing to lock down (`ENABLE_SIGNUP`, `DEFAULT_USER_ROLE`) once more than one person can reach the URL.\n- **Every messaging client is another entry point.** Each platform you wire up adds another way in, which is why the tailnet is the baseline for securing this, not the full extent of it.\n- **A compromised agent can still reach out.** The private core stops external discovery, but it does not contain the agent itself. The gateway holds the Modal and OpenRouter tokens as env vars and can call out freely, so a prompt-injected agent could read its own environment and send them somewhere; the Modal sandbox isolates the code the agent runs, not the credentials it holds. Cap and rotate the [OpenRouter key](https://openrouter.ai/docs/cookbook/administration/api-key-rotation), keep the Modal token off the gateway, and allowlist outbound traffic, which on Render means a forward-proxy sidecar (Render gives you [dedicated outbound IPs](https://render.com/docs/outbound-ip-addresses) and inbound rules, but no destination egress filter).\n\nMy recommendations:\n\n- Keep both services private; never give Hermes a public URL\n- Run code in Modal sandboxes, since `HERMES_ACCEPT_HOOKS=1` means no human approves commands\n- Rotate the shared bearer key and the Tailscale auth key periodically\n- Cap and rotate the OpenRouter key; a leaked credential is the likelier failure mode than an open port\n- Use Pulumi ESC for secrets instead of hardcoding\n- Lock down Open WebUI signup once more than one person can reach it\n- Manage Tailscale ACLs and tags deliberately, in the admin console or with the Tailscale provider\n\n## What’s next?\n\nThe deployment is the foundation the agent builds on. A private agent becomes useful when it remembers earlier context, runs code without a human at the terminal, and initiates contact on its own. The disk is what makes this persist: its memory and its schedule live on that disk, so they survive every restart.\n\n**It schedules itself.** Hermes ships a first-class [cron](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron) you drive in plain language, either by asking the agent in the chat window or through its CLI. The schedule takes intervals, five-field cron, or one-shots:\n\n```bash\nhermes cron create \"every 1h\" \\\n \"Scrape for the price, compare it with seen.json in the sandbox, message me on Telegram only if it dropped, and otherwise reply exactly [SILENT].\" \\\n --deliver telegram\n\n```\n\nThe `[SILENT]` reply suppresses delivery when nothing changed, so the watcher only speaks up when there is something to say. Scheduled runs skip memory by default, so polling does not pollute what the agent has learned.\n\n**It connects where you work, with the same secret pattern.** Messaging clients attach to the same gateway, and their tokens ride as encrypted env vars on the Hermes service, the exact shape you used for the Modal pair:\n\n```typescript\n// alongside MODAL_TOKEN_ID on the hermes service:\nTELEGRAM_BOT_TOKEN: { value: cfg.requireSecret(\"telegramBotToken\") },\n\n```\n\nplus a platform block you add to `config.yaml` (the image ships only the model and terminal blocks; Hermes supports the messaging platforms on top, per its docs):\n\n```yaml\ngateway:\n platforms:\n telegram:\n require_mention: true\n\n```\n\nWith those two pieces, a few things are genuinely doable today:\n\n1. **A price or uptime watcher** that only speaks up when something changed, using the `[SILENT]` and persistent-sandbox dedup pattern above.\n2. **A daily briefing** that ranks and dedups your feeds and delivers the top items each morning, the documented [daily-briefing bot](https://hermes-agent.nousresearch.com/docs/guides/daily-briefing-bot). If you want it to adapt to your taste over time, that is the optional [Honcho](https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho) memory provider’s job; it reads your preferences out of the conversation itself. The built-in file memory has no version of that.\n3. **A PR-review teammate** that reviews open pull requests against your repo’s `AGENTS.md` conventions and saves recurring patterns as a skill, so the fifth review needs less hand-holding than the first.\n\nA few limits are worth stating plainly, since demos tend to overstate the capabilities. Hermes does not ship Gmail, Calendar, or market integrations out of the box; those are wired up as [MCP servers](https://modelcontextprotocol.io/) or skills, which is more work than a launch video implies. It curates its own memory and improves its own skills, but it does not retrain the underlying model or autonomously change its high-level strategy, so “self-learning” here means whatever it writes into memory and skills each run.\n\n## Conclusion\n\nDeploying a Hermes agent with infrastructure as code means you can reproduce the setup anytime, version control it, and tear it down with a single `pulumi destroy`. Keeping both services private, with no public URL and no exposed ports, means the code-executing core never sits on the internet for someone to find.\n\nThe part worth carrying to the next service you deploy: not every layer has a provider, and that is fine. The task is to tell a real resource apart from a runtime dependency wearing a costume. Render and the images are resources you declare; Modal and Tailscale are credentials you hand over. Draw that map first, and the program follows from it.\n\nTo generate that map instead of writing it by hand, [Pulumi Neo](https://www.pulumi.com/product/neo/) can take a target architecture like this one and produce a first draft of the program. The agent side of this shift is covered in [How Building AI Agents Has Changed in 2026](https://www.pulumi.com/blog/how-building-ai-agents-has-changed/) and the platform side in [Agent Sprawl Is Here. Your IaC Platform Is the Answer.](https://www.pulumi.com/blog/agent-sprawl-iac-platform-is-the-answer/).\n\nIf you run into issues or have questions, drop by the [Pulumi Community Slack](https://slack.pulumi.com/) or [GitHub Discussions](https://github.com/pulumi/pulumi/discussions). New to Pulumi? [Get started here](https://www.pulumi.com/docs/get-started/).","publishedAt":"2026-06-24T00:00:00.000Z","fetchedAt":"2026-06-24T12:00:36.165Z","url":"https://www.pulumi.com/blog/deploy-a-hermes-agent-with-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/blog/deploy-a-hermes-agent-with-pulumi/meta.png","r2Key":"releases/f19ce60c3d560fe7a5a58e78265574ee7d170d043c05d712c249c3f64dbd41a3.png","r2Url":"https://media.releases.sh/releases/f19ce60c3d560fe7a5a58e78265574ee7d170d043c05d712c249c3f64dbd41a3.png"},{"type":"image","url":"https://opengraph.githubassets.com/1/dirien/hermes-agent-pulumi","alt":"GitHub repository: dirien/hermes-agent-pulumi","r2Key":"releases/c52467aad82cf1bb1b4963ef54faccca83b326c9ed35ee1761db4c9376df2ea9.png","r2Url":"https://media.releases.sh/releases/c52467aad82cf1bb1b4963ef54faccca83b326c9ed35ee1761db4c9376df2ea9.png"}],"coverageCount":0},{"id":"rel_DmLVCA9pL47I3GKyDc7i3","version":null,"type":"feature","title":"Cloudflare-First Networking as Code with Pulumi","summary":"New blog post walks through building a standardized Cloudflare edge baseline with Pulumi, covering DNS records, WAF custom rules, a Worker canary, and Zero Trust Access policies.","titleGenerated":"Pulumi blog walks through Cloudflare edge infrastructure as code","titleShort":"Cloudflare edge infrastructure defined with Pulumi code","breaking":"none","importance":null,"content":"![](https://www.pulumi.com/blog/cloudflare-first-networking-with-pulumi/meta.png)\n\nPlatform teams managing multi-cloud applications face a dangerous visibility gap. While origin infrastructure is tightly controlled, the edge configuration often drifts through manual console tweaks. DNS records point to stale origins, WAF rules are inconsistent across environments, and Zero Trust policies fail to keep pace with team changes. This edge drift leads to application exposure or routing failures that origin teams only notice after users report them.\n\nAs applications span multiple clouds, the edge often becomes the most consistent layer for enforcing security and traffic policies. The cost of waiting for a unified edge strategy is high. Every manual change is a potential security hole or a performance bottleneck that bypasses your standard CI/CD rigor.\n\n## What you’ll build\n\nIn this post, you will build a standardized Cloudflare edge baseline. You’ll use Pulumi to define:\n\n1. **DNS records** to point to your multi-cloud origins.\n2. **WAF custom rules** to block malicious traffic before it hits your network.\n3. **A Worker canary** to handle edge logic and header validation.\n4. **Zero Trust Access policies** to secure internal tools and origin access.\n\nBy the end, you will have a version-controlled edge that you can validate and deploy across any environment.\n\n## The Pulumi program\n\nWe’ll build a Pulumi program that sets up a complete edge environment. This approach ensures that your edge security and routing are always in sync with your application code.\n\n### Setting up the provider\n\nFirst, ensure you have the `@pulumi/cloudflare` package installed and your credentials configured. The examples below are checked against `@pulumi/cloudflare@6.15.0`, the current v6 Pulumi Registry API at the time of writing.\n\n```bash\nnpm install @pulumi/cloudflare@6.15.0\npulumi config set --secret cloudflare:apiToken \"$CLOUDFLARE_API_TOKEN\"\n\n```\n\n### Defining the infrastructure\n\nHere is the complete Pulumi program in TypeScript. If your zone already has a custom WAF ruleset for the same phase, import that ruleset or add the rule to your existing ruleset instead of creating another phase-level ruleset that may fail or conflict.\n\n```typescript\nimport * as cloudflare from \"@pulumi/cloudflare\";\n\nconst accountId = \"\";\nconst trustedAdminIp = \"198.51.100.10\";\n\nconst zone = new cloudflare.Zone(\"my-zone\", {\n account: {\n id: accountId,\n },\n name: \"example.com\",\n});\n\nconst www = new cloudflare.DnsRecord(\"www\", {\n zoneId: zone.id,\n name: \"www\",\n content: \"1.2.3.4\",\n ttl: 1,\n type: \"A\",\n proxied: true,\n});\n\nconst admin = new cloudflare.DnsRecord(\"admin\", {\n zoneId: zone.id,\n name: \"admin\",\n content: \"1.2.3.4\",\n ttl: 1,\n type: \"A\",\n proxied: true,\n});\n\nconst wafRule = new cloudflare.Ruleset(\"waf-rule\", {\n zoneId: zone.id,\n name: \"Block suspicious traffic\",\n description: \"Custom WAF rule to block specific patterns\",\n kind: \"zone\",\n phase: \"http_request_firewall_custom\",\n rules: [{\n action: \"block\",\n expression: `(http.request.uri.path contains \"/admin\" and not ip.src in {${trustedAdminIp}})`,\n description: \"Block unauthorized admin access\",\n }],\n});\n\nconst worker = new cloudflare.WorkersScript(\"canary-worker\", {\n accountId: accountId,\n scriptName: \"edge-canary\",\n compatibilityDate: \"2026-01-01\",\n mainModule: \"worker.js\",\n content: `\n export default {\n async fetch(request) {\n return new Response(\"Edge Baseline Validated\", {\n headers: { \"x-edge-baseline\": \"active\" },\n });\n },\n };\n `,\n});\n\nconst workerRoute = new cloudflare.WorkersRoute(\"canary-route\", {\n zoneId: zone.id,\n pattern: \"www.example.com/*\",\n script: worker.scriptName,\n});\n\nconst adminGroup = new cloudflare.ZeroTrustAccessGroup(\"admin-group\", {\n accountId: accountId,\n name: \"Administrators\",\n includes: [{\n email: {\n email: \"admin@example.com\",\n },\n }],\n});\n\nconst accessApp = new cloudflare.ZeroTrustAccessApplication(\"internal-tool\", {\n accountId: accountId,\n name: \"Internal Admin Tool\",\n domain: \"admin.example.com\",\n type: \"self_hosted\",\n policies: [{\n name: \"Allow administrators\",\n precedence: 1,\n decision: \"allow\",\n includes: [{\n group: {\n id: adminGroup.id,\n },\n }],\n }],\n});\n\n```\n\n## Validation\n\nOnce you run `pulumi up`, you can validate your edge baseline with these steps:\n\n1. **DNS check**: Run `dig www.example.com` to confirm the record points to Cloudflare’s proxied IPs.\n2. **WAF test**: Attempt to access `www.example.com/admin` from an unauthorized IP and verify you receive a 403 Forbidden response.\n3. **Worker canary**: Use `curl -I https://www.example.com` and check for the `x-edge-baseline: active` header.\n4. **Access policy**: Navigate to `admin.example.com` and verify you are redirected to the Cloudflare Access login page.\n\nBy managing these resources as code, you eliminate the risk of manual drift and ensure that every environment starts with a secure, validated edge baseline.","publishedAt":"2026-06-23T00:00:00.000Z","fetchedAt":"2026-06-23T11:01:32.827Z","url":"https://www.pulumi.com/blog/cloudflare-first-networking-with-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/blog/cloudflare-first-networking-with-pulumi/meta.png","r2Key":"releases/975a21f28aacf0e2aead59994f61a48fdf89ab77dbda7a4b8c67df3d7f50c49d.png","r2Url":"https://media.releases.sh/releases/975a21f28aacf0e2aead59994f61a48fdf89ab77dbda7a4b8c67df3d7f50c49d.png"}],"coverageCount":0},{"id":"rel_Ehw3pbtsE9hlVW_oGkpoL","version":null,"type":"feature","title":"Neo code reviews: AI code review built for infrastructure","summary":"Pulumi introduced Neo code reviews, now in public preview, which analyze pull request changes against live cloud infrastructure and preview output. Reviews post as comments on GitHub PRs, respect existing RBAC and guardrails, and are free during preview before GA on July 1, 2026.","titleGenerated":"Pulumi launches Neo code reviews for infrastructure-as-code pull requests","titleShort":"Neo code reviews analyze IaC against live infrastructure","breaking":"none","importance":null,"content":"![](https://www.pulumi.com/blog/neo-code-reviews/meta.png)\n\nToday we’re introducing [Pulumi Neo code reviews](https://www.pulumi.com/docs/ai/code-reviews/), now in public preview. Neo code reviews analyze pull request changes in conjunction with what Pulumi Cloud knows about your running infrastructure, providing both high-level and code-level feedback.\n\nNormal code review agents can’t reliably anticipate the impact an infrastructure-as-code change will have. This is because they don’t have access to critical aspects of the IaC workflow: the potential impact the update will have, in this case the `pulumi preview` output; and the current state of the cloud infrastructure. Neo not only has access to both of those, but also to the entirety of your other cloud context, such as stack relationships and dependencies.\n\n## Running reviews\n\nNeo can review every pull request automatically, or only when someone mentions `@pulumi-neo`. Either way, it skips draft pull requests and those opened by bots by default.\n\nA review is a comment, so it informs the person approving the merge and sits alongside the required checks and branch protection you already enforce. Neo code reviews run inside the same governance as every other Neo task, with the [RBAC](https://www.pulumi.com/docs/administration/access-identity/rbac/), guardrails, and audit logging your organization has set.\n\n![Neo code review on a GitHub pull request, showing a risk assessment and the resource changes the update would make](neo-code-review.png)\n\n## Enable code reviews\n\nNeo code reviews are available on GitHub during public preview. They require Pulumi Neo to be enabled for your organization, the [Pulumi GitHub App](https://www.pulumi.com/docs/integrations/version-control/github-app/) installed on the repositories you want reviewed, and a one-time grant from each organization user to access their GitHub account under **Management** > **Version control**. If Neo currently posts preview summaries on your pull requests, code reviews are already enabled, and they take the place of those summaries.\n\nNeo code reviews are free while in public preview. On July 1, 2026, they’ll be generally available, and reviews will begin counting toward your organization’s Neo token usage, at the same per-token rate as any other Neo task. The [pricing page](https://www.pulumi.com/pricing/) shows that rate and the monthly token allotment included with each plan.\n\n## Give it a try\n\nOpen a pull request against a stack Pulumi manages and see Neo’s review. We want to hear what it catches and what it misses, so hop into the [Pulumi Community Slack](https://slack.pulumi.com/) and tell us.","publishedAt":"2026-06-22T15:00:00.000Z","fetchedAt":"2026-06-23T01:01:24.349Z","url":"https://www.pulumi.com/blog/neo-code-reviews/","media":[{"type":"image","url":"https://www.pulumi.com/blog/neo-code-reviews/meta.png","r2Key":"releases/a7bf7dd791583d90f2fbd165b4b453b612ad4313586883f3a1f5fc169663bacf.png","r2Url":"https://media.releases.sh/releases/a7bf7dd791583d90f2fbd165b4b453b612ad4313586883f3a1f5fc169663bacf.png"}],"coverageCount":0},{"id":"rel_EzRN1Tn4cUbHyLrtAgjF_","version":null,"type":"feature","title":"Six Live Kubernetes Recommendations: AKS, Cilium, Rate Limiting, and More","summary":"Workshop writeup covers six recommendations for Kubernetes on Azure, including enabling Cilium on AKS, picking a team-aligned language, using AI-assisted debugging to route around Docker Hub rate limits, splitting infra from workload into stacks, and managing state with Pulumi Cloud.","titleGenerated":"Pulumi blog: AKS workshop yields six Kubernetes recommendations","titleShort":"AKS workshop: Cilium, rate limiting, and six recommendations","breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/getting-started-aks-pulumi-csharp/meta.png)\n\n*On June 10th, Engin and I ran a live workshop building an AKS cluster, an Azure Container Registry, and a random-cat web app from scratch in C#. This is the writeup, including the parts we didn’t get to live.*\n\n[Video](https://www.youtube.com/watch?v=-K_lI65Djzs)\n\nLive 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.\n\n## 1\\. Pick the language your team already uses\n\nI opened the session by asking the room what language they prefer to work in, with one caveat from me: “Hopefully, it’s not PowerShell because this is not in PowerShell.” We got some C# answers and zero requests for PowerShell, which works out, because the whole workshop is in PowerShell C#.\n\nI chose C# because, first, I genuinely love the language. I spent the early part of my career as a C# developer, and on Azure it just makes sense. Second, an Azure workshop tends to draw a big turnout of C# devs, and if they aren’t C# devs themselves, they often work somewhere the backend team uses C#. Pulumi lets you bring that language to your infrastructure rather than learn a new DSL.\n\nAI coding assistants also came up. LLMs have substantially more C# and Go in their training data than HCL or Bicep. As I put it live: “If you’re working in HCL, well, there’s not that much out there in the training set, but there’s lots of C#. There’s lots of Go.” I co-authored parts of the workshop code with Claude.\n\n**Pick the language your team already writes.**\n\nPulumi runs on the language your backend engineers know, and that language has more AI assistant training data behind it too.\n\n## Aside: everyone’s path ran through Docker Swarm\n\nWe also had some fun historical conversations about orchestrators. I asked Engin: “Did you use anything before Kubernetes became popular? Like Mesosphere or any of those other interesting solutions of the heyday?”\n\nEngin had walked the same road most of us did.\n\n> **Engin:** “We used the classical Ansible powered provisioning of VMs… And then we switched to Consul to have a little bit more control… And then we had a short intermezzo with Docker Swarm… So Docker Swarm with Portainer was really goated. And Kubernetes then took over.”\n\nMy own history rhymed with his.\n\n> **Adam:** “I worked at a place where we used a bunch of shell scripts to have like JVM services, like a red green deploy… And then it was Docker Swarm for a little bit. And then it was Kubernetes.”\n\nNo single tool won. Teams picked what fit their existing skills and shifted gradually as the ecosystem matured.\n\n## 2\\. Use Cilium on AKS if you can\n\nBy default, Kubernetes on AKS doesn’t turn on Cilium. My strong recommendation is to turn it on. The option is called Azure CNI Powered by Cilium, and it takes one config block:\n\n```csharp\nNetworkProfile = new ACI.ContainerServiceNetworkProfileArgs\n{\n NetworkDataplane = \"cilium\",\n NetworkPlugin = \"azure\",\n NetworkPluginMode = \"overlay\",\n NetworkPolicy = \"cilium\",\n PodCidr = \"192.168.0.0/16\",\n},\n\n```\n\nThis buys you eBPF networking instead of kube-proxy and iptables. [eBPF](https://ebpf.io/what-is-ebpf/) lets you run sandboxed programs inside the Linux kernel itself, so packet handling and `NetworkPolicy` enforcement happen down in the kernel instead of up in userspace. You also get Hubble flow visibility built in, the same technology as GKE’s Dataplane V2. As I said live, “this is very easy to set up on Azure. You just network data plane, set it to Cilium. Network policy, set it to Cilium.”\n\nSelf-hosted, Cilium is `helm install cilium` with a dozen flags and a lifecycle you own forever. On AKS, it’s these five lines and Azure runs it. On a getting-started cluster, I’ll take the managed version every time. Owning that lifecycle yourself buys you nothing here.\n\nFull code: [`01-cluster/Program.cs`](https://github.com/pulumi/workshops/blob/main/az-getting-started-aks/01-cluster/Program.cs)\n\n![Stage 1: cluster and ACR in place](01-cluster.png)\n\n**On managed Kubernetes, complexity you’d self-host becomes a field you set.**\n\nAKS gives you the managed version of eBPF networking. Pulumi makes the configuration code instead of portal clicks.\n\n## 3\\. Debugging Kubernetes is easier when your tools have the full context\n\nThe rate limit wasn’t even the first failure of the hour. That honor went to Azure, which refused to provision the cluster on the first `pulumi up`. I was running in Canada Central, and Pulumi Neo read the error and diagnosed it:\n\n> **Neo:** “Capacity constraints in the selected region. We might need to change our location.”\n> \n> **Adam:** “Maybe this Canadian Azure instance is not all it’s cracked up to be.”\n> \n> **Engin:** “East US is always a good bet.”\n\nWe switched the region to East US, and the cluster came up. That is the kind of diagnosis a stack-aware assistant is good at, reading the actual provisioning error instead of leaving me to guess.\n\nThen the image step hit. The workshop’s original flow pulled the cat app image into ACR with `az acr import --source docker.io/agbell/my-random-cat`, and Docker Hub rate-limited me, even though I was the only person in the room running the code. So how do you blow through an anonymous pull limit all by yourself? The trick is that `az acr import` runs server-side. Azure does the pull from Docker Hub, not my laptop, and it goes out over an egress IP shared by who-knows-how-many other Azure tenants. Docker Hub counts anonymous pulls per IP address, so all of that shared traffic lands in one bucket. It flagged me at the worst possible moment: “I just got flagged by Docker Hub. That is awesome. That will be a challenge for this demo.”\n\nNothing focuses a workshop like watching your own demo get rate-limited in front of a live audience.\n\nLive, I asked Neo to route around it: “we’re using Neo. And Neo is going to switch us out to a nice Hello World project.” Neo could see the whole stack, down to the failing image reference, and it swapped the workload over to a standard hello-world image hosted on Azure, so the deploy no longer depended on Docker Hub. A few minutes later: “we should have a Hello World container running here. It’s way less fun than my image… just a bunch of random cats. But here we can see that this is working.” I won’t oversell it. The cat was gone, and we didn’t get through every planned stage. But the cluster was up with a workload deployed, and the session kept moving.\n\nThat’s the case for a stack-aware assistant over a chatbot. A general chatbot can tell you that Docker Hub has rate limits and that you should host images closer to home. Neo was working with the actual program state, so the workaround it proposed was already wired to my resources. Engin put it this way: “for me, Pulumi Neo, the subcommand is the new Pulumi app.” When something breaks mid-demo, the tool that can read your stack is the one that helps.\n\nThe long-term fix was switching to `az acr build`, building the image in ACR from source, so the app image never has to come from Docker Hub at all. Every stage in the repo now builds the cat image this way, from source shipped in each stage’s `app/` folder:\n\n```bash\naz acr build --registry --image my-random-cat:latest app\n\n```\n\nNo local Docker, and the app image never touches Docker Hub. The only Docker Hub dependency left is the base image (`python:3.9-slim`), pulled server-side by ACR’s build instead of by an import you re-run every time.\n\nFull code: [`02-app/Program.cs`](https://github.com/pulumi/workshops/blob/main/az-getting-started-aks/02-app/Program.cs)\n\n![Stage 2: cluster, ACR, and cat app running](02-app.png)\n\n**An assistant that can read your stack beats one that can’t.**\n\nA general chatbot knows Docker Hub has rate limits. Neo could see the deployment and the failing image reference, and that context is what turned advice into a working fix mid-session.\n\n## 4\\. You don’t have to abandon Terraform to start\n\nOne attendee, Martin, had been using Terraform for eight-plus years. His question, put directly: “I’m using TF for eight plus years. Why should I consider Pulumi? Where is the strength?… It seems unnecessary to TF for me. At least from what I’m seeing now.”\n\nFair question, and the honest answer is you don’t have to abandon your modules. Pulumi has [first-class Terraform module support](https://www.pulumi.com/docs/iac/guides/building-extending/using-existing-tools/use-terraform-module/), so you can reference existing modules from a Pulumi program. Python ML teams can import infrastructure modules, and platform teams can wrap them in typed abstractions. The portfolio doesn’t change. The programs that use it just get more capable.\n\nThe sharper reason is about edges. HCL and Bicep are purpose-built DSLs, and when you hit what they can’t express, there’s no escape hatch inside the language. With a general-purpose language you can always drop to the SDK or shell out. The edges still exist. They’re just further out, and that’s the whole difference once a project gets past the basics.\n\n**You don’t have to rip and replace.**\n\nPulumi can reference existing Terraform modules. Move what makes sense now. The DSL/language tradeoff shows up at the edges, not the basics.\n\n## 5\\. Split slow infrastructure from fast workloads\n\nOnce we had the cluster up and the app running, the single program had grown: cluster, ACR, `AcrPull`, image build, deployment, service. Every new workload meant editing the file that also declares the cluster. We had planned this turn in the session in advance. I posed the problem and Engin had the recommendation ready:\n\n> **Adam:** “What do you think the problem is with my code here, Engin? … The problem is like every time I want to add a new service to my Kubernetes cluster, I have to go into this file that declares the cluster and all its infrastructure. I think I would prefer to split it.”\n> \n> **Engin:** “Create other stacks which are then referencing each other to get the values out. Actually, I highly recommend.”\n> \n> **Adam:** “Yes, I totally agree with you, Engin. We should split these out into two separate stacks.”\n\nSo that’s what we did. The infrastructure stack exports the kubeconfig and registry URL. The workload stack references those outputs via [`StackReference`](https://www.pulumi.com/docs/iac/concepts/stacks/#stackreferences). The slow-moving infra and the fast-moving app become independent deployment units. The infra team and the app team can ship on their own cadences, without fighting over one file.\n\n```csharp\n// workload/Program.cs — pulls cluster outputs, never touches cluster resources\nvar clusterStack = new StackReference(cfg.Require(\"clusterStack\"));\nvar kubeconfig = clusterStack.GetOutput(\"kubeconfig\");\nvar acrLoginServer = clusterStack.GetOutput(\"acrLoginServer\");\n\n```\n\nThe tricky part is one we didn’t cover live, which is how you split a running workload without taking down the running services. The real answer is migrating the stack state, moving resources between stacks instead of destroying and recreating them. As I noted in the session: “now we are just removing the service from our project. If this was actual production stuff, I don’t think I’d be just shutting down the service… You can actually just make changes to the state rather than tearing them down.”\n\nFor the workshop, a simpler move kept the Kubernetes cluster up and the demo moving: keep the project name. Pulumi identifies stacks as `org/project/stack`, so if you move the cluster code into `aks-cluster/` while keeping the project name `kube-kitties`, Pulumi still sees `org/kube-kitties/dev`. Same stack, nothing recreated. Rename the project and you get a second cluster.\n\nIn stage four of the demo, I showed how to extend this pattern to work with existing YAML manifests: [`ConfigGroup`](https://www.pulumi.com/registry/packages/kubernetes/api-docs/yaml/configgroup/) drives raw Kubernetes YAML through the Pulumi provider, giving you previews and dependency ordering without rewriting files. One transformation swaps the Docker Hub image reference for the ACR copy, so manifests stay portable and pods pull from your private registry.\n\nCode: [`03-split/`](https://github.com/pulumi/workshops/tree/main/az-getting-started-aks/03-split) and [`04-split-yaml/`](https://github.com/pulumi/workshops/tree/main/az-getting-started-aks/04-split-yaml)\n\n![Stage 3: infra and workload as separate stacks, joined by a stack reference](03-split.png)\n\n![Stage 4: existing YAML manifests driven through Pulumi ConfigGroup](04-split-yaml.png)\n\n**Keep the project name when you split, and the cluster doesn’t move.**\n\nPulumi identifies stacks as `org/project/stack`. Same project name means the same stack. Rename it and you spin up a new cluster.\n\n## 6\\. GitOps is the way\n\nThe final stage of the workshop is left as homework, and it’s a great one to pick up. GitOps is the standard way to run Kubernetes at this point, the One True Way™ depending on who you ask. My position from the call: “I think I’m on team GitOps.”\n\nThe take-home is the [`05-gitops`](https://github.com/pulumi/workshops/tree/main/az-getting-started-aks/05-gitops) folder. We didn’t demo it live, but the code is real and verified: Pulumi stands up the cluster, installs Argo CD, and registers the cat as an Argo `Application`. From there, changes are `git push`.\n\nTo see Kubernetes and GitOps worked through end to end, watch the video above. Engin also recently ran a [GCP workshop](https://github.com/pulumi/workshops/tree/main/getting-started-with-kubernetes-google-cloud) with great examples of GitOps with Pulumi, using Flux.\n\n**Let Pulumi stand up the cluster, then let GitOps run the apps.**\n\nPulumi installs Argo CD or Flux as part of the infrastructure. From there, workload changes are a `git push`. Stage 5 of the workshop repo is a complete Argo CD example.\n\n## Try it yourself\n\nThat’s the whole workshop, six recommendations and two live failures that ended with a cat app running on AKS. To run it yourself, clone the repo. There’s a [DEMO.md](https://github.com/pulumi/workshops/blob/main/az-getting-started-aks/DEMO.md) with every step of this session, and the stage folders mirror the arc above. `01-cluster` is the infrastructure checkpoint, `02-app` adds the cat app built into your own registry, `03-split` and `04-split-yaml` separate infrastructure from workload, and `05-gitops` is the homework.\n\nPick a stage and bring it up:\n\n```bash\ngit clone https://github.com/pulumi/workshops\ncd workshops/az-getting-started-aks/02-app\npulumi up\ncurl http://$(pulumi stack output catServiceIp)/\n\n```\n\nExpect 5 to 8 minutes waiting on cluster create. That’s just how long AKS takes. And since each folder is a complete, runnable checkpoint with its own stack, run `pulumi destroy` before moving to the next stage, or you’ll have several clusters billing at once.\n\nYou’ll need an Azure subscription, the Pulumi CLI, and the .NET SDK. Basic Kubernetes familiarity helps. For more on the building blocks, see the [Azure Native provider](https://www.pulumi.com/registry/packages/azure-native/) and the [Kubernetes provider](https://www.pulumi.com/registry/packages/kubernetes/) in the Pulumi Registry.\n\nThe full workshop code lives at [github.com/pulumi/workshops](https://github.com/pulumi/workshops) under `az-getting-started-aks`. Check out our upcoming sessions on the [workshop page](https://www.pulumi.com/events/), or subscribe to the newsletter to hear what’s coming up.\n\nIf there’s a seventh recommendation hiding in here, it’s the one I learned the hard way: never pull from Docker Hub live again. I’ll be keeping my images on a paid cloud registry from now on.\n\nEngin and I will be doing more of these, and we’d love to see you at the next one.\n\n*Parts of the workshop code were authored by Claude and Pulumi Neo, and parts of this writeup got help from both as well.*","publishedAt":"2026-06-15T12:00:00.000Z","fetchedAt":"2026-06-17T12:01:26.679Z","url":"https://www.pulumi.com/blog/getting-started-aks-pulumi-csharp/","media":[{"type":"image","url":"https://www.pulumi.com/blog/getting-started-aks-pulumi-csharp/meta.png","r2Key":"releases/e140673687135be09afc9c616ecbbe2d2c7ab4726b1472193f38517586db3e10.png","r2Url":"https://media.releases.sh/releases/e140673687135be09afc9c616ecbbe2d2c7ab4726b1472193f38517586db3e10.png"},{"type":"video","url":"https://www.youtube.com/watch?v=-K_lI65Djzs"},{"type":"video","url":"https://i.ytimg.com/vi/-K_lI65Djzs/hqdefault.jpg","alt":"Getting Started with Kubernetes on Azure (AKS) Using Pulumi C#","linkUrl":"https://www.youtube.com/watch?v=-K_lI65Djzs","r2Key":"releases/6a3d10e9be8e574177632a1f55e32e7f22bea082adbc496f2796b4fc18ac09ec.jpg","r2Url":"https://media.releases.sh/releases/6a3d10e9be8e574177632a1f55e32e7f22bea082adbc496f2796b4fc18ac09ec.jpg"}],"coverageCount":0},{"id":"rel_zb2wHHPDqg3E8A9-5SI8-","version":null,"type":"feature","title":"Stop Prompting. Design the Loop.","summary":"Article explores loop engineering, a shift from manually prompting coding agents turn-by-turn to designing automated systems that prompt agents continuously. Covers five building blocks (automations, worktrees, skills, connectors, sub-agents) plus memory infrastructure, and discusses verification, token costs, and knowledge maintenance as ongoing responsibilities.","titleGenerated":"Pulumi publishes guide to loop engineering for AI coding agents","titleShort":"Loop engineering replaces prompt-by-prompt agent work","breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/stop-prompting-design-the-loop/meta.png)\n\nFor about two years, the unit of work with a coding agent was the prompt. You wrote a good one, you gave it enough context, you read what came back, and you wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another.\n\nThat part is ending. [Addy Osmani](https://x.com/addyosmani), a director of AI at Google Cloud, has a name for what replaces it, and I have not stopped thinking about it since: [loop engineering](https://x.com/addyosmani/status/2064127981161959567). You stop being the person who prompts the agent. You design the loop that prompts it for you.\n\nIn my phrasing: you stop being the thing that runs, and start designing the thing that runs. The leverage moves up a layer. What I want to do here is take an honest look at the pieces, and at the part nobody automates.\n\n## The leverage moved up a layer\n\nThe people building these tools have already made the jump. [Peter Steinberger](https://x.com/steipete) has been posting it as a monthly reminder.\n\n![A post by Peter Steinberger (@steipete) on X: 'Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.'](./steinberger-loops.png)\n\n*Peter Steinberger ([@steipete](https://x.com/steipete)) on X.*\n\n[Boris Cherny](https://x.com/bcherny), who heads Claude Code at Anthropic, says the same thing about his own job. He does not prompt Claude anymore. He has loops running that prompt Claude and decide what to do next, scanning the issue tracker, the team chat, and the timeline for what to build. “My job is to write loops.”\n\nA loop is a goal that prompts itself. You set the purpose, and the system keeps iterating until it’s met. In practice it finds the work, hands it out, checks the result, writes down what got finished, and decides the next thing, then it pokes the agent instead of you. You build that small system once and let it run.\n\nLook closer, and a loop is really two loops nested. The inner one does the work against a spec. The outer one decides what the work should be: it watches an issue tracker, an error feed, a changelog, then writes the next spec and hands it down. Most people are still running that outer loop by hand, in their head, and calling it a backlog.\n\nThe part that surprised me is that this is barely a tooling problem anymore. A year ago a loop meant a pile of bash you wrote and maintained forever. Now the pieces ship inside the products, and the same shapes show up in Claude Code and in Codex. Osmani puts loop engineering one floor above the harness, the context and tooling you wire around a single agent. I wrote about [that harness](https://www.pulumi.com/blog/stop-tuning-prompts-build-a-harness/) a couple of weeks ago. The loop is the thing that runs on top of it: it runs on a timer, it spawns helpers, and it feeds itself.\n\n## The five pieces, and the one that holds them together\n\nStrip loop engineering down and you get roughly five building blocks, plus one place to remember things. Both Claude Code and Codex have all five now. The names differ here and there; the capability is the same.\n\n1. **Automations are the heartbeat.** They are what make a loop an actual loop and not one run you did once. A prompt or command on a cadence, a scheduled task, a hook that fires at a point in the agent’s lifecycle, or a job on CI that keeps running after you close the laptop. Discovery and triage run themselves, and the findings that matter come to you.\n2. **Worktrees keep parallel from turning into chaos.** The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines with nobody talking first. A git worktree is a separate working directory on its own branch, so one agent’s edits cannot touch another’s checkout.\n3. **Skills are intent, written down.** An agent starts every session cold and fills any hole in your intent with a confident guess. A skill is that intent written on the outside: the conventions, the build steps, the “we don’t do it like this because of that one incident,” recorded once where the agent reads it every run. Without skills, the loop re-derives your whole project from zero every cycle.\n4. **Connectors let the loop touch your real tools.** Built on MCP, they let the agent read the issue tracker, query a database, hit a staging API, or drop a message in chat. This is the difference between an agent that says “here is the fix” and a loop that opens the pull request, links the ticket, and pings the channel once CI goes green.\n5. **Sub-agents keep the maker away from the checker.** The model that wrote the code is far too generous grading its own homework. A second agent with different instructions, and sometimes a different model, catches the things the first one talked itself into. Worktrees and a cold-context reviewer are two pieces I have [written about before](https://www.pulumi.com/blog/parallel-coding-playbook-for-pulumi/), back when the question was running agents in parallel without them trampling each other.\n\nThen the sixth thing: memory. A markdown file, a Linear board, a state file, anything that lives outside the single conversation and holds what is done and what is next. It sounds too dumb to matter, and it’s the whole game. The model forgets everything between runs, so the memory has to live on disk, not in the context window. The agent forgets. The repo does not.\n\n## What makes a loop hold together\n\nA loop running unattended is also a loop making mistakes unattended. The one thing that keeps it honest is verification, and verification needs an oracle, something outside the model that returns a hard yes or no. Passing tests, a clean build, a green pipeline, a real production signal. Without an oracle, the loop compounds confidently wrong work, faster than you can read it.\n\nThe cleanest version of this already ships in the tools. Claude Code’s `/goal` keeps working across turns until a condition you actually wrote holds, something like “every test in `auth/` passes and lint is clean,” and after every turn a separate, faster model reads the transcript and decides whether you are there yet. The agent that wrote the code is not the one that grades it. That is the maker-and-checker split applied to the stop condition itself. Codex’s `/goal` reaches the same finish line a different way: the agent audits its own work against the evidence before it can call the goal done.\n\n## What the loop still won’t do for you\n\nThe loop changes the shape of the work. It does not take it off your desk. And a few things get sharper as the loop gets better, not softer.\n\n**Verification is still on you.** The split reviewer is what makes “it’s done” mean something, but “done” is a claim, not a proof. Your job is still to ship code you confirmed works, which is harder to remember when the diff arrived while you were at lunch.\n\n**The bill comes in two currencies.** Tokens and attention. A single unattended run can burn through millions of tokens, and that is only worth it when the tokens buy something worth more than they cost. The quieter trap is the second currency: memory is what lets a loop compound over time, and slop compounds right alongside it. A loop pointed at a vague goal does not get tired and stop. It gets faster.\n\n**Your understanding rots if you let it.** The faster the loop ships code you did not write, the wider the gap between what exists in the repo and what you actually understand. A smooth loop grows that gap faster, not slower, unless you read what it made. The comfortable posture, where you stop having an opinion and take whatever the loop gives back, is the risky one. Two engineers can build the exact same loop and get opposite results, one moving faster on work they understand deeply, the other avoiding the work entirely. The loop cannot tell which one you are.\n\n## When the loop reaches production\n\nMost of this thinking grew up around application code, where a bad run costs you a revert. When the loop reaches into infrastructure, the blast radius is a production outage rather than a revert, and the verification bar has to rise to meet it. The upside is that infrastructure hands the loop a better oracle than application code does. A plan diff is deterministic and machine-readable, a policy check returns a hard verdict, and drift and cost are numbers you can put a threshold on. A reviewer, whether human or agent, can read the change cold, with no memory of the prompt that produced it. That cold-context check is exactly what an unattended loop needs, and it’s the reason an infrastructure loop can be built to hold together while you sleep. [Pulumi Neo reasons over the state graph directly](https://www.pulumi.com/blog/grounded-ai-why-neo-knows-your-infrastructure/), so the checker grounds every claim in what the change actually does, not in what the writer says it does.\n\n## Where to start\n\nPick the loop you can actually trust first. In order:\n\n1. **Start where “done” is unambiguous.** CI triage, dependency bumps, a flaky-test hunt, a failing job you keep re-running by hand. Loops need an oracle, so begin where the oracle already exists.\n2. **Write the memory file before the loop.** One markdown file, or a board. What is done, what is next, what was tried and failed. This is the spine, and everything else hangs off it.\n3. **Split the checker from the maker.** Use `/goal` with a verifiable condition, or a second agent with its own instructions. Never let the agent that did the work be the one that decides the work is finished.\n4. **Cap it, then read everything.** A max-iteration count, a token budget, a teardown step. Run it once, end to end, then read every line it shipped. The first run is the measurement, not the payoff.\n\nThen look at what you built. You designed it once, and it ran without you steering each step. That is the real shift. But the leverage only holds if you wire the loop like an engineer, not like someone looking for permission to stop thinking. Read what it ships. Keep an opinion. Judgment is the one part that does not move up a layer.\n\nThe loop will do the typing. The thinking is the work.\n\n[See how Pulumi Neo closes the loop on your infrastructure](https://www.pulumi.com/product/neo/)","publishedAt":"2026-06-09T00:00:00.000Z","fetchedAt":"2026-06-09T20:01:37.075Z","url":"https://www.pulumi.com/blog/stop-prompting-design-the-loop/","media":[{"type":"image","url":"https://www.pulumi.com/blog/stop-prompting-design-the-loop/meta.png","r2Key":"releases/cead8414552738210630fec5f940dbc795e02146a45ceefdcb2644f17baa47a9.png","r2Url":"https://media.releases.sh/releases/cead8414552738210630fec5f940dbc795e02146a45ceefdcb2644f17baa47a9.png"}],"coverageCount":0},{"id":"rel_5JvsigOpKqh39c9yDytkE","version":null,"type":"feature","title":"Trigger Deployments on Git Tags","summary":"Pulumi Deployments can now trigger pulumi up automatically when a git tag is pushed, with glob-based tag filters to control which tags deploy. The feature is available across GitHub, GitLab, Bitbucket, Azure DevOps, and custom VCS integrations, and sets the PULUMI_CI_TAG_NAME environment variable for use in pre-run commands or Pulumi programs.","titleGenerated":"Pulumi Deployments now triggers on git tags","titleShort":"Deploy on git tag push","breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/trigger-deployments-on-git-tags/meta.png)\n\nA git tag is how many teams mark a release as ready. Pulumi Deployments can now act on that signal directly: configure a tag-based trigger, push a version tag like `v1.2.0`, and Pulumi automatically runs `pulumi up` for your stack. No extra pipeline glue, no manual click — your release tag *is* the deployment.\n\n## Why tags?\n\n[Push to Deploy](https://www.pulumi.com/docs/deployments/deployments/using/triggers/#push-to-deploy) has long let you preview changes on a pull request and update a stack when commits merge to a branch. That branch-based model is a great fit for continuous delivery to shared development and QA environments, where every merge should flow straight through.\n\nBut promotion to production is often deliberate, not continuous. You merge throughout the day, then decide — separately — that a particular commit is the release. The conventional way to record that decision is a git tag: `v1.2.0`, `2026.06.0`, `release-2026-06-04`. Tagging is already part of most teams’ release rituals.\n\nTag-based triggers connect that ritual to your infrastructure. Instead of wiring up a separate CI job to call the [Pulumi Deployments REST API](https://www.pulumi.com/docs/deployments/deployments/using/triggers/#rest-api) on a tag event, you configure the trigger once in your stack’s deployment settings and let Pulumi handle the rest.\n\n## How it works\n\nTag triggers are controlled by two settings on your stack’s [deployment configuration](https://www.pulumi.com/docs/deployments/deployments/using/settings/):\n\n- **Run updates for pushed tags** — a toggle that enables running `pulumi up` when a matching tag is pushed.\n- **Tag filters** — a list of glob patterns that decide which tag names qualify.\n\nTag filters use the same model as the [path filters](https://www.pulumi.com/docs/deployments/deployments/using/settings/#path-filtering) you may already know, except the patterns match against the tag name rather than changed file paths. A few examples:\n\n- `v*` — deploy on any tag beginning with `v`, such as `v1.0.0` and `v2.3.1`.\n- `v*` plus `!*-rc*` — deploy on release tags but skip release candidates like `v1.2.0-rc1`.\n- `2026.*` — deploy on calendar-versioned releases such as `2026.06.0`.\n\nFilters prefixed with `!` are exclusions, and an exclusion always wins over an include. With no filters configured and the toggle on, every tag push deploys. Deleting a tag never triggers a deployment.\n\nWhen a tag push kicks off a deployment, Pulumi sets the `PULUMI_CI_TAG_NAME` environment variable to the tag name. Your pre-run commands or your Pulumi program can read it — for example, to stamp the release version onto a resource tag or an application config value.\n\n## Works across every VCS integration\n\nTag triggers are available across all five version control integrations: [GitHub](https://www.pulumi.com/docs/integrations/version-control/github-app/), [GitLab](https://www.pulumi.com/docs/integrations/version-control/gitlab/), [Bitbucket](https://www.pulumi.com/docs/integrations/version-control/bitbucket/), [Azure DevOps](https://www.pulumi.com/docs/integrations/version-control/azure-devops-integration/), and [Custom VCS](https://www.pulumi.com/docs/integrations/version-control/custom-vcs/).\n\n## Get started\n\nYou can configure tag triggers wherever you manage deployment settings today — the [Pulumi Cloud console](https://app.pulumi.com/signin), the [REST API](https://www.pulumi.com/docs/reference/cloud-rest-api/deployments/#patch-settings), or as code with the [`pulumiservice.DeploymentSettings`](https://www.pulumi.com/registry/packages/pulumiservice/api-docs/deploymentsettings/) resource.\n\nTo try it out:\n\n1. Open a stack’s **Settings > Deploy** tab in the Pulumi Cloud console.\n2. Enable **Run updates for pushed tags** and add a tag filter such as `v*`.\n3. Push a tag — `git tag v1.0.0 && git push origin v1.0.0` — and watch the deployment run.\n\nFor the full details, see the [deployment triggers](https://www.pulumi.com/docs/deployments/deployments/using/triggers/#deploying-on-git-tags) and [tag filtering](https://www.pulumi.com/docs/deployments/deployments/using/settings/#tag-filtering) documentation. We’d love to hear how you put tag-based deployments to work.","publishedAt":"2026-06-05T00:00:00.000Z","fetchedAt":"2026-06-05T23:00:34.921Z","url":"https://www.pulumi.com/blog/trigger-deployments-on-git-tags/","media":[{"type":"image","url":"https://www.pulumi.com/blog/trigger-deployments-on-git-tags/meta.png","r2Key":"releases/122f4455f18e4c8c7a202fd6b2eb8edefddab5fff19276e6606e2c11bcd02931.png","r2Url":"https://media.releases.sh/releases/122f4455f18e4c8c7a202fd6b2eb8edefddab5fff19276e6606e2c11bcd02931.png"}],"coverageCount":0},{"id":"rel_7R26Bx1wm7bouuOI2gfPV","version":null,"type":"feature","title":"Use Your Mac for AI Agents: Self-Host Gemma 4 12 B with Pulumi and Tailscale","summary":"New guide shows how to run Google's open-weight Gemma 4 12 B model locally on a Mac using llama.cpp for native inference, k3d for local Kubernetes, Pulumi for infrastructure as code, and Tailscale for secure access. The setup achieves about 20 output tokens per second on an M3 Max MacBook Pro with 36 GB RAM and supports multimodal input including images and audio.","titleGenerated":"Pulumi blog guide: self-host Gemma 4 12 B on Mac with Pulumi and Tailscale","titleShort":"Self-host Gemma 4 on your Mac with Pulumi and Tailscale","breaking":"unknown","importance":null,"content":"![](https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/meta.png)\n\nIf you run AI tools and agents, you’ve probably accepted three tradeoffs: your data leaves your network, you can’t work offline, and your bill scales with usage.\n\nOpen-weight models now run well on consumer hardware. Once the model is on your machine, your data stays local, inference works offline, and tokens cost nothing. If you own a modern Mac, you can run a high-quality model yourself.\n\n[Gemma 4](https://blog.google/technology/ai/google-gemma-4/) is an open-weights model family from Google. This post focuses on [Gemma 4 12 B](https://developers.googleblog.com/gemma-4-12b-the-developer-guide/), released in June 2026, using Unsloth’s `Q8_0` [GGUF](https://huggingface.co/docs/hub/en/gguf). The 12 B model fits comfortably on a modern Mac while leaving enough headroom for local `llama.cpp` and a chat UI.\n\nWe’ll use `llama.cpp` for host-native inference, [k3d](https://k3d.io/) for a local Kubernetes cluster, Pulumi for infrastructure as code, and [Tailscale](https://tailscale.com/) for secure access.\n\n## Prerequisites\n\nThis setup was validated on the following hardware:\n\n- macOS 26 Tahoe, version 26.5\n- MacBook Pro with Apple M3 Max\n- 36 GB RAM\n\nOn this machine, `llama.cpp` reported about **20 output tokens per second** for a 160-token validation response with `unsloth/gemma-4-12b-it-GGUF`, `gemma-4-12b-it-Q8_0.gguf`, and a 131,072-token context. Sustained throughput varies by prompt length, thermal state, and `llama.cpp` settings.\n\nYou’ll need `brew`, `docker`, `pulumi`, and `tailscale` installed. We’ll also install `k3d` during the process.\n\n## Run Gemma 4 with host-native llama.cpp\n\nWe use `llama.cpp` directly on macOS to leverage Apple Metal acceleration. Running the LLM on the host is more efficient than trying to pass GPU access into a local Kubernetes VM.\n\nInstall the build tools:\n\n```bash\nbrew install cmake git\n\n```\n\nThen build `llama.cpp` from source and download the multimodal projector. In validation, Homebrew `llama.cpp` 9430 could run text inference, but it could not load the new Gemma 4 12 B projector and failed with `unknown projector type: gemma4uv`. Building current `llama.cpp` from source fixed that.\n\n```bash\nllm_home=\"$HOME/pulumi-gemma4-llm\"\nmkdir -p \"$llm_home/models\" \"$llm_home/logs\"\n\nif [ ! -d \"$llm_home/llama.cpp/.git\" ]; then\n git clone --depth 1 https://github.com/ggml-org/llama.cpp.git \"$llm_home/llama.cpp\"\nfi\n\ncmake -S \"$llm_home/llama.cpp\" \\\n -B \"$llm_home/llama.cpp/build\" \\\n -DGGML_METAL=ON \\\n -DGGML_BLAS=ON \\\n -DCMAKE_BUILD_TYPE=Release\n\ncmake --build \"$llm_home/llama.cpp/build\" --target llama-server -j 10\n\ncurl -L --fail \\\n --output \"$llm_home/models/mmproj-F16.gguf\" \\\n https://huggingface.co/unsloth/gemma-4-12b-it-GGUF/resolve/main/mmproj-F16.gguf\n\n```\n\nThen download and run the model with this command:\n\n```bash\n\"$HOME/pulumi-gemma4-llm/llama.cpp/build/bin/llama-server\" \\\n --hf-repo unsloth/gemma-4-12b-it-GGUF \\\n --hf-file gemma-4-12b-it-Q8_0.gguf \\\n --mmproj \"$HOME/pulumi-gemma4-llm/models/mmproj-F16.gguf\" \\\n --host 127.0.0.1 \\\n --port 18080 \\\n --ctx-size 131072 \\\n --parallel 1 \\\n --jinja \\\n --reasoning off\n\n```\n\nWe use port `18080` because `8080` is commonly used and is likely to conflict with another service you may already have running locally. If your port `8080` is free, you can use it and adjust the Pulumi config later.\n\nThe model file is about 12.65 GB, and the projector is about 116 MB. Gemma 4 12 B advertises a 131,072-token context, and this Mac loaded that full context with `--parallel 1`. `llama.cpp` projected about 15.1 GiB of Apple Metal device memory for the text model and about 258 MiB worst-case memory for the projector, leaving enough headroom for Open WebUI and the rest of the local stack. The `--reasoning off` flag keeps OpenAI-compatible chat responses visible in clients that do not read separate reasoning fields.\n\nWith `--mmproj`, `/v1/models` advertised `capabilities: [\"completion\",\"multimodal\"]`. In local validation, Open WebUI accepted an uploaded Pulumi logo image and Gemma 4 described it correctly. A small WAV file also worked through the OpenAI-compatible `input_audio` request shape, though `llama.cpp` logs still mark audio input as experimental.\n\n![Open WebUI using local Gemma 4 12 B to describe an uploaded Pulumi logo](https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/describe_image.png)\n\n### Verify the LLM API\n\nOpen a new terminal and check if `llama.cpp` is responding:\n\n```bash\ncurl http://127.0.0.1:18080/v1/models\n\n```\n\nThe `/v1/models` endpoint should return the model ID `unsloth/gemma-4-12b-it-GGUF`. Now try a chat completion:\n\n```bash\ncurl http://127.0.0.1:18080/v1/chat/completions \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"unsloth/gemma-4-12b-it-GGUF\",\n \"messages\": [{\"role\": \"user\", \"content\": \"Reply with exactly: OK\"}],\n \"temperature\": 0,\n \"max_tokens\": 32\n }'\n\n```\n\nThe chat prompt `Reply with exactly: OK` should return content `OK`. In validation, `llama.cpp` reported an output token velocity of about 20 tokens per second for a longer 160-token response.\n\n### Keep llama.cpp running after reboot\n\nFor a permanent setup, put the `llama.cpp` startup script and logs under a folder in your home directory and let `launchd` restart it when you sign in:\n\n```bash\nllm_home=\"$HOME/pulumi-gemma4-llm\"\nmkdir -p \"$llm_home/logs\" \"$HOME/Library/LaunchAgents\"\n\ncat > \"$llm_home/start-llama-server.sh\" <<'EOF'\n#!/bin/zsh\nset -euo pipefail\n\nexport PATH=\"/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin\"\n\nexec \"$HOME/pulumi-gemma4-llm/llama.cpp/build/bin/llama-server\" \\\n --hf-repo unsloth/gemma-4-12b-it-GGUF \\\n --hf-file gemma-4-12b-it-Q8_0.gguf \\\n --mmproj \"$HOME/pulumi-gemma4-llm/models/mmproj-F16.gguf\" \\\n --host 127.0.0.1 \\\n --port 18080 \\\n --ctx-size 131072 \\\n --parallel 1 \\\n --jinja \\\n --reasoning off\nEOF\n\nchmod +x \"$llm_home/start-llama-server.sh\"\n\ncat > \"$HOME/Library/LaunchAgents/com.pulumi.gemma4.llama-server.plist\" <\n\n\n\n Label\n com.pulumi.gemma4.llama-server\n ProgramArguments\n \n $llm_home/start-llama-server.sh\n \n WorkingDirectory\n $llm_home\n RunAtLoad\n \n KeepAlive\n \n StandardOutPath\n $llm_home/logs/llama-server.out.log\n StandardErrorPath\n $llm_home/logs/llama-server.err.log\n\n\nEOF\n\nlaunchctl bootout gui/$(id -u)/com.pulumi.gemma4.llama-server 2>/dev/null || true\nlaunchctl bootstrap gui/$(id -u) \"$HOME/Library/LaunchAgents/com.pulumi.gemma4.llama-server.plist\"\nlaunchctl kickstart -k gui/$(id -u)/com.pulumi.gemma4.llama-server\n\n```\n\nCheck the `launchd` service and `llama.cpp` logs:\n\n```bash\nlaunchctl print gui/$(id -u)/com.pulumi.gemma4.llama-server\ntail -f \"$HOME/pulumi-gemma4-llm/logs/llama-server.err.log\"\n\n```\n\nIf you want to stop `llama.cpp` later, unload the `launchd` service:\n\n```bash\nlaunchctl bootout gui/$(id -u)/com.pulumi.gemma4.llama-server\n\n```\n\n## Deploy Open WebUI with Pulumi and k3d\n\nNow we’ll deploy [Open WebUI](https://github.com/open-webui/open-webui) into a local Kubernetes cluster. This provides a polished chat interface that connects to our host-native LLM.\n\nFirst, install `k3d` if you haven’t already:\n\n```bash\nbrew install k3d\n\n```\n\nCreate a new cluster for this project:\n\n```bash\nk3d cluster create pulumi-gemma4-blog-qa\n\n```\n\nWe’ll use the Pulumi program in [`pulumi/examples`](https://github.com/pulumi/examples/tree/master/kubernetes-py-self-host-gemma4-llm). This program defaults to `runtimeMode=host`, which creates a Kubernetes `ExternalName` service pointing to your host machine.\n\nWhy not run the LLM inside Kubernetes on this Mac? Pulumi can do that, and the example supports it with `runtimeMode=cluster`, but that path is meant for Linux hosts with NVIDIA or AMD GPU device plugins.\n\nOn macOS, [`llama.cpp` enables Metal by default](https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md#metal-build), and Metal acceleration is available to native macOS processes. k3d runs Linux containers through Docker Desktop, so those pods do not get direct access to the Mac’s Metal device. Docker’s own [vLLM Metal announcement](https://www.docker.com/blog/docker-model-runner-vllm-metal-macos/) calls out the same boundary: Metal-backed inference runs natively on the host because there is no Metal GPU passthrough for containers. That is why this setup keeps inference host-native and lets Pulumi manage the Kubernetes UI, service wiring, and optional Tailscale access around it.\n\nClone the examples repo, navigate to the program directory, and initialize a new stack:\n\n```bash\ngit clone https://github.com/pulumi/examples.git\ncd examples/kubernetes-py-self-host-gemma4-llm\npulumi stack init gemma4-local\n\n```\n\nConfigure the program to match your local setup:\n\n```bash\npulumi config set hostLlmPort 18080\npulumi config set llmBaseUrl http://llm-server:18080/v1\n\n```\n\nThe Kubernetes service named `llm-server` maps to `host.k3d.internal`. In our validation, we confirmed that a disposable k3d pod could reach the Mac’s `llama.cpp` API at `http://llm-server:18080/v1/models` after a CoreDNS restart.\n\n```bash\nkubectl rollout restart deployment coredns -n kube-system\n\n```\n\nRun `pulumi up` to deploy Open WebUI and connect it to host-native `llama.cpp`:\n\n```bash\npulumi up\n\n```\n\nIn our validation environment, this command successfully reached the resource synthesis phase without requiring Tailscale credentials because Tailscale exposure is opt-in.\n\n## Access Open WebUI through Tailscale\n\nTailscale allows you to access your private Open WebUI instance from any device on your tailnet. Note that we only expose the web interface, not the raw LLM API, to keep the system secure.\n\nThe base Open WebUI deployment works without Tailscale credentials. To expose the web UI on your tailnet, enable Tailscale resources and provide an explicit `api_key` or OAuth/identity token:\n\n```bash\npulumi config set enableTailscale true\npulumi config set tailscale:apiKey YOUR_API_KEY --secret\n\n```\n\nOnce configured, Pulumi will create a Tailscale device or proxy that routes traffic to your Open WebUI service.\n\n## Use the model with Pi\n\nOpen WebUI gives you a browser-based chat interface, but local models are also useful from coding agents. Pi is the local coding agent used for this validation; if you do not use Pi, treat this section as an example of how any OpenAI-compatible client can point at the same local endpoint. Pi can point at the same OpenAI-compatible `llama.cpp` endpoint and use the model running on your Mac.\n\nFor a fresh Pi config, create `~/.pi/agent/models.json` with a local provider that points at the `llama.cpp` API:\n\n```json\n{\n \"providers\": {\n \"local-llama\": {\n \"baseUrl\": \"http://127.0.0.1:18080/v1\",\n \"api\": \"openai-completions\",\n \"apiKey\": \"local\",\n \"compat\": {\n \"supportsDeveloperRole\": false,\n \"supportsReasoningEffort\": false\n },\n \"models\": [\n {\n \"id\": \"unsloth/gemma-4-12b-it-GGUF\",\n \"name\": \"Gemma 4 12B Q8 (local llama.cpp)\",\n \"reasoning\": false,\n \"input\": [\"text\"],\n \"contextWindow\": 131072,\n \"maxTokens\": 1024,\n \"cost\": {\n \"input\": 0,\n \"output\": 0,\n \"cacheRead\": 0,\n \"cacheWrite\": 0\n }\n }\n ]\n }\n }\n}\n\n```\n\nThen set Pi to use that provider and model by default in `~/.pi/agent/settings.json`:\n\n```json\n{\n \"defaultProvider\": \"local-llama\",\n \"defaultModel\": \"unsloth/gemma-4-12b-it-GGUF\",\n \"defaultThinkingLevel\": \"off\",\n \"hideThinkingBlock\": true\n}\n\n```\n\nIf you already have Pi configuration files, merge the `local-llama` provider and defaults into your existing JSON instead of replacing the files.\n\n![Pi connected to local Gemma 4 through llama.cpp](https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/pi.png)\n\n## Advanced: Linux GPU in-cluster serving\n\nIf you’re running on a Linux host with an NVIDIA or AMD GPU, you can run the LLM directly inside the Kubernetes cluster. This requires the NVIDIA or ROCm device plugins.\n\nThe Pulumi program supports this through `runtimeMode=cluster`. In this mode, it deploys a `LlmServer` pod that manages the `llama.cpp` process within the cluster, using GPU resource requests to ensure hardware acceleration.\n\n## Cleanup\n\nWhen you’re done, you can tear down the resources:\n\n```bash\npulumi destroy\nk3d cluster delete pulumi-gemma4-blog-qa\n# Stop llama.cpp using the PID from your terminal\nkill \n\n```","publishedAt":"2026-06-04T00:00:00.000Z","fetchedAt":"2026-06-04T22:02:52.131Z","url":"https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/","media":[{"type":"image","url":"https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/meta.png","r2Key":"releases/4dd5187c408520eccb5cc7d79dca3e96ac2c7c1020b04e669db9b006423f8829.png","r2Url":"https://media.releases.sh/releases/4dd5187c408520eccb5cc7d79dca3e96ac2c7c1020b04e669db9b006423f8829.png"},{"type":"image","url":"https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/describe_image.png","alt":"Open WebUI using local Gemma 4 12 B to describe an uploaded Pulumi logo","r2Key":"releases/3b3788bec1ffd4b18202c43c9e34b3025e89ca44203c06f1a4aae58d28d8a764.png","r2Url":"https://media.releases.sh/releases/3b3788bec1ffd4b18202c43c9e34b3025e89ca44203c06f1a4aae58d28d8a764.png"},{"type":"image","url":"https://www.pulumi.com/blog/self-host-gemma4-llama-cpp-k8s-tailscale-pulumi/pi.png","alt":"Pi connected to local Gemma 4 through llama.cpp","r2Key":"releases/0a347511acbfaef16e5415b0c852519f90cad5d433a8ffdbace3c51f2a9b49c9.png","r2Url":"https://media.releases.sh/releases/0a347511acbfaef16e5415b0c852519f90cad5d433a8ffdbace3c51f2a9b49c9.png"}],"coverageCount":0}],"pagination":{"nextCursor":"2026-06-04T00:00:00.000Z|2026-06-04T22:02:52.131Z|rel_7R26Bx1wm7bouuOI2gfPV","limit":20},"summaries":{"rolling":{"windowDays":90,"summary":"Pulumi shipped broad platform expansion across AI infrastructure management, governance tooling, and developer experience. Bun graduated from package manager to first-class runtime for Pulumi programs, eliminating the Node.js dependency for TypeScript execution. Pulumi Neo gained critical collaboration features—Plan Mode for deliberate upfront discovery before execution, read-only task permissions to sandbox AI operations, and task sharing for organizational visibility—while Neo's migration capabilities expanded to orchestrate zero-downtime transitions from CDK, Terraform, and ARM templates. On the governance side, Pulumi shipped `pulumi policy analyze` to validate stack state against policies without running programs, locked down ESC values with `fn::final` to prevent child environment overrides, and introduced schema validation and Terraform state backend support to unify infrastructure management across tools. A 20x performance improvement from journaling moved to general availability, and the platform extended identity options with Google Sign-In, multi-VCS support (GitHub Enterprise, Azure DevOps, GitLab), and Pulumi IAM availability for self-hosted deployments.","releaseCount":44,"generatedAt":"2026-04-11T14:00:45.384Z"},"monthly":[{"year":2026,"month":3,"summary":"Pulumi focused on safety and control throughout March, launching read-only and plan-first modes for Neo alongside expanded IAM capabilities for tag-based access and team role assignments. The month also brought governance advances—OPA/Rego reached stable parity with native policy SDKs, ESC gained fn::final to lock down inherited values, and Insights expanded to customer-managed runners for regulated environments. Infrastructure tooling broadened with Terraform state backend support in Pulumi Cloud, Google Sign-In for authentication, and multi-provider version control integration, while journaling—a 20x performance improvement shipped in January—graduated to general availability by default.","releaseCount":14,"generatedAt":"2026-04-11T14:00:48.148Z"}]}}