# Using Atlas with Neon in 2026 > Neon's remote MCP server lets Atlas branch a Postgres database, run a migration on the branch, verify it, and delete the branch, all without touching main. 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 1. Bootstrap a Neon project first with npx neonctl@latest init, the fastest way to get a database before you connect Atlas. 2. Register Neon's remote MCP server: atlas mcp add neon --url https://mcp.neon.tech/mcp. Neon is remote only now. 3. Authenticate with atlas mcp auth neon. NEON_API_KEY is replaced by the OAuth flow, and the npm package @neondatabase/mcp-server-neon is deprecated. 4. Ask Atlas to branch off main, run the migration on the branch, and report the resulting schema diff. 5. Let Atlas read the branch's connection string and wire it into .env.local for a local test run against the branch. 6. Have Atlas delete the branch once the migration is verified, so preview databases do not pile up. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/integrations/neon Source of truth: aeo_pages row `/resources/integrations/neon` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.