# Connect your cloud accounts > Give Nodus read-only access to AWS, GCP or Azure (Beta) to list GPU instances, spend, credits and GPU quota, see every account on one page, enroll instances into pools, run work in your own AWS account, GCP project, Azure subscription, Kubernetes namespace or cloud account with its API key (Beta) and revoke access at any time. Source: https://www.nodus-compute.ai/docs/guides/pools/cloud-accounts/ Build revision: 4ebfc6023eeed1bd55d9969af1612182a7b0c7ff A cloud account gives Nodus read-only access to your AWS account, GCP projects or Azure subscription. Nodus lists your instances, their GPUs and your monthly spend, and you can enroll an instance into a [pool](https://www.nodus-compute.ai/docs/guides/pools/). The read-only connection never creates, changes or deletes anything in your account. Connecting a cloud account is free. You can also let Nodus run your work in a connected AWS account, GCP project or Azure subscription, or in a cloud account you connect with its API key, so Nodus spends your cloud credits before Nodus capacity (Beta, see [Run work in your own account](https://www.nodus-compute.ai/docs/guides/pools/cloud-accounts/#run-work-in-your-own-account-beta)). ## Connect AWS AWS access is a role in your account that only Nodus can assume, and only with an external id unique to your cloud account. 1. In the console, open **BYOCompute › Spend › Manage cloud accounts**, choose **Connect cloud** and then **AWS**, and choose **Continue to AWS**. You do not need your account ID: Nodus names the connection and prepares the role for you. To connect one particular account, open **Connect a specific account ID** first. Or create it from the CLI: Terminal window ```sh nodus create cloudaccount aws-main --provider aws --account-id 123456789012 ``` 2. In the AWS tab, review the prefilled CloudFormation template, acknowledge the IAM permissions and choose **Create stack**. If the tab did not open, choose **Open AWS again** in Nodus. You can also read the template with `nodus cloud onboarding aws-main`. The stack creates a role whose policy allows only these calls: |Call|Used for| |-|-| |`ec2:DescribeRegions`, `ec2:DescribeInstances`, `ec2:DescribeInstanceTypes`|Instances and their GPUs| |`ce:GetCostAndUsage`|Daily spend| |`billing:GetCredits`|Credit left and when it expires| |`servicequotas:GetServiceQuota`|GPU instance quotas| 3. When the stack shows `CREATE_COMPLETE`, open its **Outputs** tab and follow the **ReturnToNodus** link. It tells Nodus which account the stack ran in. If you entered the account ID in step 1, there is no link and nothing to do. If the link does not open, enter the ID under **Already finished in AWS?** instead. Nodus saves the role ARN, checks access automatically and opens your account when it has read your instances. There is nothing to copy. A failed check shows the reason while AWS finishes applying the permissions. Checks pause after ten minutes; **Check again** resumes the saved connection. Retrying setup reuses the existing account and its trust identity. If monitoring connects but execution cannot be verified, the account keeps your spending settings and shows what needs attention under **Execution**. Repair the grant there before expecting work to run in the account. ## Connect GCP GCP access is an OAuth grant limited to read-only scopes: `compute.readonly`, `bigquery.readonly` (for a billing export) and `cloud-platform.read-only`. 1. Choose **Google Cloud**, then **Continue with Google**. No account name, project ID or service account key is required. If you already know the IDs, you can enter them under **Advanced** instead. 2. Approve read-only access on Google’s page. Nodus lists the projects you can access. Choose the projects to connect, then choose **Connect projects**. Only those projects are imported. The person who signs in must complete this selection within 15 minutes. If it expires, sign in again to resume the saved connection. Nodus refuses grants with broader scopes and encrypts the stored authorization. 3. Inventory is imported independently of billing. For spend reports, enable a Cloud Billing export in the first configured project’s **nodus_billing** BigQuery dataset. The consenting Google user needs **BigQuery Job User** on that project and **BigQuery Data Viewer** on the export. Nodus detects the export table; connecting does not create an export or backfill billing history that Google has not supplied. ## Connect Azure Beta Connecting Azure is in Beta. Azure access is the Nodus app, admitted to your Microsoft Entra directory with read-only roles on one subscription. Nodus holds no secret for it: no client secret, certificate or key is created. 1. Choose **Azure** and enter your **Directory ID** and **Subscription ID**, then choose **Continue to Azure**. 2. Open **Azure Cloud Shell** (Bash) as an Owner of the subscription, paste the script shown and run it. It admits the Nodus app to your directory with no API permission, gives it the **Reader** and **Cost Management Reader** roles on that subscription only, and tags the subscription with a name unique to this connection, which tells Nodus the subscription is yours. It prints `Done` when it finishes. 3. Return to Nodus. It checks access automatically and opens the subscription when the first sync passes. Checks pause after ten minutes; **Check again** resumes the saved connection. Nodus reads the subscription’s virtual machines, its daily actual cost by service, and its GPU vCPU quotas in eastus, eastus2, southcentralus, westus2 and westus3. With the Reader role it can read every resource in the subscription, and it creates, changes and deletes nothing. ## Run work in your own account (Beta) Beta Running work in your own cloud account is turned on per organization. Ask Nodus support to turn it on. Connect a cloud account with its API key and a credit limit. Nodus then places your Jobs, Workspaces and other single-node work in that account first, up to the limit, and uses Nodus capacity when the account is full or out of credit. Sandboxes, CPU-only machines and multi-node runs use Nodus capacity, and work that names a pool keeps to that pool’s routing. Review the terms shown before enabling routing. Nodus creates, labels and deletes only its own machines there and never reads or changes anything else in the account. Each cloud takes these fields. Create the key in the cloud’s console with permission to create and delete machines. The first field is the secret; the CLI reads it from `--key-env` or standard input, and takes the others with `--ssh-key` or `--field name=value`. |`spec.provider`|Key fields|What to give| |-|-|-| |`Lambda`|`apiKey`, `sshKeyName`|An API key, and the name of an SSH key registered in the account (`--ssh-key`).| |`RunPod`|`apiKey`|An API key.| |`DigitalOcean`|`token`, `sshKeyFingerprint`|A personal access token with read and write scope, and the fingerprint of an SSH key in the account (`--ssh-key`).| |`Thunder`|`apiToken`|An API token.| |`Nebius`|`privateKeyPEM`, `serviceAccountID`, `publicKeyID`, `projectID`, `region`, optional `subnetID`|A service account in the project’s editors group and its key: `nebius iam auth-public-key generate` writes a `credentials.json` whose `private-key`, `iss` and `kid` are the first three. Then the project your credits are in, its region (`eu-north1`, `eu-north2`, `eu-west1`, `me-west1` or `us-central1`) and a subnet, which you may leave out when the project has only one. Nodus checks the region against the project and creates machines only in that project. The CLI reads the private key from `--key-env` or a pipe, since it spans several lines.| |`Denvr`|`apiKey`, `cluster`, optional `vpc`|An API key, the cluster your credits or quota are in (`Msc1` or `Hou1`) and, optionally, a VPC; without one Nodus uses the cluster’s default VPC. Nodus offers only the machine types whose operating system image your account lists.| |`Jarvis`|`apiKey`, `scriptID`|An API key billed in US dollars, and the id of a startup script you add once in the account with the content below. The console shows the same script to copy.| |`MassedCompute`|`apiKey`|An API key.| Nodus checks the key and these settings before it accepts them: a project, subnet, VPC or script the account does not have is refused with the field’s name. The `Jarvis` startup script hands each machine the setup Nodus passes it: ```sh #!/bin/sh set -eu [ "$#" -eq 1 ] || exit 64 bootstrap=$(mktemp) trap 'rm -f "$bootstrap"' EXIT printf '%s' "$1" | base64 -d > "$bootstrap" sh "$bootstrap" ``` 1. In the console, open **Cloud accounts** and choose your cloud under **Or connect a GPU cloud or Kubernetes cluster**. Paste the key and set the credit limit. Or connect from the CLI, which reads the key from an environment variable or standard input and never from the command line: Terminal window ```sh nodus cloud connect lambda my-lambda --credit-limit 500 --ssh-key my-key --key-env LAMBDA_API_KEY nodus cloud connect nebius my-nebius --credit-limit 2000 --key-env NEBIUS_PRIVATE_KEY \ --field serviceAccountID=serviceaccount-… --field publicKeyID=publickey-… \ --field projectID=project-… --field region=eu-north1 ``` 2. Nodus checks the key with one read, stores it encrypted and never shows it again. The account’s **Execution** section shows whether it takes work, the credit used and left this period, and the machines running there. 3. Run your work as usual. On the job page, **Attempts › Ran on** says whether each attempt ran in your account or on Nodus capacity. The credit limit is spent at Nodus’s list estimate for each offering, which can differ from what your cloud bills you, so leave some margin below the credit you hold: `--period Monthly` (the default) renews it each calendar month in UTC, and `--period Total` spends it once. Resetting this allowance does not add funds to your cloud account. When the credit runs out, Nodus stops the work in your account and continues it where `--burst` allows: |`--burst`|When the account is full or out of credit| |-|-| |`Allow` (default)|Work runs on Nodus capacity at Nodus rates.| |`Approve`|A Job waits until you approve it with `nodus request approve-burst`; Workspaces and other work run on Nodus capacity.| |`Deny`|Work waits for your account.| With several accounts connected, `--priority` sets the order Nodus spends them in: work goes to priority 1 first, then 2, and an account without a priority comes after every numbered one. Accounts with the same priority, or none, go to whichever has the cheapest machine for the work. Change it under **Order** on the account’s Execution card. To change it later, choose **Use Nodus capacity**, **Ask me first** or **Wait for my account** under **When the account cannot take the work** on the account’s Execution card. Jobs waiting for your approval appear under **BYOCompute → Execution → Approvals** with **Allow burst** and **Keep waiting**. If the cloud refuses the key, the account shows `ExecuteReady=False` with `CredentialsRejected` and Nodus places nothing there. Create a new key and choose **Save key**, or run `nodus cloud connect` again. ### Run work in a connected AWS account An AWS account you [connected](https://www.nodus-compute.ai/docs/guides/pools/cloud-accounts/#connect-aws) can run your work too, billed to its AWS credits. It needs a second role, separate from the read-only one, that lets Nodus launch and terminate only its own machines. 1. Open the account in the console and, under **Run work here**, set a monthly credit limit and choose **Let Nodus run work here**. 2. Choose **Open the AWS execute stack**, review the prefilled template, acknowledge its IAM permissions and choose **Create stack**. The stack creates the role, a machine profile with no permissions and one security group in your default VPC whose only inbound rule is SSH from Nodus, used while a machine starts. 3. When the stack shows `CREATE_COMPLETE`, choose **Start running work here**. Nodus assumes the role once and checks for the security group. The **Execution** section then shows the credit used and left and the machines running. From the CLI, once the stack shows `CREATE_COMPLETE`: Terminal window ```sh nodus cloud connect aws aws-main --credit-limit 500 ``` The role can launch only machines tagged `nodus-managed`, with that security group in its VPC, an Amazon image, IMDSv2, no key pair and the permissionless machine profile, and can rename and terminate only machines with that tag. It can read your instance, network and image descriptions, since AWS allows no narrower read, and Nodus acts only on its own tagged machines. Machines run in the stack’s region among us-east-1, us-east-2 and us-west-2. If AWS refuses a machine because the account’s GPU quota for that machine family is used up, Nodus skips that family in that region for an hour and runs the work elsewhere. The account’s **Execution** section says so; choose **Request more** next to the quota under **Credits and GPU quota** to ask AWS for more. To stop, disconnect the account in Nodus first. Nodus stops placing work there, moves running work to the next source and terminates the machines it started. Once the account is gone from Nodus, delete the execute stack in AWS. If you delete the stack first, Nodus can no longer terminate its machines; it then lists them on the account page and in `nodus describe cloudaccount/`, under **Machines that may still run**, so you can terminate them in the AWS console. ### Run work in a connected GCP project A GCP account you [connected](https://www.nodus-compute.ai/docs/guides/pools/cloud-accounts/#connect-gcp) can run your work in one of its selected projects too, billed to its Google Cloud credits. Nodus holds no key for it: it sets up a service account that only Nodus may act as, and acts as it with short-lived tokens. Use a project dedicated to this work if you can: while the grant is in place, Nodus can list the project’s instances, including their names, labels and metadata. 1. Open the account in the console and, under **Run work here**, set a monthly credit limit, pick the project if the account has several, and choose **Let Nodus run work here**. 2. Choose **Set up with Google** and sign in as an owner of the project. Nodus turns on the compute and IAM credentials APIs and creates a network with no firewall rule, a service account and the custom roles bound to it. It uses the sign-in for this setup only, keeps none of it, and revokes it when the setup ends. 3. The account page shows **Setting up Nodus in your project** while Google turns the new access on, which can take a few minutes, then the **Execution** section shows the credit used and left and the machines running. If Google refuses a step, for example because billing is off in the project, the page shows Google’s reason. If you cannot sign in as a project owner, open **Run a script in Cloud Shell instead**: have an owner run the script shown in Cloud Shell until it prints `Done`, then choose **Start running work here**. Nodus acts as the service account once and checks for the network. From the CLI, once the script prints `Done`: Terminal window ```sh nodus cloud connect gcp gcp-lab --credit-limit 500 --gcp-project lab-ml-prod ``` `--gcp-project` is needed only when the account has more than one selected project. The script creates two roles. The first can create, read and delete machines and their boot disks, under a condition that admits only names starting with the one Nodus picked for this account, so it can never reach a machine of yours. The second can use only the new network’s subnets, so Nodus cannot place a machine in your own networks. Listing cannot be narrowed that way: Nodus can list every instance in the project and acts only on the ones it created. Machines get no service account and no SSH key, run as Shielded VMs on a public image in the new network, and take no inbound connection. Machines run in us-central1, us-east1, us-east4 and us-west1. If Google Cloud refuses a machine because the project’s GPU quota is used up, Nodus skips that GPU model in that region for an hour, or every region when the all-regions GPU quota is used up, and runs the work elsewhere. The account’s **Execution** section says so; choose **Request more** next to the quota under **Credits and GPU quota** to ask for more. A zone out of machines is not a quota: Nodus tries the region’s other zones first. To stop, disconnect the account in Nodus first. Nodus stops placing work there, moves running work to the next source and deletes the machines it started. Once the account is gone from Nodus, delete the service account, both roles and the network in the project. If you delete the service account first, Nodus can no longer delete its machines; it then lists them on the account page and in `nodus describe cloudaccount/`, under **Machines that may still run**, so you can delete them in the Google Cloud console. ### Run work in a connected Azure subscription An Azure subscription you [connected](https://www.nodus-compute.ai/docs/guides/pools/cloud-accounts/#connect-azure) can run your work too, billed to its Azure credits, such as startup credits. Nodus holds no secret for it: it signs in to your directory as the Nodus app, through a federated credential of Nodus’s own. 1. Open the subscription in the console and, under **Run work here**, set a monthly credit limit, pick the region Nodus runs machines in, and choose **Let Nodus run work here**. 2. Choose **Open Azure Cloud Shell** as an Owner of the subscription, paste the script shown and run it. It creates a resource group, a network in it whose security group denies all inbound traffic, and a custom role that can act only in that resource group, assigned to the Nodus app there. It prints `Done` when it finishes. 3. Choose **Start running work here**. Nodus signs in once and checks for the resource group’s network and that the custom role reaches it. A new role assignment can take a few minutes to take effect; if the check says the role assignment was not found, wait a few minutes and choose it again. The **Execution** section then shows the credit used and left and the machines running. From the CLI, once the script prints `Done`: Terminal window ```sh nodus cloud connect azure azure-main --credit-limit 1000 ``` The role can create, read and delete virtual machines, their disks, network interfaces and public addresses, and use the new network, all only in that resource group: it changes nothing in any other resource group. The Reader role from connecting still lets Nodus read the rest of the subscription, and together the two roles let a disk in the resource group be made from any image or snapshot in the subscription. Nodus boots only its own marketplace image, but if the subscription holds images or snapshots you keep private, run work in a subscription dedicated to Nodus. Nodus names every machine it creates after the resource group, tags it, and acts only on machines with both, so keep nothing else in the resource group. Machines get no managed identity and no usable SSH key, take no inbound connection, and are deleted with their disk, network interface and address. If Azure refuses a machine because the subscription’s vCPU quota is used up, Nodus skips that GPU family in that region for an hour, or every size in the region when the regional quota is used up or Azure does not say which quota, and runs the work elsewhere. The **Execution** section says so; choose **Request more** next to the quota under **Credits and GPU quota** to ask for more. A size the region has no capacity for is not a quota: Nodus runs the work elsewhere and tries the size there again later. To stop, disconnect the account in Nodus first. Nodus stops placing work there, moves running work to the next source and deletes the machines it started. Once the account is gone from Nodus, delete the resource group, the custom role and the Nodus enterprise application. Deleting the resource group deletes every machine in it. If you remove the role assignment first instead, Nodus can no longer delete its machines; it then lists them on the account page and in `nodus describe cloudaccount/`, under **Machines that may still run**, so you can delete them in the Azure portal. ### Run work in your Kubernetes cluster Beta Running work in your own Kubernetes namespace is in Beta and turned on per organization. Nodus checks and stores your kubeconfig today, but places work there only once its tests against a live cluster pass; until then the account shows `NotAdmitted` and your work runs elsewhere. If you hold reserved GPUs in a managed Kubernetes cluster, Nodus can run your work there first, as pods in one namespace. Each pod asks for whole GPUs on the nodes you pick and runs your work’s own image. You keep paying for the cluster as you do today; Nodus meters the credit limit at the hourly rate per GPU you enter. 1. Make a namespace only for Nodus, and keep nothing else in it: pods Nodus creates there can mount any Secret in the namespace. Nodus refuses `default` and `kube-` namespaces. Terminal window ```sh kubectl create namespace nodus ``` Optionally, and only on this new namespace, refuse privileged pods in it: Terminal window ```sh kubectl label namespace nodus pod-security.kubernetes.io/enforce=baseline ``` 2. In the console, open **BYOCompute › Clouds**, choose **Kubernetes**, and name the namespace, the country the cluster runs in, and each GPU type with your hourly rate per GPU and the node labels that pick its nodes, such as `nvidia.com/gpu.product=NVIDIA-H100-80GB-HBM3`. Labels are required when you list more than one type. 3. Apply the manifest the page shows with your own kubectl context (`kubectl apply -n nodus -f nodus.yaml`). It holds no namespace, so deleting it later leaves the namespace in place: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: nodus namespace: nodus --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: nodus namespace: nodus rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list", "delete"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get"] - apiGroups: [""] resources: ["secrets"] verbs: ["create", "patch", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: nodus namespace: nodus subjects: - kind: ServiceAccount name: nodus namespace: nodus roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: nodus --- apiVersion: v1 kind: Secret metadata: name: nodus-token namespace: nodus annotations: kubernetes.io/service-account.name: nodus type: kubernetes.io/service-account-token --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: nodus-deny-ingress namespace: nodus spec: podSelector: matchLabels: nodus-managed: "true" policyTypes: ["Ingress"] ``` 4. Run the commands the page shows to write the ServiceAccount’s kubeconfig to `nodus.kubeconfig`, paste it, set a credit limit and choose **Connect namespace**. Nodus checks the Role with read-only calls and changes nothing. From the CLI, after applying the manifest and writing the kubeconfig: Terminal window ```sh nodus cloud connect kubernetes gpu-cluster --kubeconfig-file nodus.kubeconfig --namespace nodus \ --gpu H100-SXM=2.10,nvidia.com/gpu.product=NVIDIA-H100-80GB-HBM3 --credit-limit 2000 ``` The CLI sends only the current context’s API server address, certificate authority and token, never the rest of the file. Nodus keeps only those three, encrypted, and never shows them again. It takes only a ServiceAccount token over `https` with an embedded certificate authority: a kubeconfig that runs a login plugin, names a certificate file or skips TLS verification is refused. What the manifest lets Nodus do: * Create, list and delete pods, and read their logs, in that namespace. The token must have no access elsewhere: Nodus refuses a token that may list pods in every namespace or create pods in `kube-system`, such as a cluster administrator’s. If you also let the ServiceAccount list nodes, Nodus checks that each GPU type’s labels match nodes with GPUs; without that, it takes the types as you declared them. * Create, patch and delete Secrets in that namespace. Nodus uses them for each pod’s start-up token and image pull credential, and changes only Secrets carrying its own labels. It cannot read Secrets through the API, but a pod it creates can mount any Secret in the namespace, which is why the namespace must hold nothing else. * Nodus names its pods `nodus-…` and labels them. It lists and reads only pods with both, and deletes only its own pods it has read. Pods mount no ServiceAccount token and are never privileged. * The NetworkPolicy lets no inbound connection reach Nodus pods, where your cluster’s network plugin enforces NetworkPolicy. Outbound traffic stays open, since pods reach Nodus and your image registry; add your own egress policy if your cluster needs one, allowing those. If no node has room for a pod, it waits up to 10 minutes for your cluster’s autoscaler to add one (set `spec.kubernetes.scaleUpWaitMinutes`, or `--scale-up-wait`, from 0 for a fixed-size pool to 20), then Nodus deletes it and runs the work elsewhere. If the namespace’s ResourceQuota refuses a pod, Nodus skips that GPU type in the namespace for an hour. If the cluster refuses the ServiceAccount itself, because its token, Role or binding is gone, Nodus stops placing work there and the account page asks for a new kubeconfig. To stop, disconnect the account in Nodus first. Nodus stops placing work there, moves running work to the next source and deletes the pods it started. Once the account is gone from Nodus, delete the manifest (`kubectl delete -n nodus -f nodus.yaml`), which revokes the token and leaves the namespace. If you delete the manifest first, Nodus can no longer delete its pods; it then lists them on the account page and in `nodus describe cloudaccount/`, under **Pods that may still run**, so you can delete them with `kubectl delete pod -n `. ## See all your clouds in one place Open **BYOCompute › All clouds** for every connected account on one page: the credit left and when it expires, spend this month, the GPUs running and the GPU quota, with totals across accounts. Credit that expires within 30 days is called out at the top, so you can run work there first. `nodus get cloudaccounts` shows the same credit in its **Credit-Left** column. Nodus works out each account’s credit on every sync: |Account|Credit left| |-|-| |AWS|The balance AWS reports for credits that can pay for compute, and the earliest expiry among them.| |GCP, Azure, or AWS without a reported balance|The amount you state, less the spend Nodus observes from the day you state it.| |Connected with an API key|The credit limit, less the work Nodus ran there this period. You state only when it expires.| To state an amount, open the account and fill in **Credit left today** and **Expires on** under **Credits and GPU quota**, or from the CLI: Terminal window ```sh nodus patch cloudaccount/gcp-lab --patch '{"spec":{"credits":{"amountUSD":"2000","expireTime":"2026-12-31T00:00:00Z"}}}' ``` Change the amount whenever your cloud’s billing page shows a new balance; Nodus counts down from the new figure. Credit is your cloud’s money: it is an estimate between your cloud’s billing updates, and it never becomes Nodus credit. **GPU quota** is the most GPU capacity your cloud lets the account run at once. AWS counts the vCPUs of its G and P instance families per region, On-Demand and Spot; an 8-GPU machine takes 96 to 192 of them. GCP counts GPUs per model and region, and across all regions, with how many are in use. Azure counts the vCPUs of each GPU family per region, with how many are in use. **Request more** opens your cloud’s quota page. An AWS account connected before credits and quotas were shown keeps working; update its stack with the template from `nodus cloud onboarding NAME` to read them, or state the credit yourself. ## See inventory and spend Terminal window ```sh nodus get cloudaccounts nodus cloud inventory aws-main ``` Nodus syncs inventory hourly and spend daily. Open an account to see its observed month-to-date charges, service breakdown and daily amounts. The first spend sync reads the previous 35 days plus today’s partial day, so connecting in the middle of a month includes the earlier charges. Currencies stay separate; Nodus does not convert them. Missing days remain unknown. The date of the last successful observation stays visible when a refresh fails. AWS amounts use Cost Explorer’s unblended cost. GCP amounts use cost plus credits from the billing export, filtered to the connected projects. Charges outside those projects, including unassigned charges, are excluded. Azure amounts use Cost Management’s actual cost for the subscription. None is a final invoice. You continue paying your cloud directly; these amounts are separate from your Nodus balance. ### Forecast your spend The next-30-day estimate extends the recent daily average across at least seven consecutive usable billing days. Missing days and negative billing adjustments prevent a projection. AWS non-estimated observations are preferred; provisional AWS and GCP projections exclude today and yesterday to allow for reporting lag. Each projection shows its source, history length and last included date. It assumes the recent spending pattern continues. The compute-service subtotal includes CPU and related service charges. It is not a GPU-only bill or a measured cost for an individual workload. A separate compute projection appears only when the source supports it. These cloud-bill projections are distinct from a pool’s paid Predict capacity forecasts. ### Compare a workload Choose **Compare a workload with Nodus**, select matching capacity, and enter your current cost for the same workload after discounts. Enter its expected runtime on Nodus and any additional transfer, storage or ongoing commitment costs. Nodus requests a Job estimate that includes startup and shutdown; it does not start compute. The difference can be a saving or an additional cost. Changing inputs or an expired quote requires a fresh estimate. This comparison does not assume that your entire cloud bill can move to Nodus. Check that the hardware, runtime and work performed are comparable before making a migration decision. ### Run on an observed instance The **Inventory** section lists each instance and whether it is enrolled. Choose **Enroll instance**, select a private pool in your current project, and create an install command. Run it as root on that instance. The command contains a single-use token valid for 24 hours and associates the resulting node with the observed cloud account and instance. See the [host prerequisites](https://www.nodus-compute.ai/docs/guides/pools/#enroll-a-host) before installing. The installer checks the container runtime and GPU requirements before using the token. Connecting a cloud account grants observation only. Installing the agent grants execution on that host for your organization. Neither action offers capacity to other Nodus customers. ## Revoke access Disconnecting stops observation at once and deletes the credential Nodus stored: Terminal window ```sh nodus delete cloudaccount/aws-main ``` Then revoke it on your side too: * **AWS**: once the account is gone from Nodus, delete the CloudFormation stacks, which delete the roles. * **GCP**: remove Nodus from your Google account’s third-party access. * **Azure**: once the account is gone from Nodus, delete the Nodus enterprise application from your directory, and the execute resource group and its custom role if you created them. * **An account connected with an API key**: Nodus stops placing work there at once, moves running work to the next source and deletes its machines, then forgets the key. Delete the key in the cloud’s console too. If you revoke access on your side first, the next sync marks the account `Synced=False` with `GrantRevoked`, and the account’s members get one email about it. ## Finish an interrupted connection An account can appear in the list before cloud access is approved. **Finish setup** means customer approval or project selection is still needed. **Checking access** means a verification request is outstanding. **Connected** means observation access is verified for the current account configuration; permission to run workloads is shown separately. Inventory appears after verification and a successful sync. Open the account and choose **Continue setup** to resume it without creating another account. For CLI setup, copy the command shown on the account page, or run: Terminal window ```sh nodus cloud onboarding ACCOUNT --org YOUR_ORG ``` Follow the returned provider approval URL or script, then return to Nodus to finish setup. This command requires a current CLI version and a signed-in account with permission to manage the organization’s cloud accounts. If Google says the app is being tested and only developer-approved testers can access it, the Nodus operator must add your Google sign-in address to the OAuth app’s test audience. Retrying, changing project IDs, or enabling billing does not remove that audience restriction. Public access requires the app’s applicable Google verification and publishing steps.