Docs / Connect your cloud account

Connect your cloud account

LLM Hangar provisions GPU infrastructure inside your own cloud account, so the first step is linking one. Each provider uses its own recommended mechanism for delegated access, and every link is verified live against your account before anything is stored.

AWS

AWS linking uses a cross-account IAM role, not access keys. You never paste a long-lived credential.

  1. In the dashboard, choose Add cloud account, then AWS. We generate a one-time binding for your link.
  2. Follow the CloudFormation quick-create link. It deploys a stack named llmd-access in your account containing a single IAM role that trusts our platform account, bound with a single-use external ID.
  3. When the stack finishes, press Verify. We assume the role once to confirm it works, then record the link.

The external ID is minted per link attempt and can only be bound once. If you unlink and relink later, a fresh binding is generated; the old one cannot be reused.

Nebius

Nebius linking uses a service account with an authorized key, scoped to a single project.

  1. Create a dedicated project for LLM Hangar workloads. Projects are regional; you enter the project's region when linking.
  2. Create a service account in that project.
  3. Generate an authorized key for it, either with nebius iam auth-public-key generate or the console flow, and paste the private key half into the linking form.

The service account needs compute (instances, disks, filesystems, GPU clusters), VPC (networks, subnets, security groups), and read access to the project itself. The project-scoped editor role covers this. Scope everything to the one project, never the tenant.

We verify the key live: it must authenticate and be able to read its own project. A key that fails either check is rejected with a guided message before any credential is stored.

RunPod

  1. In the RunPod console, open Settings and create an API key.
  2. Paste it into the linking form. We verify it against your account before storing it.

How credentials are stored

Credentials are envelope-encrypted: each record has its own data key, wrapped by a KMS root key. Plaintext exists only transiently inside the worker that talks to your cloud provider. It is never written to logs, API responses, or the database in the clear.

Unlinking

Unlinking crypto-shreds the stored credential. It is refused while the account still owns live deployments or stages, because their storage would keep billing you with no way for us to remove it. Destroy those first, then unlink.

Next: deploy a model.