> ## Documentation Index > Fetch the complete documentation index at: https://docs.nebius.com/llms.txt > Use this file to discover all available pages before exploring further. # How to authenticate the Nebius AI Cloud CLI in environments without a browser By default, `nebius profile create` authenticates you through your [federation](/iam/overview#federations), which requires opening the Nebius AI Cloud web console in a browser. In a Docker container, a CI/CD runner or a dev container, there is no browser to open, so the command fails with an error similar to the following: ```plaintext theme={null} Error: get from wrapped tokener: authorize: get code: open browser: exec: "cmd.exe": executable file not found in $PATH ``` To authenticate in such an environment, use one of the following methods: * [Authenticating as a service account](#authenticating-as-a-service-account): the service account reads an authorized key from a file, so no browser and no human are involved. Use this method in CI/CD pipelines and containers. * [Authenticating as a user account without a local browser](#authenticating-as-a-user-account-without-a-local-browser): the CLI prints an authorization link instead of opening it. Use this method when you can open a browser on another machine and reach the environment over the network, for example in a dev container or over SSH. On a Compute virtual machine, you can attach a service account to the VM instead. See [How to work with the Nebius AI Cloud CLI on a Compute virtual machine](/cli/compute-vm). ## Prerequisites 1. [Install and configure](/cli/install) the Nebius AI Cloud CLI. 2. Make sure you are in a [group](/iam/authorization/groups/index) that has the `admin` role within your tenant or project; for example, the default `admins` group. You can check this in the [Administration → IAM](https://console.nebius.com/iam) section of the web console. 3. [Create a service account](/iam/service-accounts/manage#creating-a-service-account) and [add it to a group](/iam/authorization/groups/members#adding-a-service-account) that has the [roles](/iam/authorization/roles) your workload needs, granted within the project that the workload uses. See [Keeping the credentials secure](#keeping-the-credentials-secure). Adding the service account to the default `editors` group is quicker, but grants broad access within the whole tenant. The second and third prerequisites are only needed for the service account method. ## Authenticating as a service account An [authorized key](/iam/service-accounts/authorized-keys) is a key pair that the CLI reads from a credentials file. Because the CLI never needs to open a browser, this method works in fully unattended environments. Perform the first three steps on a machine where you are already authenticated, then move the credentials file to the target environment. 1. Get the ID of the service account and save it to an environment variable: ```bash theme={null} export SA_ID=$(nebius iam service-account get-by-name \ --name \ --format jsonpath='{.metadata.id}') ``` 2. [Get the ID of the project](/iam/manage-projects#cli-3) that the workload uses and save it to an environment variable: ```bash theme={null} export PROJECT_ID= ``` 3. Generate an authorized key and save the credentials to a file: ```bash theme={null} nebius iam auth-public-key generate \ --service-account-id $SA_ID \ --output ~/.nebius/$SA_ID-credentials.json ``` This command creates a key pair, uploads the public key to the service account and writes the credentials, including the private key, to the output file. To limit how long the key remains valid, add the `--expires-at` parameter with the expiration time in RFC 3339 format, for example `--expires-at 2027-01-31T23:59:59Z`. 4. Make the credentials file available in the target environment at runtime. The command in the next step reads the file from `~/.nebius/$SA_ID-credentials.json`, so set the `SA_ID` and `PROJECT_ID` variables in the target environment as well. The target environment also needs the Nebius AI Cloud CLI. [Install it](/cli/install) in the image or at the start of the job, but do not configure a profile for it, because the next step does that from the credentials file. On a minimal image, install `curl` before you run the installation script, and add `~/.nebius/bin` to `PATH` afterwards. In a Docker container, add the mount and the variables to the command that starts the container. The container must run as the user whose home directory you mount into, `root` in this example: ```bash theme={null} docker run \ --env SA_ID \ --env PROJECT_ID \ --volume ~/.nebius/$SA_ID-credentials.json:/root/.nebius/$SA_ID-credentials.json:ro \ ``` In a CI/CD pipeline, store the contents of the credentials file in a secret, then write it to a file at the start of the job: ```bash theme={null} export SA_ID= export PROJECT_ID= mkdir -p ~/.nebius printf '%s' "$NEBIUS_CREDENTIALS" > ~/.nebius/$SA_ID-credentials.json ``` In this example, `NEBIUS_CREDENTIALS` is the secret that holds the contents of the credentials file. 5. In the target environment, create a profile from the credentials file: ```bash theme={null} nebius profile create \ --endpoint api.nebius.cloud \ --service-account-file ~/.nebius/$SA_ID-credentials.json \ --parent-id $PROJECT_ID \ --profile ``` If you made the credentials file available at a different path, specify that path in the `--service-account-file` parameter. **Use one profile per project** Create a separate Nebius AI Cloud CLI profile for each project to ensure correct [region](/overview/regions)-specific configuration. This command neither opens a browser nor prompts for input. You will see the following message: ```plaintext theme={null} profile "" configured and activated ``` 6. Check that the CLI can authenticate with the new profile and reach the project: ```bash theme={null} nebius iam service-account list ``` The command returns the service accounts in the project. It requires a project, so it also confirms that the profile is bound to one. The CLI exchanges the authorized key for a short-lived [access token](/iam/authorization/access-tokens) and refreshes it automatically, so a pipeline job gets a fresh token in every run. For an example of using a service account in a pipeline that works with Container Registry, see [Working in a CI/CD environment](/container-registry/authentication#working-in-a-cicd-environment). ## Authenticating as a user account without a local browser If a browser is available on another machine, add the global `--no-browser` parameter. Instead of launching a browser, the CLI prints the authorization link: ```bash theme={null} nebius profile create \ --endpoint api.nebius.cloud \ --federation-endpoint auth.nebius.com \ --no-browser ``` The command prints a message similar to the following: ```plaintext theme={null} To complete the authentication process, open the following link in your browser: https://auth.nebius.com/oauth2/authorize?client_id=nebius-cli&code_challenge=&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A59998&response_type=code&scope=openid&state= ``` Open the link in a browser and log in to the web console. After you log in, the browser is redirected to the address in the `redirect_uri` parameter of the link, which is a loopback address on the machine that runs the CLI. The browser must be able to reach this address: * If the browser runs on the same machine as the CLI, it works without additional setup. * If the browser runs on another machine, forward the port from the link to the machine that runs the CLI. For example, over SSH: `ssh -L 59998:127.0.0.1:59998 @`. The CLI picks the port at random for every authentication attempt, so take the port number from the printed link each time. The CLI waits for the redirect for 15 minutes; to change this, add the `--auth-timeout` parameter. If the browser cannot reach the machine that runs the CLI at all, as is usually the case with CI/CD runners, authenticate [as a service account](#authenticating-as-a-service-account) instead. ## Keeping the credentials secure The credentials file contains the private key of the service account. Never copy it into a container image with the `COPY` or `ADD` instruction, because anyone who can pull the image can read the key from the image layer. Pass the credentials file to the environment at runtime, as a bind mount or an injected secret. In a CI/CD system, keep the contents of the file in the secret storage of that system rather than in your repository. Rotate the keys regularly: generate keys with the `--expires-at` parameter and [delete the keys](/iam/service-accounts/authorized-keys) that you no longer use. Grant the service account as few permissions as possible. The default `editors` and `admins` groups grant broad access within the whole tenant, so for a pipeline that works with a single project, create a [custom group](/iam/authorization/groups/manage) and assign it only the [roles](/iam/authorization/roles) that the pipeline needs.