neon-object-storage

Name: neon-object-storage
Author: neondatabase

478installs12forks

How to install neon-object-storage?

neondatabase/agent-skills/neon-object-storage

$npx -y skills add neondatabase/agent-skills --skill neon-object-storage

Installs into the current project.

Summary

S3-compatible object storage that branches with your Neon project, so files and the database stay in sync across every branch. Use when a user wants object storage, a bucket, blob/file storage, or somewhere to put uploads, images, documents, avatars, or user-generated files for t

Files · 1

View on GitHub

SKILL.md

1	# Neon Object Storage
2
3	This is a public beta feature and only available in `us-east-2`. 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.
4
5	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.
6
7	## When to Use
8
9	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:
10
11	- They already use Neon 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.
12	- 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.
13	- 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.
14	- They want standard S3 tooling. It's built on S3 semantics and speaks the S3 API, so the AWS SDKs, `boto3`, the AWS CLI, and presigned URLs all work — reliable and familiar, with no proprietary client.
15
16	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.
17
18	## What It Does
19
20	- S3-compatible — Works with existing S3 SDKs, `boto3`, the AWS CLI, and presigned URLs. Path-style addressing and SigV4 only.
21	- Branches with your database — Every Neon branch gets its own isolated, copy-on-write storage state. Forking copies no data.
22	- Two access modes — `private` buckets require a credential for every operation; `public_read` buckets allow anonymous reads with authenticated writes.
23	- One credential system — The same Neon credential system used by Functions and the AI Gateway.
24
25	## Setup
26
27	Object storage is part of the `neon.ts` infrastructure-as-code config (see the `neon` skill for the branch-first workflow, `link`/`checkout`, and `neon.ts` basics). Declare buckets under `preview.buckets`, keyed by bucket name:
28
29	```typescript
30	// neon.ts
31	import { defineConfig } from "@neon/config/v1";
32
33	export default defineConfig({
34	preview: {
35	buckets: {
36	images: {}, // private by default
37	"public-assets": { access: "public_read" },
38	},
39	},
40	});
41	```
42
43	Provision the declared buckets on the linked branch:
44
45	```bash
46	neon deploy # alias for `neon config apply`
47	```
48
49	## Neon Infrastructure as Code (`neon.ts`)
50
51	The `preview.buckets` block above is part of `neon.ts`, Neon's infrastructure-as-code file — one TypeScript file declares your buckets alongside every other service the branch should have (see the `neon` skill for the full reference). Reconcile the declaration against a branch the Terraform way:
52
53	```bash
54	neon config status # print the branch's live config (which buckets exist)
55	neon config plan # dry-run diff of what apply would change
56	neon config apply # create the declared buckets (neon deploy is an alias)
57	```
58
59	Buckets are branch-scoped: when a `neon.ts` is present, `neon checkout` 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 `neon deploy` to apply changes. Provisioning (`config apply` / `deploy`), `link`, and `checkout` als

People who liked this also viewed

6 picks

Type

neon-object-storage

478installs12forks

View on GitHub

How to install neon-object-storage?

neondatabase/agent-skills/neon-object-storage

$npx -y skills add neondatabase/agent-skills --skill neon-object-storage

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Neon Object Storage
2
3	This is a public beta feature and only available in `us-east-2`. 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.
4
5	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.
6
7	## When to Use
8
9	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:
10
11	- They already use Neon 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.
12	- 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.
13	- 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.
14	- They want standard S3 tooling. It's built on S3 semantics and speaks the S3 API, so the AWS SDKs, `boto3`, the AWS CLI, and presigned URLs all work — reliable and familiar, with no proprietary client.
15
16	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.
17
18	## What It Does
19
20	- S3-compatible — Works with existing S3 SDKs, `boto3`, the AWS CLI, and presigned URLs. Path-style addressing and SigV4 only.
21	- Branches with your database — Every Neon branch gets its own isolated, copy-on-write storage state. Forking copies no data.
22	- Two access modes — `private` buckets require a credential for every operation; `public_read` buckets allow anonymous reads with authenticated writes.
23	- One credential system — The same Neon credential system used by Functions and the AI Gateway.
24
25	## Setup
26
27	Object storage is part of the `neon.ts` infrastructure-as-code config (see the `neon` skill for the branch-first workflow, `link`/`checkout`, and `neon.ts` basics). Declare buckets under `preview.buckets`, keyed by bucket name:
28
29	```typescript
30	// neon.ts
31	import { defineConfig } from "@neon/config/v1";
32
33	export default defineConfig({
34	preview: {
35	buckets: {
36	images: {}, // private by default
37	"public-assets": { access: "public_read" },
38	},
39	},
40	});
41	```
42
43	Provision the declared buckets on the linked branch:
44
45	```bash
46	neon deploy # alias for `neon config apply`
47	```
48
49	## Neon Infrastructure as Code (`neon.ts`)
50
51	The `preview.buckets` block above is part of `neon.ts`, Neon's infrastructure-as-code file — one TypeScript file declares your buckets alongside every other service the branch should have (see the `neon` skill for the full reference). Reconcile the declaration against a branch the Terraform way:
52
53	```bash
54	neon config status # print the branch's live config (which buckets exist)
55	neon config plan # dry-run diff of what apply would change
56	neon config apply # create the declared buckets (neon deploy is an alias)
57	```
58
59	Buckets are branch-scoped: when a `neon.ts` is present, `neon checkout` 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 `neon deploy` to apply changes. Provisioning (`config apply` / `deploy`), `link`, and `checkout` als

People who liked this also viewed

6 picks

Type