A working AI agent has an unglamorous shopping list. It needs a database to remember things, somewhere to run that can stream tokens without timing out, object storage for whatever it produces, and access to a model. Assembled the usual way, that is four separate signups: a Postgres host, a compute platform, an S3 bucket, and an OpenAI or Anthropic account, each with its own credential to provision, inject, and rotate per environment.
Neon's June 2026 platform preview collapses that list. The pitch is that the database, the compute, the storage, and the model gateway all come from one account and branch together. I wanted to know if that was real or a slide, so I built the canonical example end to end: an image-generating agent that takes a prompt, calls a model, stores the result, and indexes it in Postgres. This is the build log, with the real commands and output, and the parts where the preview still shows.
(Companion repo: The-DevOps-Daily/neon-ai-agent. Everything below ran against a fresh project created while writing.)
Neon ships starter templates through its CLI. The image agent is one of them:
neonctl bootstrap ./ai-agent --template ai-sdk
That scaffolds 26 files: a Hono function, a Drizzle schema, a neon.ts
config, and (a nice touch) a .agents/skills/
directory with skill docs for the AI assistant you are probably using to edit the project. Neon bundles agent instructions for its own products, which tells you who this template is aimed at.
The file that matters is neon.ts
. It is the entire backend declared in one object:
import { defineConfig } from '@neondatabase/config/v1';
export default defineConfig({
preview: {
aiGateway: true,
buckets: {
images: {},
},
functions: {
imagegen: {
name: 'AI SDK image agent',
source: 'src/index.ts',
},
},
},
});
Three lines of intent: turn on the AI gateway, give me a bucket called images
, and deploy src/index.ts
as a function. No connection strings, no bucket ARNs, no model API keys. Those get filled in later, automatically.
neon link
creates and attaches a Neon project. The new platform features are private preview, so there are two constraints worth stating up front: everything is in AWS us-east-2
, and it only works on projects created inside the preview. Your existing Neon databases do not grow these features in place.
Then neon deploy
reads neon.ts
and provisions the declared services. Here is the whole sequence, link through deploy:
That last line is the actual product. Eleven environment variables (the DATABASE_URL
, the S3 access key/secret/endpoint, and the AI gateway token and base URL) all written for me, all scoped to this branch. The four credentials I would normally collect from four dashboards arrived from one deploy
.
The AI Gateway is OpenAI-compatible. Your existing SDK works by changing only the base URL, so the same chat completion against the cheapest catalog model looks like this in whatever you already use:
curl:
curl "$NEON_AI_GATEWAY_BASE_URL/ai-gateway/mlflow/v1/chat/completions" \
-H "Authorization: Bearer $NEON_AI_GATEWAY_TOKEN" \
-d '{"model":"gpt-5-nano","messages":[
{"role":"user","content":"What is Neon branching?"}]}'
Python:
from openai import OpenAI
client = OpenAI(base_url=GATEWAY_URL, api_key=GATEWAY_TOKEN)
client.chat.completions.create(
model="gpt-5-nano",
messages=[{"role": "user", "content": "What is Neon branching?"}],
)
Node:
import OpenAI from 'openai';
const client = new OpenAI({ baseURL: GATEWAY_URL, apiKey: GATEWAY_TOKEN });
await client.chat.completions.create({
model: 'gpt-5-nano',
messages: [{ role: 'user', content: 'What is Neon branching?' }],
});
Hitting it once returns exactly what you would expect from the model:
{
"model": "gpt-5-nano-2025-08-07",
"choices": [{ "message": { "role": "assistant",
"content": "Neon Postgres branching creates lightweight, independent
clones of a running database that can be developed in isolation..." }}]
}
The same token reaches around 25 models across Anthropic, OpenAI, Google, and a few open-source providers. You move between them by changing one model
string. There is no separate OpenAI or Anthropic account in this project. The published prices look like each provider's own list rate, so the gateway reads as pass-through with the convenience of a single credential:
The point is not the specific numbers, it is that "use a cheap model in CI and a frontier model in prod" becomes a config value rather than a second vendor integration.
The images
bucket is plain S3 as far as your code is concerned. The injected AWS_*
variables point the standard AWS SDK at a branch-scoped endpoint, so this just works inside the function with no custom client:
const s3 = new S3Client({ forcePathStyle: true });
await s3.send(new PutObjectCommand({
Bucket: 'images', Key: key, Body: jpeg, ContentType: 'image/jpeg',
}));
const url = await getSignedUrl(s3, new GetObjectCommand({ Bucket: 'images', Key: key }));
I confirmed it directly: a PutObject
then GetObject
round-tripped, and the presigned URL came back on a host scoped to the branch (br-green-star-….storage.c-3.us-east-2.aws.neon.tech
). That branch scoping is the part you cannot get by bolting an external S3 bucket onto a database: open a branch and its files fork with it, so a preview environment never writes into production's objects.
The function is a small handler. It streams a model response, and when the model calls its image-generation tool, it uploads the JPEG to the bucket, inserts a row in Postgres, and returns a presigned URL. Calling the deployed agent:
curl -X POST "$IMAGEGEN_URL" -H 'content-type: application/json' \
-d '{"messages":[{"role":"user",
"content":"Draw a small minimalist server rack icon, flat style"}]}'
The response streams back as the agent narrates and draws, and afterward the side effects are all there. The object is in the bucket, and the row is in Postgres pointing at it:
id | prompt | bucket_key | bytes
----+-----------------------------------+-------------------------------------+-------
2 | Draw a small minimalist server... | generated/ed49b102-…-f8c46e2f8c16.jpg | 47372
1 | Draw a small minimalist server... | generated/9125d5b4-…-63b54a892695.jpg | 47372
From an empty directory to a deployed agent that generates an image, stores it, and indexes it in Postgres took a few minutes and exactly one credential. The model call, the file write, and the database insert were all wired by the platform, not by me.
The build was smooth, but it is private preview and a few seams are worth knowing before you plan around it.
One region, new projects only.Everything is in AWSus-east-2
and only works on projects created inside the preview. You cannot bolt these features onto an existing production database today.
OPENAI_BASE_URL
Neon injects points at the OpenAI mlflow
dialect route instead. I hit a 404
until I switched routes. The SKILL docs the template ships actually explain this, which is the kind of detail that saves you ten minutes if you read it first.Yes, with an asterisk for "preview." The genuinely useful part is not any single feature, it is that the four pieces an agent needs arrive together, branch together, and authenticate with one credential. If you have ever spent the first afternoon of an AI side project wiring a database to a compute host to an S3 bucket to a model provider, collapsing that into one neon.ts
and one deploy
is a real reduction in moving parts.
Whether you should build on it today depends on your appetite for a private preview and for vendor consolidation. But as a statement of direction, an agent stack from one CLI is a clear one. We dig into the strategy behind it in Neon is becoming a backend platform, not just Postgres, and we benchmark Neon's database side in the Neon vs Supabase series. As these features leave preview, we will keep testing them the same way: real projects, real output, and the demo code published so you can run it yourself.
The full project is on GitHub. Clone it, point neonctl
at a new us-east-2
project, and deploy
: