I've been running Pulumi in production for multiple teams over the last two years, and while I initially bought into the marketing around the state management abstraction, I've come to view it as a significant architectural trade-off. The promise is alluring: you can use your cloud provider's native storage (S3, Blob Storage, GCS) for the state file, thereby eliminating a dedicated state backend like Terraform's `backend "s3"` block. However, this abstraction leaks, and when it does, the operational complexity can exceed that of a well-managed Terraform setup.
The core issue is that Pulumi's state file is not *just* a state file; it's a complex journal of your infrastructure's lifecycle. Pulumi Cloud (the SaaS) manages this brilliantly, but the self-managed state story is where the cracks appear. When you use a cloud bucket directly via `pulumi login --cloud-url s3://my-bucket`, you are not simply storing a JSON blob. Pulumi uses the bucket for a structured data store, with multiple objects for checkpoints, history, and metadata. This leads to several non-obvious failure modes:
* **Locking is a separate, critical component.** Pulumi does not use the bucket's native locking mechanisms. Instead, it relies on DynamoDB (for AWS) or a similar table service for other clouds. This is a mandatory, parallel resource you must provision and manage. If your DynamoDB table is misconfigured or becomes unavailable, your state operations fail, even if the S3 bucket is perfectly healthy.
* **State corruption recovery is a manual, undocumented process.** In Terraform, the state file is a single, relatively transparent file. Corruption or rollback procedures, while not pleasant, are at least comprehensible. With Pulumi's partitioned journal in a bucket, diagnosing and repairing a broken checkpoint requires deep knowledge of its internal structure or, more likely, a support ticket to Pulumi.
* **The abstraction obscures operational metrics.** With a dedicated backend like Terraform Cloud or a simple S3 backend, you can directly monitor the state file's size, access patterns, and even set lifecycle policies based on a clear object. Pulumi's scattered object model makes it difficult to answer simple questions like "how large is my state history?" without using Pulumi's own CLI, which defeats the purpose of transparent observability.
Consider the following minimal but *complete* setup required for a self-managed Pulumi backend on AWS, which is far more than just an S3 bucket:
```yaml
# This DynamoDB table is NOT optional for state locking.
Resources:
PulumiStateLockTable:
Type: AWS::DynamoDB::Table
Properties:
AttributeDefinitions:
- AttributeName: "key"
AttributeType: "S"
KeySchema:
- AttributeName: "key"
KeyType: "HASH"
BillingMode: PAY_PER_REQUEST
TableName: "pulumi-state-locks"
PulumiStateBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: "my-org-pulumi-state"
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled # Critical for Pulumi's history
```
You now have two critical, stateful resources to manage, secure, monitor, and backup, instead of one. The learning curve for a new team member to troubleshoot a "state is locked" error now involves understanding DynamoDB item TTLs and Pulumi's specific key schema, not just a simple lock file.
My contention is that Pulumi's "no state backend" is a semantic sleight of hand. You have traded the explicit, well-understood model of a Terraform backend for an implicit, more complex distributed system composed of object storage *and* a coordination database. For teams with mature platform groups who can package this complexity, it's manageable. For smaller teams or those seeking transparency, this trade-off often results in more time spent on state plumbing, not less. The pure win is only fully realized when subscribing to Pulumi Cloud, making the state management a vendor-managed service—which is a valid choice, but a different proposition altogether.
metrics over vibes