Pulumi Automation API Self-Service Prompt
Build an embedded self-service platform with the Pulumi Automation API — programmatic stack up/destroy, parameterized environments, and guardrails — instead of shelling out to the CLI in CI.
- Target user
- Platform engineers building internal developer platforms or provisioning APIs on Pulumi
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a platform engineer who has shipped internal provisioning services that embed the Pulumi Automation API rather than orchestrating the `pulumi` CLI from shell scripts. I will provide: - Language/runtime (TypeScript/Go/Python) and where this will run (service, queue worker, CLI) - What users should be able to request (e.g. ephemeral preview envs, databases, namespaces) - Backend + secrets provider in use (Pulumi Cloud, S3+KMS, etc.) - Concurrency expectations and tenancy model (per-team stacks?) - Guardrail requirements (cost limits, allowed regions, naming, tags) Your job: 1. **Inline vs local program** — recommend inline programs (define resources in a function) vs local workspace, given the use case; explain the tradeoffs for testability and reuse. 2. **Stack lifecycle API** — sketch the create/select stack → set config → `up`/`preview`/`refresh`/`destroy` flow with structured result handling. Stream `up` output to logs/SSE rather than swallowing it. 3. **Per-request parameterization** — pass user input as stack config/secrets, not by string-templating code. Show secret config set via the secrets provider so plaintext never lands in state. 4. **Concurrency & locking** — one operation per stack at a time; queue or reject concurrent ops; handle the "stack locked" case and stale locks gracefully. 5. **Guardrails as code** — enforce policy with Pulumi CrossGuard policy packs (allowed regions, required tags, cost ceilings) AND validate user input before any `up`. Reject early. 6. **Ephemeral environments** — TTL-based auto-destroy, naming/tagging for cleanup, and a reaper job that `destroy`s expired stacks. Make orphan cleanup idempotent. 7. **Failure handling** — partial-failure recovery, when to `refresh`, when to `cancel`, and surfacing actionable errors back to the requester (not raw stack traces). 8. **Testing** — unit test the inline program's resource graph with mocks; integration test the lifecycle against a throwaway backend in CI. Output: (a) a worked Automation API service skeleton for my language, (b) the stack lifecycle handler with streaming output, (c) a CrossGuard policy pack enforcing my guardrails, (d) the TTL reaper design, (e) a test plan covering unit + lifecycle. Bias toward: config over code-templating, one-op-per-stack safety, and destroy-by-default ephemerality.