Changelog

A new Console layout for the Neon backend

The Console sidebar has a new shape. Every branch-level Neon backend service now sits at the same level.

• Postgres database is everything that was in the sidebar before: Tables, SQL Editor, Backup & Restore, Computes, Data API, Roles, and Databases, now under one collapsible item.
• Auth, Object storage, Functions, and AI Gateway backend services sit alongside it as siblings.

Above that section, the sidebar separates what belongs to project (Dashboard, Branches, Integrations, Settings) from what belongs to the branch (Overview, Credentials, Monitoring, Child branches). The branch picker sits between them, so it's clear which branch you're looking at when you open a service.

Overview is now a summary of the branch you have selected. It lists each backend service with its status, so you can see what the branch actually has enabled without opening each one:

Each service shows whether it's enabled on the branch, so the page doubles as a list of what you can still add.

More models on the AI Gateway

We've expanded the models available through the Neon AI Gateway, including Kimi K3, GLM-5.2, Inkling, and new additions to the Gemini and GPT families.

The catalog now spans frontier and open-weight models from OpenAI, Anthropic, Google, Meta, Moonshot AI, Alibaba, Zhipu AI, and Thinking Machines. One credential and one base URL reach all of them, so trying a different model means changing a string rather than signing up with another provider:

curl -X POST "$NEON_AI_GATEWAY_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $NEON_AI_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "What is Neon?"}]}'

Browse the full catalog in the model reference, where you can filter by provider or open weights and open any model for a copy-paste quickstart. To see what your own project can reach right now, call GET /v1/models.

npx neon@latest init

Project-level permissions for all orgs

Last week we introduced project-level permissions to newly created organizations. Existing organizations are now supported, so every team on Neon has the four organization roles (Admin, Editor, Viewer, and Collaborator) and per-project permissions.

See Neon now has per-project permissions for the annoucement, and User permissions for the complete documentation.

API keys and multiple accounts in the Neon CLI

There are two new additions to the Neon CLI that go together: api-keys mints credentials, and profile stores them and switches between them. Together they let you give an agent a credential that reaches exactly one project, or work across a personal account and a work organization without juggling config directories.

Manage API keys with neon api-keys

Minting a key used to mean opening the Console or hand-rolling a neon api request. neon api-keys now covers listing, creating, and revoking keys at every scope:

neon api-keys create --name ci                                        # account key
neon api-keys create --name ci --org-id org-example-12345678          # organization key
neon api-keys create --name agent --project-id green-breeze-12345678  # one project only

Project-scoped keys are the reason this matters. A key created with --project-id can't create projects, can't mint more keys, and can't see any other project, which makes it safe to hand to an agent or a CI job instead of sharing your account.

See the neon api-keys reference and Manage API keys for key types and permissions.

Use more than one account with neon profile

The CLI could only hold one account at a time, so anyone working across two built their own workaround out of --config-dir and shell aliases. A profile is a name pointing at a credentials file, selected per invocation with --profile or NEON_PROFILE:

neon auth --profile work                                            # create or re-authenticate
neon deploy --profile work                                          # use it
neon profile create ci --mint --project-id green-breeze-12345678    # or hold a scoped key, no browser

A profile can hold a browser sign-in or an API key, which is where it meets the scoped keys above. --mint signs in once, keeps only the minted key, and signs the session back out, so afterwards nothing about the profile can open a browser.

The CLI also now stores its configuration in $XDG_CONFIG_HOME/neon, or ~/.config/neon if that isn't set. A pre-existing neonctl directory is still read in place, so there's no migration step.

See the neon profile reference for the full command set and for how --profile resolves against NEON_API_KEY.

New NAT gateway IPs and VPC endpoint services in Europe (Frankfurt)

We've expanded infrastructure capacity in the AWS Europe (Frankfurt) region (eu-central-1) with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

If you use Private Networking in eu-central-1, 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.

Project-level permissions

A feature you've been asking for is finally here. Until now, a person's access applied across your entire organization. We're excited to bring project-level permissions to Neon, so you can now grant people and agents access on individual projects, giving them only what they need where they need it. On any project, you can make someone a Viewer to see its resources, an Editor to change them, or an Admin to manage access and the project itself.

Access works in two layers. When both apply, a user keeps the higher level of access:

• Organization roles set a baseline across every project. There are now four: Admin (full control), Editor (work in every project, but can't delete or transfer them), Viewer (read-only), and Collaborator (no access until granted specific projects).
• Per-project permissions raise that baseline on specific projects. Grant a member Viewer (read-only), Editor (connect, query, and edit resources), or Admin (manage access, settings, and the project lifecycle) on any project from Settings → Project permissions.

For example, give a contractor the Collaborator role, which grants nothing by default, then Editor on just the two projects they work on. Or give a teammate Viewer across the organization and Admin on the one project they own.

You can manage the same access through the Neon API, so an orchestrator can provision a project and grant a worker agent scoped access to it:

curl --request PUT \
     --url 'https://console.neon.tech/api/v2/projects/{project_id}/members/{member_id}/role' \
     --header 'authorization: Bearer $ORG_API_KEY' \
     --header 'content-type: application/json' \
     --data '{"role": "editor"}'

The CLI doesn't have a dedicated command yet, but you can call the same route with the neon api passthrough.

What changes for existing organizations

When your organization is migrated, it moves to the new model automatically, and everyone keeps the access they have today. No action is required:

• Admins stay Admins.
• Members become Editors, with the same access under the new name.
• Project creators become Admin on the projects they created.
• People with project-share access become Editor on the projects shared with them.

The older project collaboration feature is being replaced by the new Collaborator role plus per-project permissions.

See User permissions for roles, per-project levels, and how the two layers combine.

New guides for building on the Neon backend

Two new guides show how to combine the Neon backend services, from long-running compute to LLM access, all in a single project that branches with your data:

• Build durable background workflows with Inngest and Neon Functions: run a multi-step lead-enrichment pipeline on Neon Functions, with each step checkpointed so a failure retries just that step, and an executive summary generated through the Neon AI Gateway.
• Build an LLM proxy with Neon Functions, Neon AI Gateway, and Managed Better Auth: host a secure proxy on Neon Functions that keeps your LLM keys off the browser, authenticates users with Managed Better Auth, enforces per-user rate limits in Postgres, and streams responses from the AI Gateway.

npx neon@latest init

More with Lakebase Search

Lakebase Search adds scalable vector, keyword, and hybrid search to Postgres through the lakebase_vector and lakebase_text extensions. This week, two new resources show it in action:

• Case study: CommSync runs text, vector, and hybrid search on Postgres with Lakebase Search. See how a unified business inbox powers its main inbox (BM25 text search), AI assistant (semantic search), and command palette (hybrid search with Reciprocal Rank Fusion) from a single database, cutting query latency from 19.5 seconds to 18.6 milliseconds.
• Guide: Build image search over CLIP embeddings with Lakebase Search. Search a Flickr30k corpus by text, by image, and by caption from one vector(512) column, using the lakebase_ann index (IVF + RaBitQ) that builds 50 to 100 times faster than HNSW.

To get started, load the Lakebase Search preload libraries, then create the extensions:

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;
CREATE EXTENSION IF NOT EXISTS lakebase_text CASCADE;

Fixes & improvements

Debug Postgres from the terminal with neon inspect db

You can now run read-only Postgres diagnostics straight from the Neon CLI with neon inspect db. Each subcommand runs a single, known-good query against Postgres' own statistics and catalog views, then prints a clean table (or JSON/YAML for scripting). There's no connection string to assemble and no catalog view to recall: the CLI resolves the endpoint, role, password, and database through the same Neon API the SDK uses, so you name a diagnostic and go.

Fourteen subcommands cover the questions you actually ask when something is slow, grouped by what you're chasing:

• Size and storage: table-sizes, index-sizes, bloat
• Indexes and scans: unused-indexes, seq-scans
• Live activity and contention: long-running-queries, locks
• Query workload: outliers, calls (from pg_stat_statements)
• Maintenance: vacuum-stats
• Replication: replication-slots, subscriptions
• Neon cache debugging: lfc-hit-rate, working-set

Every command is read-only, scoped to the columns that answer the question, and capped where results can get large. That makes it as safe to hand to an agent as it is to run yourself. Point it at a linked project, or at any Postgres database with --db-url:

neon link                 # or: neon set-context --project-id <project-id>
neon inspect db bloat

neon inspect db outliers --db-url postgres://<user>:<password>@<host>:5432/<dbname>

See the neon inspect reference for the full command reference, and read the deep dive on our blog.

Manage snapshots from the Neon CLI

The Neon CLI now has a first-class neon snapshots command group. Snapshots are point-in-time backups of a branch, and they were previously only available in the Console and REST API. You can manage the full lifecycle from your terminal:

• neon snapshots list and neon snapshots get to see your snapshots.
• neon snapshots create to snapshot a branch, optionally at a point in time with --timestamp or --lsn.
• neon snapshots update and neon snapshots delete to rename, re-expire, or remove a snapshot.
• neon snapshots restore to restore a snapshot into a branch, with a preview step so you can inspect the result before running neon snapshots finalize to commit it.

For example, snapshot a branch before a risky migration, then restore it into a new branch if you need to roll back:

neon snapshots create --branch main --name pre-migration
neon snapshots list
neon snapshots restore pre-migration --name recovered

You can also view and set a branch's automatic backup schedule with neon snapshots schedule get and neon snapshots schedule set. Automated backup schedules are available on paid plans, except for the Agent plan. See the neon snapshots reference for the full list of subcommands.

Create projects with more control from the CLI

neon projects create now accepts flags to configure a project up front: choose the PostgreSQL version, create protected branches, and enable logical replication.

neon projects create --name my-app --pg-version 17
neon branches create --project-id <project-id> --name production --protected
neon projects update <project-id> --enable-logical-replication --yes

See the neon projects reference for the full list of flags.

Query Functions and Storage logs from the Neon MCP server

Functions and Object Storage are core pieces of the Neon backend: serverless compute and S3-compatible storage that branch with your database in the same project. You can now query logs from both services directly through the Neon MCP server, so your AI assistant can investigate a failure without leaving your editor. Three new read-only tools make up the observability category:

• query_logs: filter logs by source, service, severity, or a text match over a time window (or drop down to raw LogQL for full control).
• list_log_fields: discover the fields you can filter on.
• list_log_field_values: list the values a field takes, to ground your filters.

Once the MCP server is connected, ask your assistant in plain language:

Why did my function error in the last hour? Check the logs.

The same logs are documented under Neon Functions logs and object storage logs.

New guides for building on the Neon backend

Two new guides show how to build on the Neon backend, from declaring your services to shipping a real app:

• Manage Neon projects with neon.ts: use Neon's native TypeScript configuration to provision Postgres, Managed Better Auth, and the Data API, manage branch compute, and generate type-safe environment variables, all from one file that branches with your data.
• Build a Discord bot with Neon Functions and Neon AI Gateway: put Functions and the AI Gateway to work in a single project, with AI chat and image generation hosted next to your database.

npx neon@latest init