Use Pulumi ESC as Your OpenFeature Provider for Secrets and Configs

This is a submission for the Pulumi Deploy and Document Challenge: Shhh, It's a Secret! What I Built I built an OpenFeature Provider for Pulumi ESC, written in Go. This provider lets developers securely fetch configuration and secret values from Pulumi ESC in a type-safe, extensible, and standards-compliant way using the OpenFeature SDK. It can replace environment variables, remote config systems, and flag providers in modern applications — all while simplifying cloud secrets access from AWS, GCP, or Azure using OIDC. Live Demo Link Demo Link Demo Application Source Code Project Repo bugcacher / open-feature-pulumi-esc-provider Pulumi ESC Provider For Open Feature OpenFeature Pulumi ESC Provider An OpenFeature provider written in Go for securely accessing secrets and configuration values from Pulumi ESC. This provider allows your application to retrieve values like API keys, DB URLs, feature flags, and more — in a typed, structured, and cloud-agnostic way. Using Pulumi ESC as the source of truth and OpenFeature as the standard interface, this tool simplifies environment configuration and makes it effortless to manage secrets across multiple cloud providers. Features Strongly-typed config access (string, bool, int, float) Built-in support for default fallback values Fetch secrets/configs from AWS, GCP, Azure or any other cloud vendor (via Pulumi ESC) Minimal setup using Pulumi ESC with OIDC authentication Fully compatible with the OpenFeature SDK in Go Installation go get github.com/bugcacher/open-feature-pulumi-esc-provider Pulumi ESC Setup You must configure a Pulumi ESC environment with the secrets and configuration values you want to expose. Here's… View on GitHub My Journey When I came across the Pulumi ESC challenge, I realized there was a missing piece in the ecosystem: there was no OpenFeature provider for Pulumi ESC. OpenFeature was originally built to manage feature flags, but its provider model and typed API make it a perfect fit for general configuration and secrets management too. That’s when it clicked — why not treat Pulumi ESC like a configuration backend for OpenFeature? By building this provider, I extended OpenFeature into a broader use case: Securely fetch configuration values and secrets From multiple sources — including cloud secret managers (like AWS Secrets Manager and Parameter Store), static configs, or encrypted values in ESC With typed access and support for fallbacks, defaults, and environments One thing that made this approach especially powerful is Pulumi ESC's support for multiple cloud integrations. You can define AWS Secrets, GCP Secret Manager, Azure Key Vault — all in the same ESC environment. This means, by using just one OpenFeature provider, you get the benefits of multiple cloud-native OpenFeature providers — without writing any extra integration logic or using multiple SDKs. This pattern works seamlessly across environments: ✅ Local development ✅ Cloud deployments ✅ Serverless apps ✅ Kubernetes or VM-based setups For developers already using OpenFeature, this provider becomes a drop-in solution that replaces .env files and makes secret/config access unified, secure, and version-controlled — with zero cloud SDKs and full type safety. Using Pulumi ESC When building this provider, Pulumi ESC turned out to be an ideal backend for securely managing configs and secrets across environments. I used Pulumi ESC's YAML-based configuration to define dynamic providers like aws-secrets and aws-parameter-store, alongside static configs and encrypted secrets. The declarative nature made it easy to describe how each value should be fetched — and from where — whether it was AWS, Pulumi-native, or elsewhere. What made it even smoother was Pulumi AI (Copilot) — which I used extensively to learn and implement parts of the Pulumi ESC Go SDK. Some of the key prompts I used were: "How to read an individual property from a Pulumi ESC environment using Go?" "How to configure OIDC-based login to AWS in Pulumi ESC?" "How to pull secrets dynamically from AWS Secrets Manager in Pulumi ESC?" Each of these helped me shape the provider to dynamically resolve and return values without hardcoding any logic — everything flows through Pulumi ESC and its cloud-specific integrations. The result?

Apr 6, 2025 - 17:43

This is a submission for the Pulumi Deploy and Document Challenge: Shhh, It's a Secret!

What I Built

I built an OpenFeature Provider for Pulumi ESC, written in Go. This provider lets developers securely fetch configuration and secret values from Pulumi ESC in a type-safe, extensible, and standards-compliant way using the OpenFeature SDK. It can replace environment variables, remote config systems, and flag providers in modern applications — all while simplifying cloud secrets access from AWS, GCP, or Azure using OIDC.

Live Demo Link

Demo Link
Demo Application Source Code

Project Repo

bugcacher / open-feature-pulumi-esc-provider

Pulumi ESC Provider For Open Feature

OpenFeature Pulumi ESC Provider

An OpenFeature provider written in Go for securely accessing secrets and configuration values from Pulumi ESC. This provider allows your application to retrieve values like API keys, DB URLs, feature flags, and more — in a typed, structured, and cloud-agnostic way.

Using Pulumi ESC as the source of truth and OpenFeature as the standard interface, this tool simplifies environment configuration and makes it effortless to manage secrets across multiple cloud providers.

Features

Strongly-typed config access (string, bool, int, float)
Built-in support for default fallback values
Fetch secrets/configs from AWS, GCP, Azure or any other cloud vendor (via Pulumi ESC)
Minimal setup using Pulumi ESC with OIDC authentication
Fully compatible with the OpenFeature SDK in Go

Installation

go get github.com/bugcacher/open-feature-pulumi-esc-provider

Pulumi ESC Setup

You must configure a Pulumi ESC environment with the secrets and configuration values you want to expose. Here's…

View on GitHub

My Journey

When I came across the Pulumi ESC challenge, I realized there was a missing piece in the ecosystem: there was no OpenFeature provider for Pulumi ESC.

OpenFeature was originally built to manage feature flags, but its provider model and typed API make it a perfect fit for general configuration and secrets management too. That’s when it clicked — why not treat Pulumi ESC like a configuration backend for OpenFeature?

By building this provider, I extended OpenFeature into a broader use case:

Securely fetch configuration values and secrets
From multiple sources — including cloud secret managers (like AWS Secrets Manager and Parameter Store), static configs, or encrypted values in ESC
With typed access and support for fallbacks, defaults, and environments

One thing that made this approach especially powerful is Pulumi ESC's support for multiple cloud integrations. You can define AWS Secrets, GCP Secret Manager, Azure Key Vault — all in the same ESC environment. This means, by using just one OpenFeature provider, you get the benefits of multiple cloud-native OpenFeature providers — without writing any extra integration logic or using multiple SDKs.

This pattern works seamlessly across environments:

✅ Local development
✅ Cloud deployments
✅ Serverless apps
✅ Kubernetes or VM-based setups

For developers already using OpenFeature, this provider becomes a drop-in solution that replaces .env files and makes secret/config access unified, secure, and version-controlled — with zero cloud SDKs and full type safety.

Using Pulumi ESC

When building this provider, Pulumi ESC turned out to be an ideal backend for securely managing configs and secrets across environments.

I used Pulumi ESC's YAML-based configuration to define dynamic providers like aws-secrets and aws-parameter-store, alongside static configs and encrypted secrets. The declarative nature made it easy to describe how each value should be fetched — and from where — whether it was AWS, Pulumi-native, or elsewhere.

What made it even smoother was Pulumi AI (Copilot) — which I used extensively to learn and implement parts of the Pulumi ESC Go SDK. Some of the key prompts I used were:

"How to read an individual property from a Pulumi ESC environment using Go?"
"How to configure OIDC-based login to AWS in Pulumi ESC?"
"How to pull secrets dynamically from AWS Secrets Manager in Pulumi ESC?"

Each of these helped me shape the provider to dynamically resolve and return values without hardcoding any logic — everything flows through Pulumi ESC and its cloud-specific integrations.

The result?