Atlas works with Neon through Neon's remote MCP server, which lets Atlas branch a Postgres database, run a migration on the branch, verify it, and delete the branch, all without touching main. Connect it with atlas mcp add neon --url https://mcp.neon.tech/mcp followed by atlas mcp auth neon. Neon is remote only now, and the OAuth flow has replaced NEON_API_KEY.
What Neon's remote MCP server gives Atlas
Neon's remote MCP server gives Atlas the one capability that makes agentic database work safe in 2026: branching. Atlas can branch a Postgres database, run a migration on the branch, verify it, and delete the branch, all without touching main, so a bad migration costs a branch and not an outage.
Most database integrations for coding agents stop at read access, because a write is irreversible and nobody wants an agent holding that pen. Neon changes the shape of the problem. When a database can be branched in seconds, a migration stops being a one-way door. Atlas can create a branch off main, apply the DDL there, look at what actually happened to the schema, and throw the whole branch away if the answer is wrong. Main never sees the failed attempt. That turns migration authoring into an ordinary edit-and-check loop, which is exactly the loop a terminal-native agent like Atlas is built to run.
Connecting Atlas to Neon in two commands
Neon is remote only now, so connecting Atlas takes exactly 2 commands. Run atlas mcp add neon --url https://mcp.neon.tech/mcp to register Neon's remote MCP server, then run atlas mcp auth neon to complete the OAuth flow. There is no local server process to launch and nothing to install.
Registering the server writes the Neon endpoint into your Atlas MCP configuration so it is available in every session in that workspace. The authentication step is separate on purpose: atlas mcp auth neon runs the OAuth handshake against mcp.neon.tech and stores the resulting credentials, so you authenticate once rather than on every run. Because the server is hosted by Neon at https://mcp.neon.tech/mcp, there is no process on your machine to keep alive, no version of a local package to pin, and nothing to rebuild when Neon ships new tools. The tools simply appear on the remote endpoint.
The deprecated npm package and the end of NEON_API_KEY
The npm package @neondatabase/mcp-server-neon is deprecated in 2026, and its deprecation notice points at mcp.neon.tech. The practical consequence is that NEON_API_KEY is replaced by the OAuth flow, so do not go hunting for an API key environment variable when wiring Atlas to Neon.
This is the single most common stumbling block, because older guides still tell you to install a package and export a key. Both halves of that advice are now stale. The @neondatabase/mcp-server-neon package is deprecated, and its own notice redirects you to the remote server at mcp.neon.tech. With the remote server, authentication happens through OAuth, which means NEON_API_KEY has no role to play. If a setup you are copying asks you to set NEON_API_KEY for Atlas, it predates the change. Run atlas mcp auth neon instead and let the OAuth flow hold the credentials.
Bootstrapping a Neon project before you connect Atlas
Running npx neonctl@latest init is the fastest way to bootstrap a Neon project before you connect Atlas. Do it first, so that by the time you run atlas mcp add neon --url https://mcp.neon.tech/mcp in 2026 there is already a real Postgres database with a main branch to branch from.
Order matters slightly here. Atlas's Neon workflow is built around branching off an existing main branch, so it helps to have a project in place before the agent arrives. The npx neonctl@latest init command handles that bootstrap: it stands up the Neon project so you are not clicking through a dashboard mid-session. Once the project exists, connect Atlas and let the MCP server take over. From that point on you should rarely need neonctl by hand, because branch creation, migration, and cleanup are all things you can ask Atlas to do through the remote server.
The daily workflow: branch, migrate, diff
The core Neon loop with Atlas is 3 moves. Ask Atlas to branch off main, run the migration on the branch, and report the resulting schema diff. Because the branch is isolated from main, you read that diff before anything reaches the database your application is actually pointed at.
Phrase the request as those three steps and Atlas will execute them in order through Neon's remote MCP server. Branching off main gives the agent a real Postgres database with your real data shape, not a mock. Running the migration on the branch surfaces the errors that only appear against real constraints and real indexes. Asking for the resulting schema diff is the part people skip and should not: the diff is your evidence that the migration did what the DDL claimed it would do. If the diff is wrong, you learned that on a branch, which costs nothing.
Testing locally against the branch connection string
Let Atlas read the branch's connection string and wire it into .env.local for a local test run. That points your application at the Neon branch rather than main, so in 2026 the migration Atlas just applied is exercised by real application code before you consider promoting it.
A schema diff tells you what changed. A test run tells you whether the change broke anything. Neon's remote MCP server can hand Atlas the connection string for the branch it just created, and Atlas can write that value into .env.local so your local process connects to the branch. Now the migration is under test by the code that actually uses it, with the queries your application really issues. Keep .env.local out of version control as you normally would. When the run passes, you have two independent signals that the migration is sound, and only then is promoting it a reasonable next step.
Cleaning up: delete the branch when the migration is verified
Have Atlas delete the branch once the migration is verified, so preview databases do not pile up. Neon branches are cheap to create, which is precisely why they accumulate, and an agent that creates 1 branch per iteration leaves a long trail unless deletion is part of the instruction.
Make cleanup an explicit step in the prompt rather than an afterthought. Atlas can delete a Neon branch through the same remote MCP server it used to create one, so the full lifecycle of branch, migrate, verify, delete lives inside a single agent session. The habit matters more than any one branch. Teams that skip it end up with dozens of stale preview databases whose purpose nobody remembers, and then someone has to audit them by hand. Ask Atlas to delete the branch the moment the migration is verified and the problem never forms.
Setup
- 01Bootstrap a Neon project first with npx neonctl@latest init, the fastest way to get a database before you connect Atlas.
- 02Register Neon's remote MCP server: atlas mcp add neon --url https://mcp.neon.tech/mcp. Neon is remote only now.
- 03Authenticate with atlas mcp auth neon. NEON_API_KEY is replaced by the OAuth flow, and the npm package @neondatabase/mcp-server-neon is deprecated.
- 04Ask Atlas to branch off main, run the migration on the branch, and report the resulting schema diff.
- 05Let Atlas read the branch's connection string and wire it into .env.local for a local test run against the branch.
- 06Have Atlas delete the branch once the migration is verified, so preview databases do not pile up.
Frequently asked questions
- how to connect Atlas to Neon MCP server
- Run atlas mcp add neon --url https://mcp.neon.tech/mcp, then run atlas mcp auth neon to complete the OAuth flow. Neon is remote only now, so there is no local server to install.
- is @neondatabase/mcp-server-neon deprecated
- Yes. The npm package @neondatabase/mcp-server-neon is deprecated and its notice points at mcp.neon.tech. Use the remote server at https://mcp.neon.tech/mcp instead.
- do I still need NEON_API_KEY for MCP
- No. NEON_API_KEY is replaced by the OAuth flow on the remote server. Run atlas mcp auth neon and let OAuth hold the credentials.
- can an AI agent run a Postgres migration without touching production
- With Neon and Atlas, yes. Atlas branches a Postgres database, runs the migration on the branch, verifies it, and deletes the branch, all without touching main.
- how do I test a Neon branch locally with Atlas
- Let Atlas read the branch's connection string and wire it into .env.local, then run your app locally. The application code exercises the migration on the branch, not on main.
- how do I stop Neon preview databases from piling up
- Have Atlas delete the branch once the migration is verified. Making deletion an explicit step in the prompt keeps preview databases from accumulating.
- how do I create a Neon project from the command line
- Run npx neonctl@latest init. It is the fastest way to bootstrap a Neon project before you connect Atlas to the remote MCP server.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas for Nuxt: Auto-Imports, useAsyncData, and Nitro Handlers in 2026
Atlas is a terminal-native AI coding agent for Nuxt in 2026. It reads nuxt.config.ts, pages/ routes, composables/ auto-imports, and server/api/ Nitro handlers, and tests with @nuxt/test-utils.
Atlas for Symfony in 2026
Atlas is a terminal-native AI coding agent for Symfony in 2026. It reads autowired services and Doctrine mappings, and shows migration SQL before anything runs.
Atlas with Mistral Small 24B (Ollama): The Single-GPU Commercial Pick for 2026
Run Atlas on Mistral Small 24B (Ollama): 14GB weights, 32K context, Apache 2.0, free self-hosted. Setup, the 32K vs 128K tag trap, and when a coder beats it.
Atlas with Qwen3-Coder Next (local via Ollama): the Top-Ranked Local Coder in 2026
Qwen3-Coder Next is the top-ranked local coding model of mid-2026: 262,144 token context, free self-hosted, or $0.22 / $1.80 per Mtok on Bedrock. Atlas setup and tradeoffs.
Atlas with Ministral 8B: The Cheap Slot That Can Still Call Tools in 2026
Ministral 8B runs 128,000 tokens at $0.10 / 1M input tokens and $0.10 / 1M output tokens, symmetric. The Atlas small_model upgrade when subagents misfire on schemas.
Atlas with Gemma 2 27B (Ollama): the Free Local Diff Reviewer in 2026
Gemma 2 27B (Ollama) is Google's 2024 flagship open model, 16GB and Free (self-hosted), with 8K tokens (8,192) of context. Use it to review Atlas diffs, not write them.
Atlas with Qwen Plus: 1M Context for $0.40 per Mtok in 2026
Run Atlas on Qwen Plus in 2026. Alibaba's mid tier gives 1M tokens (1,000,000) of context with reasoning at $0.40 per Mtok input, $1.20 per Mtok output.
Atlas with Qwen2.5-Coder 7B (local via Ollama): the Laptop Setup in 2026
Qwen2.5-Coder 7B runs Atlas on a laptop with no discrete GPU: about 5GB at 4-bit, a 32,768 token context, and free self-hosted. Setup, limits, and when to upgrade.