FIRST: Use the parent
skill for a Neon overview, getting started with Neon, Neon development best practices, and more.
If the
skill is not installed, fetch it from
https://neon.com/docs/ai/skills/neon/SKILL.md or install it with:
bash
npx skills add neondatabase/agent-skills --skill neon
Neon Object Storage
This is a public beta feature and only available in
.
Neon Object Storage is S3-compatible object storage that branches with your projects: every branch gets its own isolated storage state, so files and database rows stay in sync across dev, preview, staging, and production.
Use this skill to help the user store and serve files that branch alongside their database. Deliver a working bucket and upload/download flow, a branch-aware S3 client wired to the injected env vars, or a precise answer from the official Neon docs.
When to Use
Reach for Neon Object Storage when the user needs to store files (images, uploads, generated assets, documents, backups) and any of the following are true:
- They already use Lakebase Postgres and don't want a second provider. One backend, one bill, one CLI, one set of branches — instead of standing up and wiring a separate AWS S3 / R2 / Supabase Storage account. The same Neon credential that backs the database backs storage.
- Files must stay in sync with the database across environments. Storage branches together with your Postgres data. Fork a branch and the child instantly inherits the parent's buckets and objects at that point in time — copy-on-write, so no data is duplicated. This is what makes agent, dev, preview, and test environments seamless: a preview branch gets a consistent snapshot of both the rows and the files they reference, and writes on the child never touch the parent.
- They want safe, throwaway environments. Upload, overwrite, and delete files in a preview/CI branch without any risk to production data, then drop the branch.
- They want standard S3 tooling. It's built on S3 semantics and speaks the S3 API, so the AWS SDKs, , the AWS CLI, and presigned URLs all work — reliable and familiar, with no proprietary client.
If the user has no Neon project, isn't on Postgres, and just needs a standalone CDN-backed asset store, a dedicated object store may fit better — but the moment branch-consistent files + rows matter, this is the reason to use it.
What It Does
- S3-compatible — Works with existing S3 SDKs, , the AWS CLI, and presigned URLs. Path-style addressing and SigV4 only.
- Branches with your database — Every Neon branch gets its own isolated, copy-on-write storage state. Forking copies no data.
- Two access modes — buckets require a credential for every operation; buckets allow anonymous reads with authenticated writes.
- One credential system — The same Neon credential system used by Functions and the AI Gateway.
Availability
Check this precondition before setting anything up: Neon Object Storage is a public beta feature available only on new projects in the
region. Confirm the user's Neon project is a new project in
before proceeding; it can't be enabled on existing projects.
Setup
Object storage is part of the
infrastructure-as-code config (see the
skill for the branch-first workflow,
/
, and
basics). Declare buckets under
, keyed by bucket name:
typescript
// neon.ts
import { defineConfig } from "@neon/config/v1";
export default defineConfig({
preview: {
buckets: {
images: {}, // private by default
"public-assets": { access: "public_read" },
},
},
});
Provision the declared buckets on the linked branch:
bash
neon deploy # alias for `neon config apply`
Neon Infrastructure as Code ()
The
block above is part of
, Neon's infrastructure-as-code file — one TypeScript file declares your buckets alongside every other service the branch should have (see the
skill for the full reference). Reconcile the declaration against a branch the Terraform way:
bash
neon config status # print the branch's live config (which buckets exist)
neon config plan # dry-run diff of what apply would change
neon config apply # create the declared buckets (neon deploy is an alias)
Buckets are
branch-scoped: when a
is present,
applies the policy as it
creates a branch, so a fresh preview/CI branch comes up with its buckets already provisioned (and copy-on-write objects inherited from the parent). Checking out an
existing branch doesn't reconcile it — run
to apply changes. Provisioning (
/
),
, and
also pull the branch's S3 credentials into your local
, so the same
step shown below happens for you on those commands.
Environment Variables
When
is declared, Neon injects
AWS-standard S3 env vars so the AWS SDKs work from the environment with zero extra config. Inside a deployed Neon Function these are injected automatically; locally, pull them onto disk (or inject them at runtime) via the CLI:
bash
neon env pull # writes the branch's vars into .env (or .env.local)
# or, without writing a file, inject at runtime:
neon-env run -- <your dev command>
| Variable | Meaning |
|---|
| S3 Access Key ID (the branch credential's token id) |
| S3 Secret Access Key |
| Branch S3 endpoint URL |
| Region, e.g. |
Because the names are AWS-standard, the AWS SDK picks up the credentials, endpoint, and region from the environment automatically. Credentials are branch-scoped and valid for that branch and all its descendants.
For typed, validated access to these credentials instead of reading
directly, pass the same
config object to
from
— it returns an
namespace (
,
,
,
) derived from your config. See the
skill.
Working with Objects: the Files SDK (Recommended)
The simplest, most portable way to read and write objects is the
Files SDK with its
adapter — a small, unified storage API (
,
,
,
,
,
,
,
) over web-standard I/O. It uses the AWS S3 client under the hood, configured appropriately for Neon, and relabels errors as
— so there's nothing to misconfigure. Reach for this first.
Install it alongside the AWS S3 peer dependencies the adapter uses internally:
bash
npm install files-sdk @aws-sdk/client-s3 @aws-sdk/s3-presigned-post @aws-sdk/s3-request-presigner
The adapter resolves its endpoint, region, and credentials from the same injected
env vars — pass only the bucket name:
typescript
import { Files } from "files-sdk";
import { neon } from "files-sdk/neon";
const files = new Files({ adapter: neon({ bucket: "images" }) });
// Upload — body may be a Buffer, Uint8Array, Blob, File, ReadableStream, or string
await files.upload("generated/cat.jpg", fileBuffer, { contentType: "image/jpeg" });
// Download
const file = await files.download("generated/cat.jpg");
const bytes = new Uint8Array(await file.arrayBuffer());
// Presigned GET — share without exposing credentials (defaults to a 1h expiry)
const url = await files.url("generated/cat.jpg", { expiresIn: 3600 });
// Plus: files.exists(), files.list({ prefix }), files.copy(), files.delete(), files.signedUploadUrl()
Swap the adapter import (
,
,
, …) and the rest of your code is unchanged.
Working with Objects: the AWS S3 Client (Alternative)
Neon speaks the S3 API directly, so you can drop down to the AWS SDK whenever you prefer the native client or already depend on it. The credentials, endpoint, and region are read from the standard AWS env chain, so the only setting you pass is
— Neon requires path-style addressing, so the S3 client
must set it:
typescript
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({
forcePathStyle: true, // required: Neon uses path-style addressing
});
Then upload, download, and presign with the raw command objects:
typescript
import { PutObjectCommand, GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
const BUCKET = "images";
// Upload
await s3.send(
new PutObjectCommand({
Bucket: BUCKET,
Key: "generated/cat.jpg",
Body: fileBuffer,
ContentType: "image/jpeg",
}),
);
// Download
const res = await s3.send(
new GetObjectCommand({ Bucket: BUCKET, Key: "generated/cat.jpg" }),
);
const bytes = await res.Body?.transformToByteArray();
// Presigned GET — share without exposing credentials
const url = await getSignedUrl(
s3,
new GetObjectCommand({ Bucket: BUCKET, Key: "generated/cat.jpg" }),
{ expiresIn: 3600 },
);
Pairing Storage with the Database on a Branch
The canonical pattern: an agent generates an image →
into the
bucket → a row is inserted in Postgres → a presigned URL is returned on read. Store the bucket
key (not the bytes) in a Postgres column, and presign on read. Because both the row and the object live on the same branch, they branch together and never drift.
CLI Bucket and Object Commands
also has first-class bucket/object commands (
neon bucket create|list|delete
,
neon bucket object put|get|list|delete
) for scripting and one-off operations.
Built-in Branch Logs
bash
neon logs query --branch production --source storage --since 1h
Storage is one of the two sources branch logs cover today, alongside Neon Functions. Logs are scoped to a single branch, so pass
when the bucket you're debugging isn't on the branch you're checked out on. Everything else about logs — the required CLI version, filters, the SDK, and the Loki-compatible read API — is in the parent
skill's
Observability section.
Neon Documentation
The Neon documentation is the source of truth and Object Storage is evolving rapidly, so always verify against the official docs. Any doc page can be fetched as markdown by appending
to the URL or by requesting
. Find the right page from the docs index (
https://neon.com/docs/llms.txt) and the changelog announcements.
Further Reading