pulumi/pulumi

Lore

The timeline of pulumi/pulumi since the first public commit in October 2016. Dates are derived from git history; speculation is hedged.

Eras

Foundations (Oct 2016 – mid 2018)

The first commit landed on 2016-10-08. The original codebase was a polyglot prototype focused on the deployment engine, gRPC plumbing, and a handful of language SDKs. The TypeScript SDK was the first to mature; Python and Go followed. The split between pkg/ (engine, CLI) and sdk/ (per-language libraries + shared types) was established early and survives unchanged.

v1 → v2 → v3 (2019 – 2021)

Pulumi shipped v1.0 in 2019 and v2.0 in 2020. The CLI v1 and v2 are now end-of-life; the README explicitly directs users to migrate to v3. The major engine changes during this period included:

A move toward modeling resources with stronger types and plan-stable URNs.
Splitting language hosts from language SDKs — language hosts are the gRPC bridge, SDKs are the user-facing library.
The introduction of component resources and remote components (multi-language components implemented behind the provider interface).

Schema and codegen platform (2020 – present)

pkg/codegen/ evolved from a single-language code emitter into a full platform. Today it generates SDKs for Go, Node, Python, .NET, Java, and YAML from a unified schema (pkg/codegen/schema/pulumi.json is the metaschema). Programgen — converting from one IaC format to another via PCL — is a sibling of SDKgen.

The PCL intermediate language solidified during this era. pkg/codegen/hcl2/ parses PCL; the per-language emitters in pkg/codegen/{go,nodejs,python}/ turn PCL into idiomatic target programs. Converter plugins (proto/pulumi/converter.proto) feed Terraform / CloudFormation / Kubernetes YAML into PCL.

Automation API (≈ 2020 – ongoing)

The Automation API made it possible to drive Pulumi from inside a host program — no shell-out to pulumi from the user's perspective (although the implementation still spawns CLI subprocesses). The API exists for Go (sdk/go/auto/), Node (sdk/nodejs/automation/), Python (sdk/python/lib/pulumi/automation/), and .NET. The shape is designed to mirror the CLI's command surface; the automation/interface definitions are generated from tools/automation/specification.json (produced by make generate-cli-spec).

State engine deep changes (2022 – 2024)

The deployment engine grew several major capabilities:

Plans / preview-on-rails — pre-computing and committing to a step list (pkg/resource/deploy/plan.go).
Resource hooks — RegisterResourceHook on the resource monitor (proto/pulumi/resource.proto) and matching plumbing in pkg/resource/deploy/resource_hooks.go.
Resource transforms — first per-resource, later stack-wide (RegisterStackTransform, RegisterStackInvokeTransform).
Journaled snapshots — incremental snapshot writing for crash safety (pkg/engine/journal_snapshot.go, pkg/backend/journal.go, ~32 KB and ~30 KB respectively).

DIY rename (2024)

The "self-managed" / "file" backend was renamed to DIY (Do-It-Yourself). The directory is now pkg/backend/diy/ (previously filestate/), and CLI surface uses "DIY" terminology. This was a user-visible rename done partly to clarify the distinction from Pulumi Cloud.

Pulumi Cloud and ESC integration (2023 – present)

The hosted backend (pkg/backend/httpstate/) gained tighter integration with Pulumi Environments, Secrets, Configuration (ESC). pkg/cmd/pulumi/env/ and sdk/go/common/env/ plus the esc command tree came online during this era. Tags, deployment metadata, and the cloud-only registry (pkg/backend/httpstate/cloud_registry.go) all date from this period.

Recent activity (last 6–12 months)

graph LR
    A[Engine: hooks, transforms] --> B[Plan / preview improvements]
    B --> C[DIY rename]
    C --> D[Cloud registry]
    D --> E[Component packages]
    E --> F[Conformance test suite expansion]

Pull requests in the last 6 months focused on:

Hardening the resource hooks and stack-transform paths.
Performance work on the step generator and snapshot persistence (see pkg/backend/httpstate/snapshot_benchmark_test.go).
Cross-language conformance (scripts/run-conformance.sh) and the tests/integration/ matrix.
Continued PCL/codegen refinement, especially around convert from Terraform.

Longest-standing features

The earliest pieces of the architecture have proven remarkably stable:

Feature	Introduced	Notes
URN format	2016	`urn:pulumi:<stack>::<project>::<parent-type>$<type>::<name>` is essentially unchanged since the early days.
Resource lifecycle (Same/Create/Update/Delete/Replace)	2016	Names of steps are the same; the implementation has been re-architected several times.
`proto/pulumi/resource.proto`	2016	Many additive changes; never a backwards-incompatible break.
Output type semantics (lift, apply, dependency tracking)	2017	The Go, Node, and Python SDKs all converged on the same model.

Deprecated and renamed

What	Replacement
`filestate` backend	`diy` backend (same code, renamed)
Self-managed / file backend (terminology)	DIY backend
Pulumi v1, v2 CLIs	v3 (see migration guide referenced in `README.md`)
`pulumi stack export/import` (legacy CLI shape)	`pulumi state` subcommands (`pkg/cmd/pulumi/state/`)
Pre-`Plan` previews	`pulumi preview --save-plan` and `pulumi up --plan`

Major rewrites

Engine step model rewrite (~2019) — the step generator and step executor were split out into separate components, paving the way for parallel step execution.
Codegen consolidation (~2021) — multiple ad-hoc generators merged into a single schema-driven pipeline under pkg/codegen/.
Snapshot journaling (~2023) — write-ahead journal added to keep state consistent across crashes (pkg/engine/journal_snapshot.go).
Backend interface unification (~2024) — pkg/backend/backend.go (~21 KB) is the converged interface DIY and HTTP backends both implement.

Growth trajectory

2016: 1 contributor, ~10s of files.
2019 (v1.0): hundreds of files, ~10 contributors.
2024 (v3.x): 4,000+ Go files, 400+ unique contributors, weekly releases.
2026: 1,400+ tags, 15,000+ commits, three modular Go modules + dozens of language-host sub-modules.

The release cadence has been consistently weekly for years; a new patch tag often lands within hours of a merge to master (see release.yml and release-pr.yml in .github/workflows/).