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. Three one-time steps in the console at console.nebius.com; scope everything to the one project, never the tenant.

Step 1: create a dedicated project

  1. Create a new project used only for LLM Hangar workloads. Projects are regional; the region shown on the project (like eu-north1) goes in the linking form.
  2. Copy the tenant ID and the project ID. Each has a copy icon next to it in the console.

Step 2: create a service account

  1. In the project, open IAM, then Service accounts, and create a new service account.
  2. Give it the project-scoped editor role. That covers what deployments need: compute (instances, disks, filesystems, GPU clusters), VPC (networks, subnets, security groups) and read access to the project itself. Grant nothing outside the project.
  3. Copy the service account ID (starts with serviceaccount-).

Step 3: generate an authorized key

The console does not generate the key pair for you: you create it on your own machine and upload only the public half.

  1. Generate a key pair: openssl genrsa -out private.pem 4096
  2. Extract the public half: openssl rsa -in private.pem -pubout -out public.pem
  3. On the service account's page, click Upload authorized key, attach public.pem, and upload it.
  4. Copy the public key ID from the Authorized keys tab (starts with publickey-).
  5. Paste the full contents of private.pem into the linking form's private key field. The private half never goes to Nebius; the public half never goes in the form.

If you use the Nebius CLI instead, nebius iam auth-public-key generate --service-account-id <id> --output key.json creates and uploads the key in one step; the file it writes holds the private key and the key ID.

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.

Verda

Verda (formerly DataCrunch) uses OAuth client credentials from the Verda console: open Credentials in the sidebar, then Cloud API credentials, and click Create. Paste the client id and secret into the linking form; we verify them by exchanging a token before anything is stored. The Connect Verda page explains how deployments and storage work in your project.

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 permanently removes the stored credential. First delete deployments and retained stages in that account, so their resources do not keep billing after LLM Hangar loses access.