Skip to content

Support sourcing Pulumi programs from ConfigMaps for multi-language, multi-file programs #1036

@EronWright

Description

@EronWright

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Problem Statement

The current Program CRD (pulumi.com/v1) only supports inline YAML programs embedded in the .program field. This has several limitations:

  1. Language restriction: Only YAML programs are supported
  2. Single-file limitation: Cannot easily express multi-file programs
  3. Schema maintenance burden: Operator must track Pulumi YAML schema evolution (Deal with pulumi-yaml deprecation of configuration (in favour of config) #404, Support full YAML resource option schema on Program custom resource #527)

Proposed Solution

Enable Stacks to reference ConfigMaps containing complete Pulumi programs. Users would create programs using:

kubectl create configmap my-python-program --from-file=./program-dir/

Then reference it in a Stack:

apiVersion: pulumi.com/v1
kind: Stack
metadata:
  name: my-stack
spec:
  configMapSource:
    name: my-python-program
  stack: dev
  # ... rest of stack configuration

Benefits

  1. Multi-language support: Python, Go, TypeScript, .NET, Java, YAML - any Pulumi language
  2. Multi-file programs: Natural support for complex program structures
  3. Cleaner lifecycle: ConfigMaps are independent resources, avoiding deletion issues
  4. Better GitOps: ConfigMaps can be generated from Git sources, kustomize, etc.
  5. Program reuse: Multiple Stacks can reference the same ConfigMap
  6. Simpler maintenance: Operator doesn't need to track language-specific schemas

Implementation Approach

The implementation would follow a similar pattern to existing source types (GitSource, FluxSource, ProgramRef):

  1. Add ConfigMapSource field to Stack spec alongside existing source options
  2. In WorkspaceReconciler, detect ConfigMapSource and mount the ConfigMap as a volume
  3. Agent init container mounts ConfigMap contents as workspace directory
  4. Runtime detection happens automatically based on program files (Pulumi.yaml, package.json, go.mod, etc.)

This would be similar to how FluxSource currently works, but using ConfigMaps instead of HTTP artifact retrieval.

Related Issues

This feature would help address:

Use Cases

Python program with dependencies:

# Directory structure:
# my-program/
#   Pulumi.yaml
#   __main__.py
#   requirements.txt

kubectl create configmap my-python-program --from-file=./my-program/

TypeScript program:

# Directory structure:
# my-program/
#   Pulumi.yaml
#   index.ts
#   package.json
#   tsconfig.json

kubectl create configmap my-ts-program --from-file=./my-program/

Go program:

# Directory structure:
# my-program/
#   Pulumi.yaml
#   main.go
#   go.mod
#   go.sum

kubectl create configmap my-go-program --from-file=./my-program/

Affected area/feature

Pulumi Kubernetes Operator - Stack source resolution and Workspace initialization

Alternative Solutions

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions