Pulumi previews direct resource operations with pulumi do

Pulumi introduced pulumi do as a research preview on May 22 and made it available in Pulumi CLI v3.242.0 and later as a direct way to operate resources through Pulumi providers without first creating a project, program, or state file. The announcement presents it for one-off create, read, update, delete, list, and query tasks from a consistent CLI.

Provider schemas generate the command surface

The command accepts a Pulumi type token in the form package:module:resource, followed by an operation. Users can browse partial tokens in the terminal, pass inputs interactively or from JSON or YAML, and receive structured output. The same provider resource model supplies defaults and identifiers, so the interaction does not require a separate handcrafted CLI for every service.

At launch, pulumi do resolves provider configuration through the environment variables or credential files supported by each provider. Most resource operations map directly to provider methods, and each command runs independently. The post labels the current behavior stateless; dependency tracking, drift detection, and a path into a full IaC program are roadmap items rather than present guarantees.

Stateless is an operational choice

The command lowers setup cost for experiments and repair work, but a created resource still needs an owner, cost boundary, and deletion plan. A shell history entry is not a durable inventory. Teams should capture structured output, tag resources, and decide when an operation must instead enter version-controlled IaC.

Because this is a research preview, pin the CLI version and test provider-specific defaults and error behavior in a sandbox account. Keep confirmation enabled until the exact inputs and target identity are visible, and avoid treating provider consistency as identical service semantics. pulumi do offers a common interaction shape; the cloud-side consequences remain those of the underlying resource API.