AWS SDK error
CredentialsProviderError: Could not load credentials from any providers
"CredentialsProviderError: Could not load credentials from any providers" means the AWS SDK for JavaScript v3 tried its credential chain (environment variables, the shared config and credentials files, a credential process, a web identity token file, then the container or EC2 metadata service) and found nothing, so every S3 call and presigned URL fails. On Vercel the usual cause is that AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY sit in a local file or an AWS profile on your laptop, not in the project's Environment Variables for that environment. Add both there, or pass credentials to the S3Client under your own variable names, then redeploy. Reproduced with @aws-sdk/client-s3 3.1161.0 on 2026-10-31.
Paste this to your agent
Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.
Repository check
Check this in your repo
Find AWS keys the code reads but .env.example does not list
For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. When the code reads AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY from process.env and .env.example does not list them, it reports env_var_drift as a warning, but it cannot see the variables set in your Vercel project, so it cannot tell whether they are set there. For an S3Client created with no credentials option the code reads no variable, and it reported nothing on a fixture like that.
It is a repository check, not a live database test: it does not start your app or call AWS. It is advice, not a gate, and it exits with code 1 when it finds a blocker.
npx -y viberaven@1.7.1 checkWhat it printed on a fixture repo
On 2026-10-31 we ran it on a small Next.js fixture repo made for this page, not a customer repo, with @aws-sdk/client-s3, a presigned upload route, an S3Client that passes process.env.AWS_ACCESS_KEY_ID and process.env.AWS_SECRET_ACCESS_KEY, and an .env.example that listed only NEXT_PUBLIC_APP_URL. The output is below, with the folder shortened to ~/uploads-app. It is a warning, so the exit code was 0.
$ npx -y viberaven@1.7.1 check
viberaven check · ~/uploads-app
🟡 Env vars used in code but missing from .env.example (env_var_drift)
Code reads 3 environment variables that .env.example does not document (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET_NAME). Fresh clones, CI, and the production deploy can silently run without them.
Verdict: ✅ no blockers, 1 warning · score 90
Fix: viberaven fix · Details: ~/uploads-app/.viberaven/agent-tasklist.mdWhich variables and files does the SDK look at, and in what order?
The v3 default provider (credential-provider-node, defaultProvider.ts) tries, in order: environment variables, SSO (skipped unless SSO fields are passed), the shared config and credentials files, a credential process, a web identity token file, and the container or EC2 metadata service. The last link throws this error. When AWS_PROFILE is set, the environment provider is skipped.
The access key id and the secret are read as a pair. In a run on 2026-10-31 with an empty home folder and AWS_EC2_METADATA_DISABLED=true, no AWS_ variables gave the error, and so did AWS_ACCESS_KEY_ID alone and AWS_SECRET_ACCESS_KEY alone. Without that variable the same message came back on this machine. With both set, the presigner produced a URL with no network call.
new S3Client({ region: "us-east-1" }), no AWS_ variables
name: CredentialsProviderError
message: Could not load credentials from any providers
AWS_ACCESS_KEY_ID only
name: CredentialsProviderError
message: Could not load credentials from any providersWhy does it work on my laptop and fail on Vercel?
On your machine the chain finds something the deployment never gets: a profile in the shared credentials file (aws configure), an SSO login, or a variable from a local env file. A Vercel Function reads the variables you set in the project for its environment, Production, Preview or Development, and Vercel says a changed variable applies only to new deployments.
Vercel's guide for the AWS SDK says to add AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to the project, and AWS_SESSION_TOKEN only for temporary credentials, after which new S3Client({}) reads them. Functions also get AWS_REGION preset to the function's region.
What do the Vercel docs say about AWS_ variables, and about OIDC instead of keys?
Vercel lists AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION and AWS_DEFAULT_REGION as allowed names, and notes that these variables may appear in your functions even if you did not set them, and are not usable as AWS credentials. Seeing AWS_ACCESS_KEY_ID in a log does not show that your key reached the deployment.
For keys that never sit in the project, Vercel supports OIDC with AWS on all plans: create an IAM role that trusts Vercel, set its ARN as AWS_ROLE_ARN, and use awsCredentialsProvider from @vercel/oidc-aws-credentials-provider. Vercel also warns that AWS_REGION is not stable by default when a function can run in several regions, and tells you to declare it yourself.
import * as S3 from "@aws-sdk/client-s3"
import { awsCredentialsProvider } from "@vercel/oidc-aws-credentials-provider"
const s3 = new S3.S3Client({
region: process.env.AWS_REGION!,
credentials: awsCredentialsProvider({
audience: "sts.amazonaws.com",
roleArn: process.env.AWS_ROLE_ARN!,
}),
})Checklist
How to fix it, then check the fix
- 01Find AWS keys the code reads but .env.example does not list. For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. When the code reads AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY from process.env and .env.example does not list them, it reports env_var_drift as a warning, but it cannot see the variables set in your Vercel project, so it cannot tell whether they are set there.
npx -y viberaven@1.7.1 check - 02Find where the app creates its S3 client and which variables it reads, including committed env files:
grep -rnE "new S3Client|AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|AWS_REGION" --exclude-dir=node_modules --exclude-dir=.next . - 03Add the variables in Vercel for each environment that uploads, with no space or newline at either end of a value:
vercel env add AWS_ACCESS_KEY_ID production vercel env add AWS_SECRET_ACCESS_KEY production vercel env add AWS_REGION production vercel env add AWS_ACCESS_KEY_ID preview vercel env add AWS_SECRET_ACCESS_KEY preview vercel env add AWS_REGION preview - 04Or pass the credentials to the client under your own names. In a run, undefined values threw "Resolved credential object is not valid", but empty strings did not throw and produced a URL signed with an empty key, so check that both values are non-empty:
const s3 = new S3Client({ region: process.env.S3_REGION, credentials: { accessKeyId: process.env.S3_ACCESS_KEY_ID, secretAccessKey: process.env.S3_SECRET_ACCESS_KEY, }, }) - 05Add the variable names, with no values, to .env.example, so the next person to set up the project knows which ones to add.
- 06Redeploy, because Vercel applies a changed variable only to new deployments. Then call the route that signs or uploads: it should return the presigned URL, not a 500 with this error in the function logs.
Related
Related guides
Sources
Official docs behind this checklist
Browse all launch guides · Read resources · How to make and check your next change
FAQ
FAQ for builders before launch
Why do I get "Region is missing" after setting the keys?
In a run on 2026-10-31, an S3Client created with credentials and no region threw "Region is missing" when the presigned URL was requested. Set AWS_REGION in Vercel or pass region to the client. Vercel presets AWS_REGION to the function's region, which can change, so declare the region of your bucket yourself.
Should I use access keys or Vercel OIDC?
Both work on Vercel. The AWS docs recommend short-term credentials, and OIDC gives your function short-lived ones through an IAM role, so no key pair sits in the project. Access keys are long-lived values stored as project variables.