Connect your cloud accounts

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. 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).

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:

   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:

#!/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:

   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 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:

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/<name>, 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 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:

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/<name>, 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 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:

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/<name>, 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.

   kubectl create namespace nodus

   Optionally, and only on this new namespace, refuse privileged pods in it:

   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:

   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:

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/<name>, under Pods that may still run, so you can delete them with kubectl delete pod -n <namespace> <name>.

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:

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

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 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:

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:

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.