If you've built anything with a coding agent lately, you've hit this wall: the agent gets to the part where it needs a real Postgres instance, and then it stops. Not because it can't write the schema — because provisioning a database usually means a signup form, an email verification link, and a credit card field, and agents are famously bad at checking their inbox.
On September 11, 2026, Neon shipped a fix for exactly that problem: Claimable Neon, a flow that lets an agent provision a real, temporary Postgres project with scoped credentials — no account, no payment details — and then hand it off to an actual human later via a claim link. It's a small feature with a genuinely new idea underneath it, and as of this week nobody else on DEV.to has written it up.
What actually shipped
The mechanics, straight from Neon's technical reference:
An agent discovers the flow through a machine-readable auth.md file at neon.com/auth.md (a pattern WorkOS has been pushing as a discovery protocol for agent-to-service registration), then runs:
npm i -g neon@latest
neon claim create --service data-api --service auth --env-pull
That single command provisions a project scoped to that session — Lakebase Postgres, optionally the Data API and Managed Better Auth — and hands back credentials the agent can use immediately with any standard Postgres client. No human touches a signup form. When the build is done, the agent runs neon claim accept --no-open, which generates a short-lived link. A human clicks it, logs into (or creates) a Neon account, picks an org, and accepts the transfer. Neon then rotates every credential the agent was using, so the agent's access dies the moment a human takes ownership.
The part that actually matters: it's on a leash
Here's where it gets more interesting than "agents can make databases now." Neon put real limits on this, and they're worth knowing before you build a workflow around it:
| Constraint | Value |
|---|---|
| Unclaimed project lifetime | 72 hours, then deleted |
| Storage cap (pre-claim) | 100 MB |
| Transfer cap (pre-claim) | 1 GB |
| Claim link validity | 15 minutes per issuance |
| Access token lifetime | 900 seconds (15 min) |
| Builder-initiated transfer TTL (default, for platforms rolling their own claim flow via the transfer-request API) | 24 hours |
That last row is a separate, more general mechanism: platforms building their own onboarding on top of Neon's project-transfer API can set their own expiration instead of using the packaged 15-minute claim link. Same underlying idea, two entry points.
That's a database with an expiration date, and it's the right call. A durable, unbounded database that anyone can spin up with zero identity check is an abuse vector waiting to happen — someone scripts a loop, and you've got a few thousand free Postgres instances quietly costing Neon money with no one to bill. Capping it at 100 MB and 72 hours turns "anonymous infrastructure" into "anonymous demo," which is a much smaller attack surface. It's basically Tinder for databases: you've got a short window to make a real connection, or the whole thing expires and nobody remembers it happened.
Currently the claimable flow covers Postgres, the Data API, and Managed Better Auth. Object Storage, Functions, and the AI Gateway are marked "coming soon" in the docs, so this is v1, not the finished product.
Who this is actually for
This isn't aimed at you provisioning your own side project's database — you're not the bottleneck there, you have an account already. It's aimed at people building the thing that builds the thing: AI coding-agent platforms, no-code/agentic app builders, onboarding flows where a prospect should see a working app before they've committed to creating an account anywhere. If you're building a Bolt- or Replit-style product and your current answer to "the agent needs a database" is either your own hand-rolled multi-tenant Postgres cluster or forcing users through a signup wall before they see a single query run, this replaces that plumbing with three API calls (per Neon's integration guide): create a project, generate a transfer request, hand the user a claim URL.
Worth being direct about the incentive here: Neon built this to win the "which database does the AI app-builder wave standardize on" fight, the same way Vercel wants to be the default deploy target for the same wave. Neon's own partner pages describe technology-integration partnerships (Vercel, Replit, Cloudflare) with no terms listed for independent writers, and the only referral-style program we could find documented anywhere — via a third-party affiliate-program aggregator, not Neon's own site — is restricted to accepted open-source projects paid through GitHub Sponsors. Either way, there's nothing in it for us: we're recommending this because the mechanism is genuinely well-designed, not because there's a check on the other end of the link.
Bottom line
If you're building anything where an agent needs to stand up real infrastructure before a human is ready to sign up for something, Claimable Neon is worth wiring in now rather than building your own throwaway-project system — the 72-hour/100 MB leash is a sane default, not a limitation you'll fight. If you're just a developer using Neon for your own projects, this changes nothing for you today; it's infrastructure for the platforms you might build on top of, not for you directly.
- Adopt it if: you're building an agent-driven app builder, coding platform, or onboarding flow that currently stalls on "user needs to sign up before the demo works."
- Skip it if: you just need a database for your own app — regular Neon project creation is still the right tool.
- Watch: Object Storage, Functions, and AI Gateway support are "coming soon" — the useful surface area of this feature roughly doubles once those land.
- Recap link: Neon's Claimable Postgres
Researched and drafted with AI assistance, checked against primary sources.
Top comments (0)