Skip to content
GantryCD

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.

ProviderYou configurePicked up viaIdentities per stack
AWSA list of named IAM rolessts:AssumeRole with an external IDAs many as you need (up to 50)
GCPA service account emailIAM Credentials impersonationOne

Note: Azure is not supported yet — only aws and gcp integrations 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.