Cloud Credentials

Cloud Credentials authorize Anycloud to provision resources in your AWS, Azure, GCP, or Lambda account. Save multiple named credentials when you want to use several accounts or let Anycloud choose across them.

Cloud credentials are distinct from Secrets: credentials let Anycloud manage infrastructure; secrets become environment variables inside your workload.

Create credentials

The interactive wizard can use local provider tooling, open a provider login, create a least-privilege identity, or accept pasted values:

anycloud credentials new production-aws

For automation, supply the provider fields:

# AWS
anycloud credentials new production-aws --provider aws \
  --access-key-id AKIA... \
  --secret-access-key ...

# Azure
anycloud credentials new production-azure --provider azure \
  --application-id ... \
  --secret ... \
  --subscription-id ... \
  --directory-id ...

# GCP
anycloud credentials new production-gcp --provider gcp \
  --project-id my-project \
  --client-email service-account@my-project.iam.gserviceaccount.com \
  --private-key "..."

# Lambda
anycloud credentials new production-lambda --provider lambda \
  --api-key ...

Provider secret flags also accept their documented environment-variable fallbacks. An explicit flag wins.

anycloud credentials list
anycloud credentials edit production-aws
anycloud credentials delete production-aws

See credentials reference for every field and wizard mode.

Select credentials for compute

Pin a named credential when account choice is part of the workload:

anycloud submit ghcr.io/acme/train:latest \
  --credentials production-aws \
  --gpu-type h100

In Python, pass the name to a Client or CloudConfig:

import anycloud
from anycloud.types import CloudConfig

ac = anycloud.Client(credentials="production-aws")

config = CloudConfig(credentials="production-aws")
job = ac.submit("ghcr.io/acme/train:latest", cloud_config=config, gpu="h100")

Python credential resolution is:

1. An explicit credential object
2. A saved credential name
3. Automatic selection when exactly one saved credential exists

The CLI can leave compute credentials unpinned and let the server compare compatible targets across saved named credentials. That also requires an unpinned region. The Python SDK does not guess when several credentials are saved; pass a name or explicit CloudConfig.

If a pinned credential becomes invalid, the deployment becomes invalid. For an unpinned CLI deployment, Anycloud can temporarily block the failing credential and try another saved credential.

Storage credentials

Same-cloud Bucket access uses the workload VM's cloud-native identity. When a Bucket belongs to a different account, give it a separate storage credential:

anycloud submit ghcr.io/acme/train:latest \
  --credentials compute-account \
  --input-bucket training-data \
  --input-storage-credentials storage-account \
  --input-storage-region us-east-1

Input, output, and checkpoint storage identities are independent. See Buckets.

Local security model

Saved cloud credentials live in the local Anycloud API database at ~/.anycloud/api.db. They are encrypted at rest with libsodium (XSalsa20-Poly1305) using a locally generated key at ~/.anycloud/cipher.key. Anycloud communicates directly with the cloud provider rather than sending the credentials to an Anycloud-hosted service.

Each deployment receives a unique ED25519 SSH keypair. The private key remains encrypted in the local API database; commands such as anycloud exec ask the API to perform the SSH operation rather than returning the key to the CLI.

Same-cloud storage uses VM identities instead of putting long-lived provider keys inside the container. Cross-cloud S3 sync uses a scoped, expiring STS token.