Skip to main content
Pulumi services provision infrastructure from Go programs in your GitHub repository. The environment’s agent runs each installation’s stack; Ryvn manages state, configuration, approvals, and outputs. No Pulumi Cloud account is needed.
Ask Ryvn to enable the beta for your organization.

Prerequisites

  • A provisioned target environment (setup).
  • A connected, Pulumi-capable agent with resource permissions and outbound access for Go modules and Pulumi providers.
  • Go 1.26.10 locally to build the example.
  • A connected GitHub repository, an authenticated current Ryvn CLI (update instructions), and an existing stable release channel.
  • For Helm, a web service with a release in stable and a chart accepting app.deploymentName.

Environment setup

The beta currently supports GCP environments. Ask your environment owner to set managedStateBackend: true in platform inputs. Review all changes in the provisioning plan and complete provisioning before installing Pulumi.

Deploy a resource

The Random provider persists a generated deployment name in stack state.
1

Prepare the source

Create infrastructure/ in your repository and save these files:
infrastructure/Pulumi.yaml
infrastructure/main.go
Initialize and check the module locally:
Commit and push source, Pulumi.yaml, go.mod, go.sum, and required local/generated Go source; exclude build output.
2

Create the service and release

Use Git Sync, replacing the synthetic repository:
infrastructure.service.yaml
projectName must match Pulumi.yaml. Both projectName and build.path are immutable. Pulumi build accepts only path and branches; omit build or build.path to use the repository root.Once synced, publish from that checkout:
Releases require a full 40-character commit SHA. If CLI Git detection fails, pass --metadata-file release-metadata.yaml with your pushed commit:
release-metadata.yaml
Ryvn checks out that SHA, not the version string. The dashboard’s manual release form cannot publish Pulumi releases.
3

Configure the installation

Set the name prefix and provisioned environment, then sync:
infrastructure.installation.yaml
namePrefix is ordinary project config read by the program. Provider-specific config uses the provider’s namespace.

Secrets

Installation secrets become whole Pulumi secret objects under their names. Variable groups require Link group or this optional addition under installation spec; the group must already exist:
Installation secrets override same-name groups. Do not duplicate their names in ordinary config or use k8sSecretValue templates. For a database secret containing username and password, add this inside the pulumi.Run callback:
Use the returned Output to preserve secret tracking, not the decoded struct. Never log secret values.

Providers and Helm consumers

A Go Pulumi program can create cloud prerequisites and Kubernetes bootstrap Jobs before Helm consumers. The Kubernetes provider can use the agent’s in-cluster identity and existing RBAC; Ryvn grants no additional permissions. Provider await behavior determines Job completion. Make bootstrap operations retry-safe and avoid shared Pulumi/Helm resource ownership. The example chart reads app.deploymentName as an application deployment label. Pass the exported name to that value, adapting the key to your chart:
web.installation.yaml
Dependencies gate only the first install. Redeploy consumers when outputs change. Secret outputs require authorized access.

Approvals and troubleshooting

Environment approval policy takes precedence; if unset, autoApprove applies. Required approvals use refreshed previews; automatic operations skip this step. Approval binds release, configuration, and operation, not an exact saved plan. Pulumi recalculates at execution; drift can change results.
The beta compiles Go programs on Linux AMD64 agents with Go 1.26.10, Pulumi 3.272.0, CGO_ENABLED=0, and read-only module resolution. Pin dependencies and allow module/provider downloads. Repository checkout credentials do not authenticate private modules; preparation hooks, code generation, and Docker builds are not run.For an existing Automation API application, expose resource declarations through pulumi.Run and Pulumi config; Ryvn owns lifecycle and backend selection. Separate unrelated Rust, CGO, or generated dependencies into another module only if the deployment program can compile independently under these constraints. Moving files alone does not establish compatibility. No committed executable or wrapper image is required.
Cancellation requests a graceful stop and waits for process exit; it is not rollback. Involve your operator or Ryvn support for a stuck operation. Confirm the old executor has stopped before recovering a stale lock, then follow Pulumi’s interrupted-update guidance to reconcile state before retrying. Preserve state storage, the encryption key, and recovery access. Disabling the backend is not recovery.