"Could Not Load Credentials From Any Providers" (AWS SDK for JavaScript v3), Fixed: Local, SSO, Docker, GitHub Actions, Lambda, ECS, Browser and LocalStack

"CredentialsProviderError: Could not load credentials from any providers" means the AWS SDK for JavaScript v3 checked every place it looks for credentials and found none it could use. In Node.js it tries, in order: environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY), AWS IAM Identity Center (SSO), the shared ~/.aws/config and credentials files for the profile in AWS_PROFILE (or default), a credential process, a web identity token file, and finally the ECS container and EC2 instance metadata services. The fix depends on where your code runs: on your laptop, set AWS_PROFILE to a profile that exists and run aws sso login if it uses SSO; in Docker, pass environment variables or mount ~/.aws, and on EC2 raise the metadata hop limit to 2; in GitHub Actions, use aws-actions/configure-aws-credentials with an OIDC role; on Lambda, ECS and EC2, attach an IAM role; with LocalStack, set any dummy keys. In a browser there is no default chain at all, so you must supply credentials, usually through Amazon Cognito. Below: a one-minute test that shows which source is failing, then each environment step by step.

Ethan wrote a small Node.js script for Jake's computer shop: every night it uploads the day's repair photos to S3. On his laptop it worked perfectly. Copied to the back-room PC in a Docker container, it died with "Could not load credentials from any providers." Moved to GitHub Actions for a test, it died with the same words. Same code, same error, three different causes. The message is the SDK saying "I looked everywhere I know," and the fix is always about which of those places should have had the answer.

Using Python, Java, the CLI or Terraform instead? The same problem has its own page for each; see our CLI credentials guide and the cards below.

How the SDK looks for credentials (the provider chain)

When you create a client such as new S3Client({}) without passing credentials, the SDK uses its default credential provider chain: a list of places to look, tried in order until one returns usable credentials. In Node.js, version 3 of the SDK checks:

1. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and, for temporary credentials, AWS_SESSION_TOKEN.
2. IAM Identity Center (SSO): a profile configured for SSO, with a valid login cached by aws sso login.
3. Shared config and credentials files: ~/.aws/credentials and ~/.aws/config, for the profile named in AWS_PROFILE, or default. A profile can hold keys, or point to a role to assume, a credential process, or another source.
4. Login credentials: credentials from the CLI's newer sign-in flow.
5. A credential process: an external program named in the config that prints credentials.
6. A web identity token file: AWS_WEB_IDENTITY_TOKEN_FILE plus AWS_ROLE_ARN, used by Kubernetes (EKS) service accounts and some CI systems.
7. ECS container credentials: the task role, through variables ECS sets for you.
8. EC2 instance metadata: the instance profile role, from the metadata service at 169.254.169.254.

"Could not load credentials from any providers" means every one of those came back empty. The useful question is never "why can't it find credentials" in general, but "which of these should have provided them here, and why didn't it?" On a laptop that is usually step 2 or 3; in a container, step 1 or 8; in CI, step 1 or 6.

One difference from the older SDK (version 2) catches people migrating old code: v3 reads ~/.aws/config automatically, so AWS_SDK_LOAD_CONFIG=1 is no longer needed and does nothing. Region is a separate setting; a missing Region produces a different error ("Region is missing"), not this one.

The environment variables the SDK reads

A quick way to see which of these exist where your app runs: env | grep ^AWS_ on macOS and Linux, or Get-ChildItem Env:AWS_* in PowerShell. A stray AWS_ACCESS_KEY_ID from an old experiment silently wins over everything else in the chain, so this check also finds the opposite problem: the "wrong" credentials being used.

Find the failing source in one minute

Before changing anything, test the chain on its own, outside your application. Save this as whoami.mjs next to your project (it uses the packages your app already has, or npm install @aws-sdk/credential-providers @aws-sdk/client-sts):

import { fromNodeProviderChain } from "@aws-sdk/credential-providers";
import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";

const creds = await fromNodeProviderChain()();
console.log("Found keys starting", creds.accessKeyId.slice(0, 4), "expires", creds.expiration ?? "never");

const sts = new STSClient({ region: process.env.AWS_REGION || "us-east-1" });
console.log(await sts.send(new GetCallerIdentityCommand({})));

Run it with node whoami.mjs in exactly the environment that fails: the same terminal, container or CI job. Three possible outcomes:

• It prints an identity (an ARN). Credentials load fine in this environment; your application is overriding them (passing empty credentials, a wrong profile, or a different environment). Search your code for credentials: and profile:.
• It fails with the same error. The environment has no usable credentials; read the section for where it runs.
• Credentials load but GetCallerIdentity fails (expired token, invalid signature). The source was found but its credentials are stale or wrong; refresh them.

Key prefixes help too: AKIA means long-term access keys; ASIA means temporary credentials (SSO, roles, metadata), which expire.

Jake: "So the script tells you which drawer is empty?"

Ethan: "It tells me whether any drawer has a key. Then I know whether to blame the computer or my code."

On your own computer: profiles and SSO

Most laptop failures come down to the profile:

• No profile named. With no AWS_PROFILE, the SDK uses default. If your credentials live under a named profile, such as [profile shop], set it: export AWS_PROFILE=shop on macOS and Linux, $env:AWS_PROFILE="shop" in PowerShell, or set AWS_PROFILE=shop in Command Prompt.
• A profile name typo, or the wrong file format. In ~/.aws/config, named profiles are written [profile shop]; in ~/.aws/credentials they are written [shop]. Mixing them up means the SDK cannot find the profile. Our config vs credentials guide shows the rules side by side.
• An expired SSO login. SSO profiles need a fresh login every so often: aws sso login --profile shop. When the cached login has expired, the SSO step fails, and if nothing else in the chain has credentials, you get this error.
• Running as a different user. sudo node app.js, a Windows service or a scheduled task runs as another user, with another home folder and no ~/.aws. Point it at the files with AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE, or run it as your user.
• Environment variables set in one terminal only. A variable exported in one terminal is not seen by an app started from an IDE, a different terminal, or a process manager such as PM2. Set it where the app is actually launched.

To confirm what the CLI sees with the same profile, run aws sts get-caller-identity --profile shop. If the CLI works and Node does not, compare the environment the two run in: the profile setting is nearly always the difference.

Setting up an SSO profile for Node.js, start to finish

If your company uses IAM Identity Center (SSO), which is the recommended way to work locally, a profile set up once covers the CLI and every SDK, including JavaScript v3:

1. Run aws configure sso and answer the prompts: a session name, your organization's start URL, its Region, then pick the account and role. Give the profile a short name such as shop.
2. Check the result in ~/.aws/config: an [sso-session ...] section with the start URL, and a [profile shop] section that refers to it with sso_session, sso_account_id and sso_role_name.
3. Log in: aws sso login --profile shop opens your browser; approve, and the login is cached on disk.
4. Point Node at the profile: export AWS_PROFILE=shop (or the PowerShell equivalent), plus AWS_REGION.
5. Verify with the test script above; it should print your role's ARN.
6. When it stops working one morning, repeat step 3. SSO logins expire after the session length your organization sets, and an expired login is the single most common cause of this error on developer machines.

Once the login is cached, the SDK exchanges it for short-lived role credentials and refreshes them as needed while the login lasts; you do not copy any keys anywhere.

In Docker: no home folder, no metadata, or both

A container starts with an empty home directory and its own network, so the two sources that work on a laptop (files) and on EC2 (metadata) can both disappear. Choose one approach:

• Pass environment variables: docker run -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN -e AWS_REGION myimage. Writing -e NAME without a value copies it from your current shell, so the keys never appear in your command history.
• Mount your AWS folder read-only for local development: docker run -v "$HOME/.aws:/root/.aws:ro" -e AWS_PROFILE=shop myimage. If the container runs as a non-root user, mount it into that user's home instead, or set AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE to the mounted paths.
• Use the instance's role on EC2. Containers on an EC2 instance can use the instance profile, but only if they can reach the metadata service. With IMDSv2 and the default hop limit of 1, the extra network hop of Docker's bridge network blocks it, and the SDK falls through to this error. Raise the limit to 2:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

Keys baked into an image with ENV or a copied credentials file go wherever the image goes: anyone with the image has the keys, and they end up in registries and build caches. For Python in the same situation, our boto3 NoCredentialsError guide covers the equivalent fixes.

Jake: "So the back-room PC failed because the container couldn't see Ethan's laptop keys?"

Ethan: "It couldn't see any keys. A container is a new, empty computer. You have to hand it the keys on purpose."

In GitHub Actions and other CI systems

CI runners start clean every time, with no profile and no metadata, so the SDK finds nothing unless the workflow provides credentials. The secure way on GitHub is OIDC: the workflow proves its identity to AWS and receives short-lived role credentials, with no stored keys at all.

permissions:
  id-token: write      # required for OIDC
  contents: read

jobs:
  upload:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/GitHubActionsShopUpload
          aws-region: us-east-1
      - run: npm ci
      - run: node upload.mjs

The action exports the role's temporary credentials as environment variables, which the SDK picks up at step 1 of the chain. On the AWS side you need, once: an IAM OIDC identity provider for token.actions.githubusercontent.com, and a role whose trust policy allows your repository (limit it to your repo and branch). The two most common failures are a missing id-token: write permission, which makes the action itself fail, and running node in a different job from the credentials step, where the variables do not exist.

Other CI systems follow the same idea: GitLab and Bitbucket support OIDC roles too, and as a last resort, stored secrets exposed as the standard AWS_* variables work everywhere.

On Lambda, ECS, EKS and EC2: it should just work

Inside AWS, credentials come from a role, automatically. When this error appears there, something is overriding or blocking that:

• Lambda: the execution role's credentials are provided as environment variables. If you see this error in Lambda, your code is almost certainly passing its own credentials (often empty values from a missing config) or a profile that does not exist in Lambda. Remove those and let the default chain work. If instead you see an access denied error, the role exists but lacks permissions.
• ECS: set a task role on the task definition (not just the task execution role, which is for pulling images and writing logs). Without a task role, your code has no credentials from step 7.
• EKS: use IAM roles for service accounts or EKS Pod Identity, which provide the web identity token or container credentials the SDK reads. A pod without either falls through to the node's metadata, which is often blocked by the hop limit.
• EC2: attach an instance profile (IAM role) to the instance. Check from the instance: curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ should print a role name (with IMDSv2 required, fetch a token first). No role name means no role attached.

On any of these, hard-coded keys in environment variables take priority over the role (step 1 beats steps 7 and 8). Remove stray AWS_ACCESS_KEY_ID variables from Lambda configuration or task definitions; otherwise you are using whoever's keys those are, not the role you set up.

In the browser (React, Vue, plain JavaScript)

In a browser there is no default chain: no files, no metadata, no environment variables. The SDK cannot find credentials on its own, by design, so calling AWS from browser code without supplying credentials always produces this error. The standard solutions:

• Amazon Cognito identity pools: fromCognitoIdentityPool from @aws-sdk/credential-providers exchanges a signed-in (or guest) user for temporary, tightly scoped AWS credentials.
• A backend in between: often better, the browser calls your API, and your server (with a role) calls AWS.
• Presigned URLs for S3 uploads and downloads: your backend creates a short-lived URL, and the browser uploads directly without any AWS credentials.

Putting access keys into front-end code, even in an environment variable at build time, publishes them to every visitor. Frameworks like Next.js run some code on the server and some in the browser; AWS calls belong in server code, where environment variables or a role are available.

With LocalStack and other local AWS emulators

LocalStack accepts any credentials, but the SDK still needs some to sign requests, so a fresh machine with no AWS setup fails before the request is even sent. Set dummy values:

const s3 = new S3Client({
  region: "us-east-1",
  endpoint: "http://localhost:4566",
  forcePathStyle: true,
  credentials: { accessKeyId: "test", secretAccessKey: "test" },
});

Keep the explicit credentials only in local and test configuration, so production uses the real default chain. The same applies to DynamoDB Local and other emulators.

If you would rather not change code, set the dummy values as environment variables for the local run only: AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_REGION=us-east-1 node app.mjs. The default chain finds them at step 1, and the endpoint setting points requests at the emulator. In a Docker Compose file for local development, the same three variables go under the app service's environment, next to the emulator's container name as the endpoint host.

In serverless frameworks, SDK wrappers and AI coding tools

Many tools are Node.js programs using this same SDK, so they fail with this exact message when they cannot find credentials:

• Serverless Framework, AWS CDK, Amplify CLI: they read the same profiles and environment variables. Pass --profile or set AWS_PROFILE, and refresh SSO logins.
• AI coding assistants and agents that call Amazon Bedrock: when configured to use Bedrock, they authenticate with the standard AWS chain, so "could not load credentials" means the profile or SSO login they run with is missing or expired. Set AWS_PROFILE and AWS_REGION in the environment the tool starts from, run aws sso login, and restart the tool so it picks them up.
• Apps run by a process manager (PM2, systemd, a Windows service): they do not inherit your terminal's variables. Put the variables in the service's own configuration.

Every cause, by environment

Setting credentials explicitly in code (when you must)

Usually the default chain is the right answer. When you need to choose a source deliberately, for example a specific profile in a tool that serves several accounts, the @aws-sdk/credential-providers package offers each source on its own:

import { S3Client } from "@aws-sdk/client-s3";
import { fromIni, fromSSO, fromEnv } from "@aws-sdk/credential-providers";

const s3Profile = new S3Client({ region: "us-east-1", credentials: fromIni({ profile: "shop" }) });
const s3Sso     = new S3Client({ region: "us-east-1", credentials: fromSSO({ profile: "shop-sso" }) });
const s3Env     = new S3Client({ region: "us-east-1", credentials: fromEnv() });

Choosing one provider means the others are skipped, so the same code will no longer work on Lambda or EC2 without changes. Keep explicit providers to tools and scripts that really need them, and let applications use the default chain so they run anywhere with the right role.

Assuming a role from Node.js

Many setups use one identity to sign in and then assume a role in another account. There are two clean ways to do it in SDK v3.

In the config file, so the default chain handles it everywhere:

[profile shop-prod]
role_arn = arn:aws:iam::444455556666:role/ShopUploader
source_profile = shop
region = us-east-1

With AWS_PROFILE=shop-prod, the SDK signs in with the shop profile, assumes the role, and refreshes the role's credentials as they expire. If the source profile itself is missing or expired, the whole chain fails with this error, so check the source first.

In code, when the role depends on the request (for example, one role per customer account):

import { fromTemporaryCredentials } from "@aws-sdk/credential-providers";
import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "us-east-1",
  credentials: fromTemporaryCredentials({
    params: { RoleArn: "arn:aws:iam::444455556666:role/ShopUploader", RoleSessionName: "nightly-upload" },
  }),
});

The base credentials for the assume-role call still come from the default chain, so the original problem must be solved first: assuming a role does not create credentials out of nothing. If the assume step fails with access denied instead, the role's trust policy does not allow your base identity.

Long-running apps and credentials that expire

A server that runs for days needs credentials that renew themselves. Sources that refresh automatically: SSO profiles (while the login lasts), assumed roles from a profile or fromTemporaryCredentials, and the ECS, EKS and EC2 role providers. Sources that do not: temporary keys pasted into environment variables. Those work until they expire, typically within hours, and then every call fails with an expired-token error until someone restarts the app with new keys.

So if your error appears after an app has run happily for a while, look for temporary credentials in environment variables and replace them with a role or profile that refreshes. Our expired token guide explains session lifetimes in more detail.

The fix, step by step

1. Run the test script where the failure happens, to confirm the environment, not your code, is missing credentials.
2. Decide which source should provide them here: profile or SSO (laptop), variables or mount (Docker), OIDC (CI), role (AWS compute), Cognito or a backend (browser).
3. Fix that one source using the section above.
4. Remove stray overrides: hard-coded credentials, unused AWS_ACCESS_KEY_ID variables, wrong profile settings.
5. Re-run the test, then your application.
6. If the error becomes "access denied," credentials now load, and the remaining work is IAM permissions for the identity that the test printed.

Frequently asked questions

The upload script now runs in three places, each with the right kind of key: Ethan's SSO profile on his laptop, an IAM role passed through the hop-limit fix on the back-room PC's EC2 test machine, and an OIDC role in GitHub Actions. None of them stores an access key anywhere. Jake asked why one script needed three different answers. "Same script, three different houses," Ethan said. "Each one keeps its keys in a different drawer."

Revision note. Written October 19, 2026, for the AWS SDK for JavaScript v3. The error is always the same sentence; the missing key is always in a different drawer.