Backend beta, TypeScript SDK, passkey support, and CLI diffs

Jul 17, 2026– Neon backend beta, a new TypeScript SDK, passkey support, and Git-style CLI diffs

Neon backend for apps and agents is now in beta

Neon Object Storage, Functions, and AI Gateway have graduated from private preview to beta. Everyone can start building a complete backend on new or existing projects in AWS US East (Ohio) today.

Declare your whole backend in one neon.ts file, and it branches with your data. Fork a branch and you get an isolated copy of your database, files, functions, and gateway.

• Object Storage

  S3-compatible object storage that branches with your database.

• Functions

  Long-running serverless compute that runs alongside your database.

• AI Gateway

  One API for frontier and open-source models, built into your project.

New to the Neon backend? Start with the beta guide, see how the pieces fit together, or build one end to end with the full backend quickstart. For the vision behind the platform, read the announcement blog post.

One-shot your backend with an AI agent

Install the beta agent skills:

npx neon@latest init --preview

Then build your backend from a single prompt:

Set up a Neon backend for my app with Postgres, object storage, functions, and AI gateway

Your agent provisions the services, declares them in neon.ts, and wires them into your app.

New TypeScript SDK for the Neon API

We're introducing @neon/sdk 1.1, the best way to work with the Neon API from TypeScript. It's fetch-based, zero-dependency, and generated from our OpenAPI spec, with an ergonomic layer on top. It covers the whole Neon Platform API: projects, branches, databases, and our new backend services (Object Storage, Functions, and AI Gateway). It replaces @neondatabase/api-client as the recommended client, though the legacy package still works.

The ergonomic layer matters most for the multi-step provisioning workflows that might take you or your agent a few attempts to get right (for example, create a project, wait for it to be ready, then create a branch and hand back a connection string). createNeonClient({ apiKey }) gives you namespaced methods (neon.projects, neon.storage, neon.functions, neon.aiGateway, and more), typed { data, error } results, and workflow helpers like createAndConnect. Any method takes { waitForReadiness: true } to block until provisioning finishes, and a raw layer exposes every endpoint.

npm install @neon/sdk

import { createNeonClient } from "@neon/sdk";

const neon = createNeonClient({ apiKey: process.env.NEON_API_KEY! });

// Workflow helper: create, poll until ready, return a connection string
const { data, error } = await neon.projects.createAndConnect({ name: "my-app" });
if (error) throw error;
const { project, connectionString } = data;

// Or wait on any mutation with waitForReadiness
const { data: branch, error: branchError } = await neon.branches.create(
  project.id,
  { name: "preview" },
  { waitForReadiness: true }
);
if (branchError) throw branchError;

// The new backend services are namespaced too
await neon.storage.buckets.create(project.id, branch.id, { name: "uploads" });

Read the announcement blog post for the full story, or see the TypeScript SDK documentation and migration guide for setup, API reference, and moving from @neondatabase/api-client.

Passkey support

You can now sign in to Neon with a passkey instead of a 2FA code. Add a passkey from Account settings and use your device's built-in biometrics, like Touch ID or Windows Hello, or a security key to verify it's you. Passkeys satisfy organization-level 2FA requirements, so admins can let members enroll in either 2FA or a passkey to comply. See Manage your Neon account for setup steps.

Git-style diffs in the Neon CLI

Newneon diffcommand

We've added a top-level diff command to the Neon CLI, letting you (and your agents) quickly see schema changes between your current branch and any other branch you specify. It fits into a branch-first development workflow alongside neon link, neon checkout, neon status, and neon deploy.

1. neon link: link to a Neon project
2. neon checkout dev-1: create/checkout a dev branch
3. Do the dev work
4. neon diff main: sanity check the schema changes made against main

CREATE TABLE public.orders (
    id integer NOT NULL,
    customer_id integer NOT NULL,
    status text NOT NULL
    status text NOT NULL, 
    discount_code character varying(20) 
);

CREATE INDEX orders_discount_code_idx ON public.orders USING btree (discount_code); 

Want your agents to use neon diff? Install the Neon agent skills so your assistant has current knowledge of the CLI and reaches for the command on its own:

npx neon@latest init

Config commands now show the same diff

neon.ts is the TypeScript config file that declares your Neon backend: which services are on (Postgres, Auth, Data API, Object Storage, Functions) and your branch settings (compute size, TTL, protected). The config commands reconcile that file with what's actually live: neon config plan previews the changes, neon config apply makes them, and neon deploy applies and provisions in one step.

These commands now report their changes as a git diff instead of tables so you can see exactly what will change before you confirm:

Planned changes
  + Neon Auth
  + bucket uploads
  ~ main
      computeSettings.autoscalingLimitMaxCu  → 4
      ttl                                    → 2026-07-24T09:49:44.092Z

If apply finds a setting that already differs on the branch, it shows the current value too and stops without changing anything until you re-run with --update-existing.

New NAT gateway IPs and VPC endpoint services in US East (Ohio), Europe (London), and Asia Pacific (Singapore)

We've expanded infrastructure capacity in the AWS US East (Ohio) (us-east-2), Europe (London) (eu-west-2), and Asia Pacific (Singapore) (ap-southeast-1) regions with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

Update your IP allowlists

If you have IP allowlists on external systems that Neon connects to, update those allowlists to include the new NAT gateway addresses. Connections may be affected intermittently if traffic routes through non-allowlisted NAT gateways.

If you use Private Networking in these regions, you can now use the additional VPC endpoint service addresses for enhanced capacity and reliability. See the Regions documentation for the complete list of NAT gateway IPs and the Private Networking guide for VPC endpoint service addresses by region.