I Gave an AI Agent a Database, Compute, Storage, and Models From One CLI

Neon's June 2026 platform preview collapses the typical four-service AI agent stack—database, compute, storage, and model gateway—into a single CLI command. An engineer built an image-generating agent end to end using Neon's unified platform, provisioning all services from one `neon.ts` config file and deploying with `neon deploy`, which automatically injected all environment variables. The preview currently runs only in AWS us-east-2 and requires projects created within the preview.

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 https://github.com/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: js 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: 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: python 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: js 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 AWS us-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 https://devops-daily.com/posts/neon-backend-platform-not-just-postgres , and we benchmark Neon's database side in the Neon vs Supabase series https://devops-daily.com/posts/neon-vs-supabase-free-tier-benchmarks . 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 :