How do I turn a pulumi preview into something shareable?

`pulumi preview --diff --color=always | ansi2html > preview.html` keeps the colours and the diff markers, or use `--json` and render the structured plan yourself. Publish the HTML to Comma for a URL anyone can open.

Why not just read the preview in the CI log?

Because the person who should approve a change to a production database is usually not the person with CI access, and a preview scrolls past 400 lines of unchanged resources before it reaches the one that matters.

Can reviewers comment on a specific resource?

Yes. Threads anchor to the rendered content, so "this replace will drop the volume — use a new name instead" lands on that resource rather than in a channel after the apply.

Is this a replacement for Pulumi Deployments review gates?

No — it is the artifact those gates are missing. Keep the gate where it is; publish the preview so the human being asked to approve has something readable to approve against.

Should previews be public?

No. A preview names resources, regions, account ids and sometimes ARNs. Set access to private or team on the report.

Share a Pulumi preview

pulumi preview is the single highest-stakes document in an infrastructure pipeline. It is the difference between a deploy and an outage, it is read once, and it is read in a CI log — scrolled past in a fold, in a monospace column, by whoever happened to trigger the pipeline.

The ~ update line that replaces a database is three lines down from four hundred lines of unchanged resources, and the person who would recognise it as dangerous is not the person looking.

Render it to HTML

The preview's colour is information — green create, yellow update, red replace — so keep it:

pulumi preview --diff --color=always --stack prod \
  | ansi2html --scheme=xterm > preview.html

ansi2html (from colorized-logs, or pip install ansi2html) converts the escape sequences into styled HTML rather than throwing them away.

For something more structured, pulumi preview --json emits the plan as data — every step with its op, urn and the diff of changed properties — which you can render into a table that puts replaces at the top, where they belong.

Publish it

Drop preview.html into Comma, or from the pipeline:

pulumi preview --diff --color=always | ansi2html > preview.html

curl -fsS -X POST "https://commareports.com/api/v1/reports" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html preview.html \
        --arg t "Preview — prod — PR #$PR_NUMBER" '{title: $t, html: $html}')"

POST rather than PATCH here: a preview belongs to a proposed change, so a new report per PR is the right shape, and the URL goes into the PR as the thing being approved. See the API reference and publishing from CI.

Approval that points at a resource

The reason infrastructure review is weak is that approval is granted on a pull request diff of code, while the risk lives in the plan — and the plan is not in the PR. + 12 resources in a YAML diff does not tell you one of them replaces a stateful volume.

Publishing the preview and commenting on it moves the approval onto the plan:

"This replace on aws:rds/instance:Instance will drop the data. Use deleteBeforeReplace: false and rename." — anchored on the resource.
"Approved, but run it after 20:00 UTC." — on the report, with a timestamp.

See commenting on HTML and sign-off on a report.

Keep it restricted

A preview names account ids, region, resource URNs and sometimes ARNs and endpoint hostnames. Access is per report — private, team, or anyone signed in at your domain. Use one of those, never link-anyone.

Limits

Entry HTML: 5 MB. A very large stack's full --diff output can exceed that — preview per project or per stack, which is also how it is reviewed.
Assets: 25 MB per file, 250 MB and 500 files total.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a preview →