Cloud Connections

Orkestia reaches every cloud the same way it reaches AWS: through an organization-scoped connection — a grant you create in your account, scoped to what workflows actually need, revocable at any time. AWS Connections has its own section because the cross-account IAM role model deserves a full walkthrough; this section covers the other live providers, which follow the same pattern with provider-native credentials and grants.

The one pattern to learn

Every provider connection works the same way operationally:

1. The workflow tells you what it needs. When a workflow's schema reports has_prerequisites: true, the prerequisites call (get_workflow_prerequisites over MCP, or the equivalent dashboard flow) returns a setup guide with Orkestia's platform identity already filled in — you grant exactly the trust required, nothing broader.
2. You create the grant in your account — a service-account key or workload-identity grant on GCP, an app registration/service principal on Azure, an API key on Magalu, a kubeconfig/service-account on Kubernetes.
3. The connection is stored org-scoped and resolved automatically at run time. Workflows never take credentials in their inputs; they name the connection they need.
4. Revoking the grant stops the work. Access is delegated, never copied — the Zero Code Custody boundary expressed operationally.

Live providers

Managing connections

Connections are managed like any other org resource: list and validate them from the dashboard, rotate the underlying credential on your side (connection.rotate exists as a workflow for exactly this), and delete a connection to sever the grant. Because workflows reference connections, deleting one cleanly breaks the workflows that depend on it — nothing keeps working on a cached credential.