pulumi-random

@pulumi/random is the official Pulumi provider that brings Terraform’s battle-tested random provider into Pulumi programs, letting you generate passwords, strings, integers, UUIDs, byte sequences, and Docker-style pet names as declarative, stateful resources instead of throwaway runtime values. Because Pulumi tracks each generated value in state, re-running a program doesn’t silently regenerate secrets or names on every deployment - the resource is created once and then treated as a stable input for anything downstream, such as a database password or a unique bucket suffix.

Under the hood, the provider is generated by bridging the Terraform random provider through pulumi-terraform-bridge, so it inherits the same semantics as its Terraform counterpart (keepers maps to force regeneration, sensitive output typing for passwords) while exposing an idiomatic, language-native API for TypeScript, Python, Go, C#, and Java, all built from one shared schema.

What You Get

• RandomPassword / RandomString resources for generating configurable, optionally sensitive random strings with character-class constraints (upper/lower/numeric/special).
• RandomId, RandomUuid, and RandomBytes resources for generating unique identifiers and byte sequences in base64, hex, or URL-safe encodings.
• RandomPet and RandomShuffle resources for human-readable name generation and order randomization from a supplied list.
• Native SDKs for TypeScript/JavaScript, Python, Go, C#, and Java, all generated from a single shared schema so behavior is consistent across languages.
• keepers support on every resource, letting you force regeneration only when specific upstream values change instead of on every run.

Common Use Cases

• Generating a random database password once at provisioning time and passing it into an RDS, Cloud SQL, or similar managed-database resource.
• Creating unique, collision-resistant suffixes for globally-namespaced resources like S3 buckets or Azure storage accounts.
• Assigning memorable pet-style names (e.g. witty-badger) to ephemeral environments or resource groups for readability in dashboards.
• Producing UUIDs or random IDs to correlate resources across systems without hardcoding values in source.

Under The Hood

Architecture The repository is a Terraform-bridged Pulumi provider: provider/resources.go defines a tfbridge.ProviderInfo that wraps the vendored terraform-providers/terraform-provider-random shim (via pf.ShimProvider), mapping each Terraform resource (random_password, random_string, random_id, random_uuid, random_pet, random_shuffle, random_bytes, random_integer) onto a Pulumi resource token under the random:index module. A code generator then produces the per-language SDKs under sdk/{nodejs,python,go,dotnet,java} from the resulting Pulumi schema (provider/cmd/pulumi-resource-random/schema.json), so the actual resource logic lives once in the bridge layer and the SDKs are thin, generated wrappers around pulumi.CustomResource.

Tech Stack The provider binary and bridge are Go, built against pulumi/pulumi/sdk/v3 and pulumi-terraform-bridge/v3, with the underlying randomness semantics inherited from the upstream Terraform random provider written against the Terraform Plugin Framework. Each generated SDK uses its language’s native tooling (npm/tsc for Node.js, setuptools for Python, Go modules, NuGet for .NET, Maven for Java), and the repo is orchestrated by a single Makefile plus .ci-mgmt.yaml-driven CI that builds, generates, and publishes all five SDKs together.

Code Quality Testing is split between Go-level provider tests (provider_program_test.go) and per-language example programs exercised through examples/examples_{go,nodejs,py,dotnet}_test.go, plus numbered regression tests (regress_160_test.go, regress_272_test.go, etc.) that pin down specific historical bugs. There are no unit tests inside the generated SDK directories themselves, since that code is auto-generated and not hand-maintained; correctness is instead validated at the provider/bridge layer and through end-to-end example runs in each supported language.

API Design Because every resource and SDK is generated from one shared schema, the public API is highly consistent across languages - the same resource names, property names, and keepers-based recreation semantics appear identically whether you’re in TypeScript, Python, or Go. Getting started requires minimal boilerplate: importing the package and instantiating a resource (e.g. new random.RandomPassword(...)) is enough to get a fully-typed, documented property surface, with inline JSDoc/docstrings carried over from the original Terraform provider documentation.