Pulumi onboarding as a pattern

Pulumi ESC and Pulumi Governance both need trusted access to a team's cloud accounts before they can do anything useful. Federated identity (OpenID Connect) is the right way to grant it: no long-lived keys to leak or rotate. It was also the hardest first step.

The problem

Before, setting up an OIDC login provider for AWS took four manual steps in the AWS console: create an identity provider, an IAM role, and a trust policy, then come back to Pulumi and write the ESC environment. And every account in an organization needed its own pass.

It wasn't only an ESC problem. Other Pulumi products needed the same trusted access to cloud accounts, and Governance's discovery would need it across whole organizations.

Options I rejected

• Defer it to the Pulumi CLI. There was a proposal to make setup a CLI-only feature for now. I rejected it, because it would have left the console, where teams meet ESC, with the same four manual steps. The console flow shipped first, with the CLI as one of its options, and a dedicated CLI setup followed in 2026.
• A page of its own. An early direction gave setup its own page. I rejected it because it would have made the login provider setup hard to share with the other products that needed the same feature. A side panel can open anywhere, so any product can offer setup in context.
• Names first. The first version was a three-step modal that asked for a project and environment name before it asked how to connect. I moved the decision that matters most, how to authenticate, to the front.

What I chose

• One panel, five steps: cloud provider, authentication, accounts, infrastructure and environments, create. Pulumi provisions the identity provider, IAM role and policy attachment in every selected account and creates an ESC environment for each.
• The secure path is the default. IAM Identity Center (SSO) is recommended. Static credentials, existing ESC credentials and the Pulumi CLI stay one click away, so nobody is stuck.
• The whole organization at once. Every account in one table, selected in bulk, instead of one account at a time.
• Nothing hidden. The panel says what will be created before it creates it, approval happens in AWS, and provisioning is checked off per account as it lands.

The pattern pays off: Connect cloud accounts

Connect cloud accounts, the front door to Governance, shipped on the same panel and the same cloud provider, authentication and accounts steps. It adds what Governance needs: access, with read-only as the recommended default and per-account overrides; discovery and policy defaults, with workflow-minute usage disclosed where the choice is made; and a summary that lands on proof of value, discovery running and every account backed by an ESC environment.

The tradeoff

Fewer steps has a cost. To keep the flow short, choosing accounts and setting their access share one step, and in use people miss the way to edit the accounts they selected. I'm iterating on that step. Credentials are still the biggest drop-off, and most people who get past them finish, which is why SSO is the recommended default.

Outcomes

• ESC onboarding. Four manual console steps became one guided flow. After the redesign, the share of teams creating environments with a cloud login provider roughly doubled, and over the same year the number of teams opening ESC environments nearly doubled.
• Connect cloud accounts. Setup that took hours to days, one account at a time, now takes about three minutes for a batch of accounts across AWS, Azure and Google Cloud. In a team's first setup, the typical number of accounts connected more than doubled, and most newly connected accounts now come through the organization-level flow.

Making the secure path the easy path is a growth lever: the security review stops being the blocker, and every product that needs a cloud account starts from a step teams already know.