Cloud providers
OpenTofu needs credentials to talk to your cloud. GantryCD delivers them as cloud integrations: per-stack configuration that lets the backend mint short-lived credentials for each run, scoped and expiring with that run. No static cloud keys are ever stored on a stack or shipped to a runner.
These are separate from the storage credentials GantryCD uses for its own state and logs — this surface is about the access your OpenTofu code uses at runtime.
| Provider | You configure | Picked up via | Identities per stack |
|---|---|---|---|
| AWS | A list of named IAM roles | sts:AssumeRole with an external ID | As many as you need (up to 50) |
| GCP | A service account email | IAM Credentials impersonation | One |
Note: Azure is not supported yet — only
awsandgcpintegrations can be created. Adding a provider is an extension point.
The model
You don’t hand GantryCD a secret. You grant GantryCD’s own cloud identity permission to assume a role (AWS) or impersonate a service account (GCP). At run time the backend exchanges its identity for temporary credentials and hands them to the runner, which makes them available to OpenTofu before any of your code runs. Nothing in your stack config can override them.
One integration is your stack’s access to one provider — you integrate with AWS
once and with GCP once. How many identities that gives you is the provider’s own
business: a stack spanning three AWS accounts has one AWS integration listing three
IAM roles, each with a name your OpenTofu selects it by. The name becomes a
credentials-file profile, so provider "aws" { profile = "network" } works just as it
does on your laptop, and a role named default serves a bare provider "aws" {}.
GCP has no such list, because it needs none: the google provider reads a single
ambient token, so a GCP integration is just the service account to impersonate.
Which providers the backend can actually serve is set by the operator with the
RUNTIME_PROVIDERS env var.
Fail fast, not mid-run
When you create a deployment, GantryCD pre-flights every cloud integration on the stack: it checks the provider is supported and that the backend can actually authenticate to it. If a check fails, deployment creation fails immediately and no runner is ever launched — a clear error instead of a run that dies at its first cloud call. The probe only ever touches GantryCD’s own identity, never your role.
Credential lifetime
Cloud credentials share the run’s single time budget (RUN_TTL, default one
hour) with every other credential the run holds, and expire together when the run
ends. Because they’re minted via AssumeRole / impersonation, the cloud’s own
session-duration and token-lifetime policies also apply — operators size
RUN_TTL accordingly.
Internals
The provider model, the pre-flight, and the startup-failure path are in Cloud Integrations; how the credentials reach the worker is in Runner Runtime Credentials.