Console layout reworked; AI Gateway adds models; CLI gains api-keys

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 regions for backend services coming soon

Object Storage, Functions, and the AI Gateway services are available only in AWS US East (Ohio) (aws-us-east-2). More regions are coming soon.

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:

<span class="line" data-line="1"><span style="color:var(--shiki-token-function)">curl</span><span style="color:var(--shiki-token-string)"> -X</span><span style="color:var(--shiki-token-string)"> POST</span><span style="color:var(--shiki-token-string-expression)"> "$NEON_AI_GATEWAY_BASE_URL/v1/chat/completions"</span><span style="color:var(--shiki-foreground)"> \</span></span>
<span class="line" data-line="2"><span style="color:var(--shiki-token-string)">  -H</span><span style="color:var(--shiki-token-string-expression)"> "Authorization: Bearer $NEON_AI_GATEWAY_TOKEN"</span><span style="color:var(--shiki-foreground)"> \</span></span>
<span class="line" data-line="3"><span style="color:var(--shiki-token-string)">  -H</span><span style="color:var(--shiki-token-string-expression)"> "Content-Type: application/json"</span><span style="color:var(--shiki-foreground)"> \</span></span>
<span class="line" data-line="4"><span style="color:var(--shiki-token-string)">  -d</span><span style="color:var(--shiki-token-string-expression)"> '{"model": "kimi-k3", "messages": [{"role": "user", "content": "What is Neon?"}]}'</span></span>

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.

Set up the Neon backend with your AI agent

To build with the beta services including AI Gateway, install the Neon agent skills so your assistant knows how to provision and wire them up:

<span class="line" data-line="1"><span style="color:var(--shiki-token-function)">npx</span><span style="color:var(--shiki-token-string)"> neon@latest</span><span style="color:var(--shiki-token-string)"> init</span></span>

Then ask your assistant to get started with Neon. See the backend beta guide for access and setup, or How a Neon backend fits together for a tour of all five capabilities.

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.

Get started with project permissions

Go from everyone-sees-everything to scoped access in about five minutes. Read the guide.

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.

New to the Neon CLI?

Install it with npm install -g neon, then authenticate with neon auth. See the install guide and CLI quickstart to get going.

Manage API keys withneon 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:

<span class="line" data-line="1"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> api-keys</span><span style="color:var(--shiki-token-string)"> create</span><span style="color:var(--shiki-token-string)"> --name</span><span style="color:var(--shiki-token-string)"> ci</span><span style="color:var(--shiki-token-comment)">                                        # account key</span></span>
<span class="line" data-line="2"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> api-keys</span><span style="color:var(--shiki-token-string)"> create</span><span style="color:var(--shiki-token-string)"> --name</span><span style="color:var(--shiki-token-string)"> ci</span><span style="color:var(--shiki-token-string)"> --org-id</span><span style="color:var(--shiki-token-string)"> org-example-12345678</span><span style="color:var(--shiki-token-comment)">          # organization key</span></span>
<span class="line" data-line="3"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> api-keys</span><span style="color:var(--shiki-token-string)"> create</span><span style="color:var(--shiki-token-string)"> --name</span><span style="color:var(--shiki-token-string)"> agent</span><span style="color:var(--shiki-token-string)"> --project-id</span><span style="color:var(--shiki-token-string)"> green-breeze-12345678</span><span style="color:var(--shiki-token-comment)">  # one project only</span></span>

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 withneon 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:

<span class="line" data-line="1"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> auth</span><span style="color:var(--shiki-token-string)"> --profile</span><span style="color:var(--shiki-token-string)"> work</span><span style="color:var(--shiki-token-comment)">                                            # create or re-authenticate</span></span>
<span class="line" data-line="2"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> deploy</span><span style="color:var(--shiki-token-string)"> --profile</span><span style="color:var(--shiki-token-string)"> work</span><span style="color:var(--shiki-token-comment)">                                          # use it</span></span>
<span class="line" data-line="3"><span style="color:var(--shiki-token-function)">neon</span><span style="color:var(--shiki-token-string)"> profile</span><span style="color:var(--shiki-token-string)"> create</span><span style="color:var(--shiki-token-string)"> ci</span><span style="color:var(--shiki-token-string)"> --mint</span><span style="color:var(--shiki-token-string)"> --project-id</span><span style="color:var(--shiki-token-string)"> green-breeze-12345678</span><span style="color:var(--shiki-token-comment)">    # or hold a scoped key, no browser</span></span>

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.

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