Amazon S3 lands on the Vercel Marketplace and v0
S3, S3 Tables, and S3 Vectors are now provisioned from the Vercel Marketplace and v0, with OIDC temporary credentials instead of static keys.
Anyone who has ever glued a Vercel app to AWS knows the ritual this replaces. Open the AWS console, create a bucket, draft a bucket policy you will never fully re-read, generate an access key pair, paste it into environment variables, and then spend the rest of the project half-wondering where that key has already leaked. On October 14, AWS trimmed a whole section of that dance: Amazon S3, including Amazon S3 Tables and Amazon S3 Vectors, is natively available on the Vercel Marketplace and v0 by Vercel.
You add S3 storage resources directly from Vercel's own tools, and per AWS the integration covers three workloads: everyday storage, analytics, and AI. Resource provisioning and connection configuration are handled for you. S3 joins the existing Vercel integrations for Amazon Aurora, Amazon DynamoDB, and Amazon OpenSearch Serverless, which AWS describes as a complete application stack inside Vercel, from the database layer through object, vector, and open table storage, all on one AWS account with one bill.
Three bucket flavors are in play. General purpose buckets take everyday object storage. S3 Tables is fully managed Apache Iceberg with automated table maintenance and compaction, working with any Iceberg REST Catalog-compliant engine. S3 Vectors stores and queries vectors without a separate vector database. Note the fine print on that last one: S3 Vectors does not generate embeddings. You bring the model; S3 keeps the vectors and does the nearest-neighbor work.
Setup
From the Vercel dashboard: open the Storage tab, choose Create, pick AWS, select the bucket type, choose a Region, and create the bucket. Provisioning takes a few seconds. Connect the bucket to a project, then pull the injected environment variables:
1
2
vercel link
vercel env pull .env.localThe integration injects
AWS_REGION, AWS_ROLE_ARN, AWS_RESOURCE_ARN, and a bucket name such as S3_BUCKET_NAME, S3_TABLE_BUCKET_NAME, or S3_VECTOR_BUCKET_NAME. At runtime, the awsCredentialsProvider from @vercel/functions/oidc exchanges a short-lived OIDC token with AWS STS for temporary credentials scoped to the resource. AWS's summary: "No static keys are stored anywhere."An upload route then looks like this, straight from the announcement:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { awsCredentialsProvider } from "@vercel/functions/oidc";
const s3 = new S3Client({
region: process.env.AWS_REGION,
credentials: awsCredentialsProvider({ roleArn: process.env.AWS_ROLE_ARN }),
});
export async function POST(request) {
const formData = await request.formData();
const file = formData.get("file");
await s3.send(new PutObjectCommand({
Bucket: process.env.S3_BUCKET_NAME,
Key: file.name,
Body: Buffer.from(await file.arrayBuffer()),
ContentType: file.type,
}));
return Response.json({ success: true });
}Listing and reading use
ListObjectsV2Command and GetObjectCommand on the same client. For analytics, the announcement's DuckDB example attaches the table bucket by its ARN and runs a plain aggregate query against it; if you run DuckDB inside a Next.js route, add @duckdb/node-api to serverExternalPackages in next.config.mjs so the native bindings stay out of the bundle.Tips worth more than the setup guide
Read the role policy before you ship anything to users. The temporary credentials are scoped to the resource, a large improvement over a static key with admin-shaped habits. But the role behind
AWS_ROLE_ARN sets the ceiling on what any Vercel-side request can do, so when a project starts touching user uploads, review that policy the way you would review a teammate's pull request.Mind the linked-account catch. You can create a new AWS account through the integration, or link an existing one to keep your current billing and full S3 capabilities. If you link an existing account, AWS states that Vercel works only with new buckets created through the platform. Plan naming and any migration before you point the integration at the account your production data lives in, because retrofitting an existing bucket is not on the feature list.
Bring your own embeddings for RAG. The storage side is handled: document text in DynamoDB, embeddings in S3 Vectors, and the announcement's example query returns the top five matches with metadata in a single call. The generation side is yours. Budget for the model call, not only the vector store.
Costs and security review notes
The integration carries no charge of its own; you pay standard Amazon S3 pricing for what you use. New AWS accounts created through Vercel receive $100 in credits valid for six months. Availability spans all commercial AWS Regions supported by Vercel, from both v0 and the Marketplace.
For the security review agenda: the OIDC role is the main control surface, so treat its policy as the thing a release checklist exists to check. Resource ARNs and bucket names in environment variables identify infrastructure rather than authenticate anyone, which puts them in configuration, not the secrets vault, when you decide what to log. And since every S3 resource lives in your own AWS account, your existing tooling and billing stay in one place, which your auditors will appreciate more than another SaaS portal with its own export format.
v0 can also do the provisioning conversationally: describe "a support bot that answers questions from my PDFs" and it wires up S3 Vectors, configures the connection, and generates working code. That is either a wonderful timesaver or a reason to read the role policy twice. You already know which of those I believe.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article