Deploy with secrets outside source control
Production secret values can stay in the deployment’s secret store while the repository holds configuration. Wildo reconstructs the structured secret inputs from the runner’s environment and uses them to generate the runtime artifacts.
Example — Deploy with secrets outside source control
A deployment workflow receives a provider credential from its secret store. The value reaches the runtime that needs it without being written into the application’s source files.
For engineers
The CI adapter reads WILDO_SECRET_* variables and validates the reconstructed object with the same schema as file-backed environments. Provider variables use WILDO_SECRET_PROVIDER_ENV_<ENV_VAR_NAME>, retaining their declared runtime name.
Generate the workflow’s variable list from the configured application workspace:
wildo config sync --env=production --domain cicd
Inspect the generated deployment workflow’s env block. It derives required and optional inputs from the secret schema and the selected providers; do not copy a fixed list from another environment.
For example, suppose a configured provider declares EXAMPLE_API_KEY as its runtime secret. The corresponding workflow fragment is:
- name: Generate deployment artifacts
env:
WILDO_SECRET_PROVIDER_ENV_EXAMPLE_API_KEY: ${{ secrets.WILDO_SECRET_PROVIDER_ENV_EXAMPLE_API_KEY }}
run: npx wildo config sync --ci --env=production --domain config
This is a placeholder-only example of one entry, not the complete generated workflow. Store the real value under that secret-store name; never replace the expression with a literal credential.
| Boundary | Name or result |
|---|---|
| Deployment secret store | WILDO_SECRET_PROVIDER_ENV_EXAMPLE_API_KEY |
| Runner environment | The same name, populated only for the generation step |
| Reconstructed secret input | providerEnv.EXAMPLE_API_KEY |
| Configured consuming runtime | Provider credential output under its declared runtime name |
The adapter validates the reconstructed inputs. Required provider inputs must be supplied; optional inputs are identified separately by the generated list. CI consumes persisted material rather than minting temporary replacements. Generated Kubernetes artifacts are written under .wildo-saas/deploy/production/k8s/ for the deployment step to consume.
Preserve key material across the boundary
The adapter normalizes escaped newlines for key and certificate variables before use. Store the actual material in the deployment’s secret manager and expose it only to the runner steps that need it. Do not replace missing persisted keys by generating fresh ones during an ephemeral deployment.
Separate source hygiene from secret operations
The framework consumes the values; the secret store owns access, rotation and expiry policy. The runner holds them in memory and may render secrets-bearing deployment artifacts, which require their own access and cleanup policy. Local file-backed environments remain a separate supported workflow; their secrets are authored inputs, not disposable generated files.