> Full Neon documentation index: https://neon.com/docs/llms.txt # A new Console layout for the Neon backend, more AI Gateway models, API keys and multiple accounts in the Neon CLI, and more ## A new Console layout for the Neon backend The Console sidebar has a new shape. Every branch-level [Neon backend](https://neon.com/docs/get-started/backend-overview) 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: ![The new Neon Console sidebar alongside the branch Overview page, which lists Postgres database, BetterAuth, Object storage, Functions, and AI Gateway with their status](https://neon.com/docs/changelog/backend_nav.png) Each service shows whether it's enabled on the branch, so the page doubles as a list of what you can still add. **Important: 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](https://neon.com/docs/ai-gateway/overview), 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: ```bash 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](https://neon.com/docs/ai-gateway/models#available-models), 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`](https://neon.com/docs/ai-gateway/models#list-available-models). **Note: 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: ```bash npx neon@latest init ``` Then ask your assistant to get started with Neon. See the [backend beta guide](https://neon.com/docs/get-started/backend-beta) for access and setup, or [How a Neon backend fits together](https://neon.com/docs/get-started/backend-overview) for a tour of all five capabilities. ## Project-level permissions for all orgs [Last week](https://neon.com/docs/changelog/2026-07-31#project-level-permissions) 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](https://neon.com/blog/neon-now-has-per-project-permissions) for the annoucement, and [User permissions](https://neon.com/docs/manage/user-permissions) for the complete documentation. **Tip: Get started with project permissions** Go from everyone-sees-everything to scoped access in about five minutes. [Read the guide](https://neon.com/docs/manage/project-permissions-get-started). ## 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. **Note: New to the Neon CLI?** Install it with `npm install -g neon`, then authenticate with `neon auth`. See the [install guide](https://neon.com/docs/cli/install) and [CLI quickstart](https://neon.com/docs/cli/quickstart) to get going. ### 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: ```bash 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](https://neon.com/docs/cli/api-keys) and [Manage API keys](https://neon.com/docs/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`: ```bash 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](https://neon.com/docs/cli/profile) 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. **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 `eu-central-1`, 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.