The Two Builders
In the same city worked two builders. Avasta the old builder moved fast. He wrote his blueprints in an untyped script, ran them against the forge, and fixed whatever broke at runtime. Sometimes the forge rejected a blueprint because a value was a number where a string was expected. Sometimes a building collapsed because a wall thickness was expressed in feet when the forge expected cubits. The errors only appeared when the forge ran. Likhit the typed builder worked differently. Before the forge ran, a checker named Sankhyaka read Likhit's blueprints and found mismatches of type and shape. The forge ran rarely and almost always succeeded.
“An error found before construction costs one correction. An error found after costs one correction plus a demolition.”
The Contract Is the Documentation
Likhit described a storage vault: const vault = new StorageAccount("vault", { resourceGroupName: rg.name, sku: { name: "Standard_LRS" }, kind: "StorageV2" }). When a colleague asked what parameters the StorageAccount accepted, Likhit did not need a document — Sankhyaka told him. The moment a colleague typed StorageAccount and opened the parameter block, the type definitions appeared: every parameter, its type, whether it was required or optional, and the allowed values for string enumerations. The type definitions were the documentation. They were always accurate because they were the same code the forge used.
“A type definition that is accurate is more useful than a document that may be outdated.”
The Reusable Component
Likhit built the same three-resource pattern many times: a storage account, a CDN profile, and a CDN endpoint linked to the storage account. Each time he rebuilt it from scratch, he made small mistakes — a parameter wrong, a dependency missing. He created a ComponentResource: a class called StaticWebsite that accepted a name and a few options and internally created all three resources in the correct configuration. He stored this class in the Component Vault. The next time he needed a static website, he wrote: new StaticWebsite("my-site", { domainName: "example.com" }). Three resources appeared, correctly wired, from one line.
“A component is a tested pattern. A pattern used once is a copy. A pattern used often is a library.”
The Stack Reference Bridge
Likhit managed infrastructure in two separate programs: one that built the network (the roads and walls), and one that built the applications that ran on the network. The applications needed the network's subnet IDs. But the programs were separate stacks. He could not import one into the other. He used stack references: a bridge that read values from another stack's outputs without combining the codebases. const network = new StackReference("org/network/prod"); const subnetId = network.getOutput("subnetId"). The application stack read the subnet ID without knowing how the network was built. The network stack could be rebuilt without touching the application stack.
“Dependencies between programs should cross explicit bridges, not hidden channels.”
The Automation API
The forge could be run from the command line. But Likhit needed to run it inside another program — a deployment system that created a new environment for every pull request, ran tests, then destroyed the environment after the tests passed. He used the Automation API: a library that embedded the forge inside a TypeScript program. His deployment system called LocalWorkspace.createOrSelectStack(), called stack.up(), waited for it to complete, read the stack outputs, ran the tests, then called stack.destroy(). The forge was not a command he ran. It was a function he called. The entire deployment lifecycle was orchestrated by his own code.
“When infrastructure management becomes a function call, it can be orchestrated like any other program.”
Sankhyaka Never Sleeps
Likhit was asked by the Queen to add a new type of resource to every building: a monitoring beacon. He added the type to his ComponentResource. Sankhyaka immediately flagged every place in the codebase where an old component was used without the new beacon type. Each flag was a location requiring attention. Likhit walked through the flags, one by one, adding the beacon. When Sankhyaka showed no more flags, the change was complete. He had not missed a single building. Avasta, working without a type-checker, made the same change and found three buildings without beacons when the auditor arrived six months later.
“The type-checker does not rest between deployments. It reviews the whole codebase on every keystroke.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Pulumi with TypeScript gives you full type safety for infrastructure. Every resource's inputs and outputs are typed — the IDE knows required parameters, valid enums, and output types before deployment. ComponentResource lets you build typed, reusable infrastructure components: classes with explicit inputs/outputs that encapsulate multi-resource patterns. StackReference lets programs share outputs without sharing code. The Automation API embeds the Pulumi engine in your TypeScript program, enabling programmatic stack management — useful for preview environments, integration tests, and custom deployment orchestration. The core insight: TypeScript's compiler finds configuration errors before the cloud API does.