> Full Neon documentation index: https://neon.com/docs/llms.txt

# 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](https://neon.com/docs/storage/overview): S3-compatible object storage that branches with your database.
- [Functions](https://neon.com/docs/compute/functions/overview): Long-running serverless compute that runs alongside your database.
- [AI Gateway](https://neon.com/docs/ai-gateway/overview): One API for frontier and open-source models, built into your project.

New to the Neon backend? Start with the [beta guide](https://neon.com/docs/get-started/backend-beta), see [how the pieces fit together](https://neon.com/docs/get-started/backend-overview), or build one end to end with the [full backend quickstart](https://neon.com/docs/get-started/full-backend-quickstart). For the vision behind the platform, read the [announcement blog post](https://neon.com/blog/neon-backend-is-beta).

**Note: One-shot your backend with an AI agent**

Install the beta agent skills:

```bash
npx neon@latest init --preview
```

Then build your backend from a single prompt:

```text
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`](https://www.npmjs.com/package/@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`](https://www.npmjs.com/package/@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.

```bash
npm install @neon/sdk
```

```typescript
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](https://neon.com/blog/neon-sdk) for the full story, or see the [TypeScript SDK documentation](https://neon.com/docs/reference/typescript-sdk) and [migration guide](https://neon.com/docs/reference/migrate-api-client-to-sdk) 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](https://neon.com/docs/manage/accounts#passkeys) for setup steps.

![Sign in to Neon with a passkey](https://neon.com/docs/changelog/neon-passkey.png)

## Git-style diffs in the Neon CLI

### New `neon diff` command

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

```sql
CREATE TABLE public.orders (
    id integer NOT NULL,
    customer_id integer NOT NULL,
    status text NOT NULL -- [!code --]
    status text NOT NULL, -- [!code ++]
    discount_code character varying(20) -- [!code ++]
);

CREATE INDEX orders_discount_code_idx ON public.orders USING btree (discount_code); -- [!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:

```bash
npx neon@latest init
```

### Config commands now show the same diff

[`neon.ts`](https://neon.com/docs/reference/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:

```bash
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.

**Tip: 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](https://neon.com/docs/introduction/regions#aws-nat-gateway-ip-addresses) for the complete list of NAT gateway IPs and the [Private Networking guide](https://neon.com/docs/guides/neon-private-networking) for VPC endpoint service addresses by region.