Tracker: Neon ships AI Gateway, Storage, and agent-safe credentials

This is a tracker post, the first of its kind on the ledger, so a word on what it is. A skill is a bet on a platform: it encodes how to build against someone else's services, and it is only as good as its assumptions stay true. When the platform moves, the skills either move with it or quietly rot on the shelf. So we watch a short list of platforms the shelf leans on — and when one of them has a quarter like Neon just had, it gets written up.

Neon is the obvious first card. The factory kit — the four skills that took pastmonday.com from an empty repository to production in about forty minutes — runs its entire backend on Neon. Over the past few weeks Neon shipped three things that kit cares about: an AI Gateway, S3-compatible Object Storage, and a way to let agents drive the platform without ever holding a raw key.

TL;DR

• AI Gateway, announced at the end of May and in private preview since late June: one API and one credential in front of models from Anthropic, OpenAI, Google, and open-source providers. The OpenAI and Anthropic SDKs work without code changes. General availability is expected in Q3.
• Object Storage, also in private preview: S3-compatible buckets that branch with your database, authenticated by your Neon credential — no second cloud account. Preview is limited to new projects in AWS us-east-2 for now.
• The neon api command, shipped July 10: agents call any Platform API route through the CLI's existing login, so the agent never touches a raw API key.

Resources

The kit that runs on all three, and the primary sources:

One key, every model

The AI Gateway is a single endpoint and a single credential in front of frontier and open-source models — Anthropic, OpenAI, Google, and others — with routing, logging, and rate limits handled at the gateway rather than in your application code. The detail that matters most in practice: the OpenAI and Anthropic SDKs work against it without code changes. You point the SDK at the gateway, and the provider zoo behind it becomes someone else's problem.

The case for it, from where we sit: every agent-built product now ships with an AI feature, and every AI feature used to mean another provider account, another key in the env file, another metering question the backend has to answer. The gateway collapses that to one seam. When the factory's backend stage wired pastmonday's chat, the whole integration was one base URL and one key — and the token metering that the free tier's budget depends on came with it. It is in private preview, and it showed up in our forty-minute run anyway; the agent found the OpenAI-compatible endpoint before the official SDK provider was even installable. GA is expected in Q3, at which point the last asterisk comes off.

Storage that follows the branch

Object Storage is S3-compatible buckets built into the Neon backend, and the headline is not the S3 part — it is that storage branches with your database. Every branch gets its own isolated namespace, so a preview environment gets files that match its rows instead of pointers into production's bucket. Buckets come in private and public_read modes, and any S3 SDK or tool works: point it at the branch endpoint and authenticate with your Neon credential. No separate storage account, no second set of cloud credentials to provision and rotate.

Anyone who has run preview deployments against a shared bucket knows the failure this kills: the database branches cleanly, the files do not, and a preview build happily serves production uploads or overwrites them. Rows and files finally share a lifecycle. The preview caveats are real — new projects only, AWS us-east-2 only for now — so this is one to design toward rather than migrate onto today. The factory's foundation stage already lays the storage seam; when the region list grows, the kit's runs inherit it without an edit.

If branching is new to you, it is worth understanding on its own before the storage angle makes sense — Neon's own material is the right rabbit hole:

Keys the agent never holds

The quietest release of the three is the one we think about most. As of July 10, the Neon CLI ships an api command: any route on the Platform API, called from the terminal, authenticated by the CLI's existing login. Run it with the route you want and the CLI signs the request; run neon api --list and it prints every available route from the OpenAPI spec. The stated reason is agent workflows, and the phrasing in the changelog is worth quoting straight: without hand-building curl requests or giving agents raw API keys.

Agents are spectacular at using APIs and terrible at keeping secrets. They paste keys into logs, commit them into examples, echo them into error messages — not out of malice, out of enthusiasm. The usual fix is a pile of redaction rules. Neon's fix is structural: the agent gets to say what it wants done, and a local, logged-in process does the signing. The credential never enters the context window, so there is nothing to leak. And because the command covers the whole Platform API surface the moment an endpoint exists, an agent has full reach on day one of any new Neon feature — no waiting for a dedicated CLI verb. That is the API-first thesis, adopted by the platform itself.

A skill is a bet on a platform. The tracker exists so the bets on our shelf stay good.

Why we run a tracker

Because the shelf is not a museum. The skills and kits on it encode assumptions about the platforms underneath — which services exist, what is in preview, where the seams are — and those assumptions age at whatever speed the platform ships. Watching that drift is maintenance work, and maintenance work is exactly what a directory should do once rather than every builder doing it separately.

The practical loop looks like this. Neon moves; the tracker records it; the kit's stages get updated once to match; and every run after that inherits the change — the next forty-minute build wires the gateway's GA endpoint or the new storage region without anyone re-reading a changelog. If you run your stack on a platform we track, the kit above is the compounding version of this post. And if you maintain skills on a platform we do not track yet, that is worth fixing — tell us, or better, publish the skill and make the case on the shelf.